OpenMemory

Most LLM applications forget everything the moment a session ends, and the common workaround, stuffing past conversations into a vector database and retrieving the nearest chunks, has obvious gaps. Plain RAG does not know whether a fact is still true, how recently it mattered, or what kind of memory it even is. OpenMemory, built by CaviraOSS, positions itself as a local, self-hosted long-term memory store for agents and copilots, framed as a step beyond embeddings in a table. It describes itself as a cognitive memory engine: a persistent layer that an LLM app can write to and recall from across sessions, running on your own machine with SQLite by default or external Postgres. The pitch is ownership and explainability, keeping user data and recall logic in your own infrastructure rather than a hosted memory API.

OpenMemory models memory in sectors instead of one flat store. Its README lists episodic memory for events and conversations, semantic for facts, procedural for skills and workflows, plus emotional and reflective sectors. On top of that sits a temporal knowledge graph using valid_from and valid_to timestamps, so a superseded fact can be closed out and point-in-time queries become possible. Recall combines vector search with graph traversal over waypoints and a composite score blending salience, recency, and coactivation, with gradual decay rather than hard expiry. The distinctive part is the explainable trace: it surfaces which nodes were retrieved and why, which is rare among memory layers. It ships Python and JS SDKs, an opm CLI, an MCP server, and connectors for GitHub, Notion, and Google Drive.

The natural audience is developers building stateful AI: agents, coding assistants, copilots, journaling tools, and knowledge-worker apps where a model needs to carry context forward across sessions rather than rebuild it from scratch each time. The framework integrations point at this directly, with documented hooks into LangChain, CrewAI, AutoGen, and Streamlit, plus MCP support so Claude, Cursor, and Windsurf can read and write memory. Concrete uses include a coding agent that remembers project conventions and prior decisions, a personal assistant that retains preferences and recurring facts, or a research tool that accumulates findings over weeks. The connectors and the migration path from Mem0 and Zep also make it a candidate for teams that already run a hosted memory layer and want to move that data onto self-hosted, local-first infrastructure they control.

The honest caveats are real. This is the smallest community among comparable projects here, and there has been no release since December 2025, so on paper it is the least actively maintained of the group. The README itself carries a notice that the project is mid-rewrite, with breaking changes and bugs expected on the rewrite branch, which is a clear signal it is not yet production-hardened. The performance and cost claims, the reported faster recall and lower cost versus hosted APIs, are the project's own benchmarks rather than independent results, so treat them as marketing until verified in your own workload. There is also a sloppy detail: the homepage states MIT while the repository is actually Apache-2.0. Minor, but in a memory layer that handles user data, attention to detail and steady upkeep matter.

Compared to commercial memory APIs such as Mem0, Zep, or Supermemory, OpenMemory trades a managed, supported service for local ownership, a richer sectored model, and explainable recall traces, and it provides a migration tool so the switch is not a clean-room rebuild. That tradeoff is appealing when data residency, cost control, and transparency outweigh the convenience of a hosted SLA. It is interesting today if you want a self-hosted, explainable memory layer with ready connectors and you are comfortable tracking a moving target. It is too early if active maintenance is a hard requirement: six months without a release plus an in-progress rewrite means you should expect to read source, pin versions, and possibly contribute fixes. Prototype with it, but validate the benchmarks and stability before betting production on it.