What happened when we ran it
Our run of Hindsight at commit f843f17 installed 2,172 npm packages in 146 seconds and occupied 1,684 MB afterward. We cloned it on October 13, 2026, into a fresh, unprivileged Debian container with 3 CPUs, 8 GB of RAM, image lab-node:22, and no secrets. Installation succeeded. This establishes that the npm dependency step completed in that environment. It doesn't establish that an agent could store or recover a memory.
The checkout contained 5,053 files, roughly 847,014 source lines, and occupied 249.2 MB. The harness skipped build and tests because it found no script or target for either. Its scan recorded monorepo workspaces and 9 CI workflow files, with no Dockerfile or tests directory detected. Those are scan results, not proof the project has no container recipes or checks elsewhere. npm audit reported 68 known vulnerabilities: 62 high, 6 moderate, and none critical or low.
Hindsight turns retained facts into beliefs you can inspect
Hindsight's retain operation uses a language model to extract facts and their context from conversations or documents. Background consolidation groups related facts into observations, which keep links and quotations from supporting memories. New information can revise an existing observation. For a support assistant, that offers a way to update its understanding when a customer's circumstances change, while preserving evidence you can inspect. That's the strongest reason to consider it.
The 2,172-package installation doesn't tell us whether those derived beliefs are correct. Hindsight's observation documentation explains how evidence accumulates and how stale observations are checked against raw facts during reflection. Evidence counts still need interpretation: repeated statements can repeat a mistake. I'd evaluate corrections explicitly, including a preference withdrawn later, before letting remembered information influence customer-facing answers. Our sandbox results contain no memory-quality evaluation.
Self-hosting still needs a model provider and durable storage
The recommended Docker route bundles the API, web interface, and embedded PostgreSQL. The README supplies a hosted model credential through HINDSIGHT_API_LLM_API_KEY; local providers are also supported. Production can use external PostgreSQL with pgvector. The deployment guide distinguishes local model components from the language-model service, which remains external to the Docker image. Choosing self-hosting therefore still leaves a decision about where inference runs and where retained text goes.
Our 146-second npm install didn't exercise that deployment. Persist the database volume and give production workers a stable HINDSIGHT_API_WORKER_ID: the guide warns that changing container identities can leave interrupted tasks assigned to an old worker. Host bind mounts also need ownership matching the container user. These details make the docs useful, but they add real operating work beyond the quick-start command. A successful package install settles none of them.
Recall retrieves evidence; reflect writes an answer from it
Hindsight's recall pipeline combines semantic, keyword, graph, and time-based searches, then merges and reranks their results. Reflect gathers evidence and generates an answer using the bank's configured disposition. Use recall when your application needs memories to handle itself; choose reflect when you want Hindsight to reason over them. Both decisions affect what your application trusts. A retrieved fact and a generated interpretation deserve different treatment in your own code.
The 1,684 MB measured after npm installation is only the footprint of that lab path. It gives you no service-memory budget or request-latency estimate. Hindsight also exposes retain, recall, and reflect through a bank-specific MCP endpoint, and its coding-agent integration can ingest git history and sessions for tools including Claude Code. That makes persistent project context convenient, while increasing the importance of knowing exactly what gets retained and replaced.
Open reports concern lost history and API availability
Issue 5708 reports that coding-agents 0.8.1 moves its git-history window in steps, then replaces the aggregate document and deletes facts for commits that fall outside it. The report concerns this project's coding-agent ingestion, and remained open when checked. I'd avoid treating that integration as a permanent project archive until its replacement behavior is verified against the version you intend to use. Keep the original repository and transcripts.
Our Node 22 sandbox didn't exercise coding-agent ingestion or the API. Separately, issue 5703 reports that loading a large observation graph in the control plane blocks API work long enough for Kubernetes liveness probes to restart the service. That is a user report, not our measurement. For a shared service, include graph browsing in availability checks rather than assuming the administrative interface can't interrupt callers.
Recent maintenance earns a trial, with narrow adoption criteria
GitHub recorded a last push on October 16, 2026, and the latest release, v1.0.0, shipped on October 13. The API listed 50,565 stars and 139 open issues and PRs combined. New issue reports continued on October 17, while the release notes list fixes to integration capture and scoped API access. That is active maintenance alongside unresolved defects. The release tag alone doesn't establish readiness for your workload.
For user-preference storage, compare Mem0. For an application centered on time-aware entity relationships, compare Graphiti. I'd choose Hindsight for an assistant that needs revisable, evidence-linked understanding across sessions. The 62 high-severity audit findings make dependency review a prerequisite for adoption, although the supplied audit summary doesn't identify exploit paths. Start with one bank and a correction-heavy workload. Require the assistant to stop using a withdrawn fact before expanding what it remembers.