LongMemory: A local-first temporal memory engine for LLM agents
Local persistent memory store for LLM applications including claude desktop, github copilot, codex, antigravity, etc.
At a glance
- What is it?
- LongMemory is a TypeScript memory store that adds temporal truth, governance, and explainable recall to LLM applications. It targets developers who need more than vector search, but it brings real complexity.
- Who is it for?
- 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.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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 README does not show a full config file, so expect to read the source for advanced options.
Integrations: MCP, agent hosts, and the session porter
LongMemory exposes 13 high-level governed tools through MCP, plus readable resources and workflow prompts. You can start a local stdio MCP server with longmemory mcp --db .longmemory/project.db --project current, or an authenticated HTTP MCP server with LONGMEMORY_API_KEY and longmemory serve --mcp-http. Tool arguments cannot override server-bound runtime identity, which is a strong governance property. 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, but the README does not explain how the porter handles conflicting or duplicate content.
Governance and lifecycle: permissions, decay, and consolidation
LongMemory enforces scope at several levels: project, tenant, user, team, role, agent, task, and framework. The README claims these are enforced during recall, not just at write time. 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. The README does not show how to configure ACL policies, so this is an area to verify in the source.
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 and code switching, but it does not document accuracy or failure modes for low-resource languages. Embedding providers include OpenAI-compatible APIs, Gemini, AWS Bedrock, Ollama, Siray, and local HTTP models, but there is no benchmark comparing them. The project is in beta at v1.3.0, and the last push is dated 2026-08-31, 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
A real alternative is Mem0, which offers a managed memory layer with graph-based recall and a similar focus on temporal facts, but it is cloud-hosted and uses a different extraction pipeline. Zep is another alternative, with a temporal knowledge graph and a Python-first SDK, but it also leans on a server component. 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. The key difference is that LongMemory bakes temporal truth and governance into the storage layer, while Mem0 and Zep often handle those concerns in application logic or external services. 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 README does not mention migration guides between versions, 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. There is no mention of a versioned API or a data migration tool, so 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 13 MCP tools and the recall modes match your agent's actual workflow, and test the multilingual and embedding provider paths with your data, since the README does not detail failure behavior for those integrations.
Community notes