LongMemory: A local-first temporal memory engine for LLM agents

The problem: retrieval pipelines do not remember

Most LLM memory systems are chunk, embed, and retrieve pipelines. They return nearest vectors, but they cannot answer whether a fact was true in January, which source is authoritative, or why a result belongs in context. LongMemory models those concerns directly. It is for developers building autonomous agents, coding assistants, or chat applications that need durable memory with temporal awareness and access control. The target user is someone who has hit the limits of naive RAG and wants a local-first alternative to hosted memory services.

Architecture: immutable nodes, executable edges, and temporal truth

LongMemory is built on what the README calls a Hydrograph memory substrate. It stores immutable nodes, executable edges, worlds, entities, facets, and traces in SQLite. Each piece of content has a recorded time and a separate valid time. That distinction lets the system keep superseded facts instead of overwriting them. Recall applies gates for temporal consistency, contradictions, confidence, grounding, permissions, and token cost. The design treats memory as a governed graph, not a flat vector index. This is a different assumption from most RAG tools, and it shows in the API.

Recall modes: strict, historical, associative, and world-grounded

The README shows four recall modes. Strict recall applies temporal, contradiction, contract, confidence, and grounding gates. Historical recall accepts a valid_time parameter so you can ask what was true at a past date. Associative recall follows semantic, lexical, entity, activation, and graph signals, which is closer to traditional similarity search. World-grounded recall requires current external evidence before returning a result. These modes are not just flags; they change the retrieval logic. A developer must choose the right mode per query, which adds design work but gives control over hallucination risk.

Getting started: library, CLI, and service

The fastest path is npm. Install longmemory, call createMemory(), ingest text, and recall with a mode. In-memory mode needs no external database. For persistence, pass store: 'sqlite' and a db_path. The CLI offers longmemory init and longmemory recall with a mode flag. To run as a service, clone the repo, run corepack enable, pnpm install --frozen-lockfile, pnpm build, and pnpm start. The API listens on http://127.0.0.1:7331. Docker is available through ghcr.io/caviraoss/longmemory, and a compose file includes an optional dashboard on port 3000. The .env.example file lists the server, request, memory and embedding settings.

Integrations: MCP, agent hosts, and the session porter

LongMemory serves MCP at the same address as its API, http://127.0.0.1:7331, and the Docker Compose file enables MCP over HTTP by default and requires LONGMEMORY_API_KEY. The README lists a session porter for Claude Code, Codex, OpenCode, Gemini CLI, Copilot Chat, Cline, and raw harness logs. That means you can import conversation history from those tools.

Governance and lifecycle: permissions, decay, and consolidation

LongMemory enforces scope at several levels: project, tenant, user, team, role, agent, task, and framework. The README states that these scopes are enforced. Lifecycle management includes deterministic decay, explicit reinforcement, consolidation, compression, and reconsolidation. That is a serious feature set for a local-first project. The trade-off is that you must design your scoping model up front. If you ingest everything under a single tenant and user, the governance machinery adds no value and only increases complexity.

Limitations and wrong-tool cases

LongMemory is not a drop-in vector database. Its recall modes require you to think about temporal validity and grounding, which is overkill for simple FAQ lookup. The README lists multilingual memory with script detection, code switching, transliteration and cross-language embeddings. Embedding providers include OpenAI-compatible APIs, Gemini, AWS Bedrock, Ollama, Siray, and local HTTP models. The project is in beta at v1.3.0, and the last push is dated 2026-10-18, which suggests active development, but also that APIs may still change. If you need a mature, widely adopted memory layer with a large community, this may not be it yet.

Alternatives: Mem0, Zep, and plain vector stores

Mem0 and Zep are other memory layers built for LLM agents. For teams that only need semantic search, a plain vector database like SQLite with sqlite-vec or a dedicated store like Qdrant is simpler and faster to operate. LongMemory's local-first, Apache-2.0 approach gives you full control, but you must run and maintain it yourself.

Maintenance and upgrade cost

LongMemory is Apache-2.0 licensed, so you can fork and modify it without commercial restrictions. The project is written in TypeScript and uses pnpm with a frozen lockfile, which suggests a reproducible build. The repository carries a MIGRATION.md at its root, and the beta status means upgrades could introduce breaking changes. The SQLite database stores nodes, worlds, entities, edges, temporal history, grounding, and lifecycle state, so you need to back up that file and understand its schema before upgrading. Plan to test each release in a staging environment. The dashboard and VS Code extension add more surfaces to update, so the maintenance cost is higher than a simple library.

Editorial conclusion

Adopt LongMemory if your LLM application needs point-in-time truth, supersession handling, and permission-scoped recall, and you are comfortable running a TypeScript service with SQLite. Do not adopt it if a simple vector store or a hosted memory service like Mem0 or Zep covers your needs, because LongMemory's temporal and governance features add operational overhead. Before committing, verify that the MCP surface and the recall modes match your agent's actual workflow, and test the multilingual and embedding provider paths with your data.

Frequently asked questions

Official sources

1. CaviraOSS/LongMemory on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases