Open-source alternatives to Zep: 4 long-term memory for AI agents tools compared
Replacing Zep means the conversation history, the facts extracted from it and the summary format all move onto infrastructure you control, and the prompt your agent uses to read memory changes with them. Most readers should start with mem0ai/mem0, whose add-and-search shape is the closest thing here to dropping a memory layer into an agent that already exists.
What Zep does, and why people look elsewhere
Zep is a hosted memory service for AI agents: it keeps a running summary of a conversation and the facts drawn from it, then returns the relevant part on the next turn.
- the conversation history and the facts extracted from it are stored on the vendor's servers
- the agent has to reach the vendor's API on every turn that needs memory
- the extraction and summary format are the vendor's, so a different memory layer needs a different prompt shape
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install |
|---|---|---|---|---|---|
| mem0ai/mem0 | Apache-2.0Permissive: commercial use allowed | Commits in the last dayLast push October 23, 2026 | TypeScript | 67,710 | See analysis |
| supermemoryai/supermemory | MITPermissive: commercial use allowed | Commits in the last six monthsLast push October 22, 2026 | TypeScript | 31,365 | Command documented |
| TencentCloud/TencentDB-Agent-Memory | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 21, 2026 | TypeScript | 29,864 | Command documented |
| CaviraOSS/LongMemory | Apache-2.0Permissive: commercial use allowed | Commits in the last six monthsLast push October 18, 2026 | TypeScript | 4,543 | See analysis |
Each alternative in detail
mem0ai/mem0Mem0 stores and retrieves user, session, and agent memories so AI applications can carry preferences and context across conversations.
- Best for
- You are building an assistant, a support bot or an agent that has to remember user preferences across sessions, and you want either a library, a self-hosted server or a managed platform to hold them.
- What you give up
- The April 2026 algorithm is ADD-only, so a memory is never updated or deleted, and our analysis of Mem0 says to skip it if your workload needs corrections and removals. The self-hosted build also ships fewer advanced features than the managed platform, and the README says the published benchmark scores come from the managed platform with optimizations the open-source SDK does not have, so the numbers will not reproduce on your own hardware.
supermemoryai/supermemoryMemory and context engine + app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.
- Best for
- You want one memory engine that returns knowledge base documents and personal facts from a single query, connects to Drive, Gmail, Notion, OneDrive and GitHub, and can be reached from an SDK, an MCP server or a local binary.
- What you give up
- The newest tags are server releases still numbered 0.0.x, and our analysis of Supermemory says it does not suit a team that needs a production dependency with a stable server release. The local install is a remote script piped into a shell, which our analysis says is a problem for any policy against that, and the headline benchmark claims in the README are the project's own.
- First install step
- Full setup guide
npm install supermemory # or: pip install supermemory
TencentCloud/TencentDB-Agent-MemoryTencentDB Agent Memory is a team-level memory hub for AI Agents — turning conversations, docs, and code into four reusable memory assets (Chat Memory, Skill, LLM-Wiki, Code-Graph) that are governed, shared, and equipped across agents and frameworks.
- Best for
- Several coding agents work against the same codebase and you want them to share one set of reusable assets instead of re-explaining the project context in every session.
- What you give up
- The repository reports a licence GitHub cannot classify, so the LICENSE file has to be read before a deployment, and our analysis of TencentDB Agent Memory says to read the install document rather than the readme first. The stack wants two separate sets of LLM parameters filled in before anything runs, and the integration works by routing model traffic through a proxy, so what that proxy does with your prompts is a question our analysis says the readme does not answer.
- First install step
- Full setup guide
git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git cd TencentDB-Agent-Memory/deploy/global-images cp .env.example .env $EDITOR .env # Fill in two sets of LLM parameters (memory group + proxy group) ./start-all.sh # Launch everything with one command; when finished, it prints a one-liner you can paste directly into Claude
CaviraOSS/LongMemoryLocal persistent memory store for LLM applications including claude desktop, github copilot, codex, antigravity, etc.
- Best for
- Your agent needs point-in-time truth, supersession handling and recall scoped by permission rather than plain similarity, and you are willing to run a TypeScript service with SQLite behind it.
- What you give up
- Our analysis of LongMemory says it does not suit a team whose needs a simple vector store or a hosted memory service already covers, because the temporal and governance features add real operational overhead. The README says no service or external database is required for in-memory use, so you decide when to promote it to a running service, and our analysis asks you to test the multilingual and embedding provider paths because the README does not detail how they fail.
Four different memories: extracted facts, one structure, team assets, a temporal store
Zep is a hosted memory service for AI agents. It keeps a running summary of a conversation and the facts drawn from it, then returns the relevant part on the next turn. The reasons teams look elsewhere are about where that state lives: the conversation history and the facts extracted from it are stored on the vendor's servers, the agent has to reach the vendor's API on every turn that needs memory, and the extraction and summary format belongs to the vendor, so a different memory layer means a different prompt shape for the agent.
The four candidates disagree about what a memory is.
mem0ai/mem0 stores memories as discrete extracted facts. The README describes user, session and agent memory levels, and its April 2026 algorithm is a single-pass extraction where one LLM call pulls facts out and nothing is ever overwritten, with entities extracted and linked across memories and a retrieval step that scores semantic, BM25 keyword and entity matches in parallel before fusing them. It adds time-aware retrieval so a question about the current state ranks the right dated instance. The README publishes the evaluation framework as well, so the numbers can be reproduced.
supermemoryai/supermemory sells one structure instead of a stack of features. The README describes a memory layer that extracts facts, handles temporal changes and contradictions and forgets expired information, a user profile maintained automatically, a hybrid query that returns knowledge base documents and personal facts together, connectors for Drive, Gmail, Notion, OneDrive and GitHub, and extractors for PDFs, images, video and code. You reach it through an SDK, through an MCP server with three tools, or through a one-command local binary.
TencentCloud/TencentDB-Agent-Memory is about teams rather than conversations. Its README describes a memory hub that turns conversations, documents and code into four reusable assets, Chat Memory, Skill, LLM-Wiki and CodeGraph, with the chat side distilled in layers from a raw conversation up to a persona. Integration is a base-URL swap: point the agent at the proxy and the protocol does not change.
CaviraOSS/LongMemory is the strictest of the four. The README lists durable local-first storage on SQLite, immutable content with provenance, strict, historical, associative, grounded and multilingual recall, and explainable evidence selection with token-bounded context.
Who was left out, and why the hosted memory services are not here
Two groups are absent, and the reasons are worth stating.
The first is the hosted memory services, Zep included. They keep the conversation and the extracted facts on their own infrastructure, and the agent calls them on every turn that needs memory. That is the property you are removing.
The second is the plain vector stores. A vector store gives you nearest neighbours over embeddings you produced somewhere else. A memory service also has to decide what is worth keeping from a conversation and how to summarise it, and a vector store leaves both decisions to you and to a model you have to prompt.
Also missing are the agent frameworks that carry their own context handling, and the observability platforms that collect traces. Both can hold conversational state, but neither gives you a memory API to call in the middle of a turn.
One omission is specific: none of the four gives you a generic key-value store for your own application state next to the memory, so if your agent also has to remember a shopping cart or a workflow position, that part still needs its own answer.
Choosing by scenario: one developer, a small team, a company with residency rules, a developer swapping memory inside an agent
A solo developer who wants a coding assistant to remember them should look at supermemoryai/supermemory. The README describes plugins for Claude Code, Cursor, Codex, OpenCode, OpenClaw and Hermes, and an MCP server whose three tools are memory, recall and context, where context injects a user profile at the start of a conversation. Our analysis of Supermemory says it fits one person who wants a coding assistant to keep preferences across conversations.
A small team building a product with user context should look at mem0ai/mem0. The README lays out three shapes: a library for testing and prototyping, a self-hosted server for teams running on their own infrastructure, and a managed platform for production use without operations, and it is explicit that the self-hosted build ships fewer advanced features than the hosted one. Our analysis of Mem0 says it suits assistants, support bots and autonomous agents that need preferences to survive across sessions.
A company with data residency rules has to ask where the extraction happens, not only where the facts are stored. Every one of these four extracts with a model. For mem0ai/mem0 that call is the core of the algorithm, so a self-hosted deployment still needs a model endpoint inside your network. Supermemory says you can bring any model, and its README mentions running fully offline with Ollama. LongMemory stores on SQLite inside your own process. TencentDB Agent Memory wants two sets of LLM parameters filled in before anything runs, one for the memory group and one for the proxy group.
A developer swapping memory inside an existing agent has to rewrite the prompt shape, and that is the part people underestimate. Zep hands the agent a summary and the relevant facts. mem0ai/mem0 gives you an add call and a search call, so the agent decides what to store and what to ask for. supermemoryai/supermemory gives you three named tools, with the profile injected separately. TencentDB Agent Memory changes nothing about the protocol, because the proxy keeps the shape of the call the same. CaviraOSS/LongMemory exposes recall modes, strict, historical and associative among them, and the agent picks one per query.
What self-hosting a memory layer costs you
Every memory layer here has the same three moving parts, and each one costs something different.
The extraction model comes first. mem0ai/mem0 does one LLM call per extraction pass, so the throughput of your writes is the throughput of your model endpoint. Our analysis of Mem0 says to verify the exact retrieval latency with your own stack before you commit, because the published numbers came from a managed platform.
The store comes second. The self-hosted server for mem0ai/mem0 starts a stack with a browser wizard for the first API key, and the README says self-hosted auth is on by default, with a way to turn it off for local development only. supermemoryai/supermemory keeps a single structure and connects to external sources with real-time webhooks, which puts credential management for every connector on your side. CaviraOSS/LongMemory starts with no service and no external database for in-memory use, moves to SQLite with a file path, a tenant identifier and a user identifier, and also runs as an HTTP service on a local port or as a container with a data volume and an API key in the environment.
The third part is the update path, and here one project draws a hard line. The README for mem0ai/mem0 describes an ADD-only algorithm: memories accumulate and nothing is overwritten. Our analysis of Mem0 says to skip it if your workload needs frequent updates and deletions, which is a real constraint for a support agent whose users correct their own details.
And one project makes the local install a deliberate choice. The local path for supermemoryai/supermemory is a single command that pipes a remote script into a shell. Our analysis of Supermemory says it does not suit a policy that forbids that, which is worth knowing before you paste it.
Licences, and the question that is not about the licence
Three of the four are unambiguous. mem0ai/mem0 is Apache-2.0, supermemoryai/supermemory is MIT and CaviraOSS/LongMemory is Apache-2.0. You can run a modified copy inside your own network without publishing the changes, and none of them attaches conditions to the data you store.
TencentCloud/TencentDB-Agent-Memory is the one that needs a decision first. The repository reports a licence GitHub cannot classify, so the LICENSE file is the document to read, and our analysis of TencentDB Agent Memory says to read the install document rather than the readme before you commit, since the terms of a shared team hub are usually where the obligations live.
The question that is not about the licence is whether the memory has to work with no network at all, and it matters most to the teams moving away from a hosted service. mem0ai/mem0 needs an LLM call for extraction, so fully offline operation means pointing that call at a model you run yourself. Supermemory's README says you can bring any model and run fully offline with Ollama. LongMemory's whole design is local-first storage on SQLite, with no external service required for in-memory use. TencentDB Agent Memory expects two sets of model credentials and a proxy in the path.
One practical point closes this. Whatever you pick, the licence covers the tool. The conversation content, the facts extracted from it and the summaries built on top stay under your own terms, and what you accept are the terms of the tool that holds them.
Bottom line
Take mem0ai/mem0 when you want extracted facts in a searchable store you host, supermemoryai/supermemory when you want documents and personal facts from one query plus connectors, CaviraOSS/LongMemory when you need point-in-time truth, supersession and permission-scoped recall, and TencentCloud/TencentDB-Agent-Memory when several coding agents should share one set of team assets. Before committing, measure extraction and retrieval latency with your own model endpoint, read the LICENSE file of TencentDB Agent Memory, and decide whether you can accept a store that only ever adds facts.
Sources
Was this useful?