Where memkeeper fits among agent memory systems
If you are choosing a memory layer for an agent, the honest question is not "is memkeeper good," it is "why this instead of mem0, Zep, or Graphiti." Those are real projects solving an overlapping problem, and some of them are excellent at things memkeeper does not try to do. This is a map, not a takedown. It should help you pick the right tool even when that tool is not ours.
We are going to compare on architecture and deployment, not on benchmark scores. Cross-vendor memory benchmarks are scored by LLM judges with different harnesses and are genuinely hard to compare, so a table of everyone's self-reported numbers would mislead more than it informs. Design choices are durable; this quarter's leaderboard is not.
The short version
| Axis | memkeeper | mem0 | Zep / Graphiti |
|---|---|---|---|
| Deployment | local, OSS, one binary | OSS, self-host, or cloud | Zep is cloud; Graphiti is the OSS library under it |
| Where memory lives | your machine | your store or mem0's cloud | Zep's cloud, or your own graph database |
| How memories are written | explicit CLI/MCP writes; deterministic dedup | model extracts from the transcript | model extracts from the transcript |
| What a result carries | the fact plus context; provenance on request | the distilled fact | graph facts and edges |
| Retrieval | BM25 + dense + rerank, plus an entity graph | vectors, optional graph | temporal knowledge graph |
| Runtime footprint | one SQLite file | a vector store (and optional graph) | a graph database, plus an LLM call per write |
| Cost shape | zero marginal, local | free tier, then metered | credits or enterprise |
The rows that matter most are where the memory lives, what each result carries, and how much machinery it takes to run. Those are the real forks.
Where the memory lives
This is the first fork, and it is mostly a values question. Zep today is a hosted product: its open-source Community Edition was retired in 2025, so self-hosting now means running the underlying Graphiti library against your own graph database rather than running Zep. mem0 gives you a real choice: an Apache-2.0 library you can self-host, or a managed cloud. memkeeper only does one of these on purpose. Your agent's memory is your decisions, your preferences, and facts about your systems, and we think the default home for that is the machine you are already working on, not someone else's tenant. If you want a managed service with an SLA, that is a genuine reason to look at the hosted options instead, and we would rather tell you that than pretend the trade does not exist.
The fact, and the why
This is the difference that shows up the moment you actually use one of these. A lot of memory systems distill a conversation down to a bare fact and hand back that string: "user prefers dark mode." Useful, until the agent needs to know whether that still holds, where it came from, or what it was really about. memkeeper stores each memory with its context, keeps provenance internally, and exposes source only when you explicitly ask for it. The agent gets not just what you decided but the frame behind it, without every recall including source metadata by default. In hands-on use against a system that returns atomic facts alone, that gap, the missing why, is the thing you feel first. It is also why the harder, multi-step questions hold up: the answer often lives in the context around a fact, not the fact by itself.
Who writes the memory
It is tempting to call this automatic versus manual, but that is not the real line, because memkeeper does not make you type commands for every workflow either. A script or MCP client can call remember, and uncertain writes can go to a candidate queue for review. What differs is the mechanics underneath, and how much of it you can see and steer. mem0, Zep, and Graphiti run an extraction model over the conversation that decides what to keep and reconciles it against the store. memkeeper is explicit about capture and deterministic about bookkeeping: dedup and supersession key on the fact's identity rather than being re-reconciled by a model, so you can read, search, and audit the store. Memories that keep proving useful can be promoted on retrieval traffic, not on a model's guess. Low-friction in practice, inspectable by design. It is the same instinct behind measuring abstention: we would rather the memory be deliberate and honest than large and confident.
How much machinery it takes
This is the most concrete difference. Graphiti, and Zep on top of it, build a temporal knowledge graph, which means a real graph database as a dependency (Neo4j, FalkorDB, or similar) and an LLM call on every write to extract entities and relationships. That buys something real: bi-temporal reasoning and point-in-time queries over a large, evolving fact base. mem0 needs a vector store, and a graph store too if you turn on its graph memory. memkeeper is a single binary over one SQLite file. There is no service to stand up, no graph database to operate, and no extraction model parsing every message to decide what to store. Lexical search works with zero setup; semantic is a local model or an API key when you want it. And memkeeper still keeps a first-class entity graph in that same SQLite file, so you get entities, relationships, and multi-hop graph context without a graph database to operate. What it does not do is the heavier temporal-knowledge-graph work, which brings us to the honest limitation.
Where memkeeper is genuinely narrower
memkeeper has a first-class entity graph, with entities, relationships, and multi-hop graph context, and semantic retrieval alongside its lexical search. What it is not is a temporal knowledge graph. If your problem is deep temporal reasoning over a large, evolving body of enterprise facts, with point-in-time queries, audited multi-tenant infrastructure, and an SLA, memkeeper is not the tool, and Zep and Graphiti are built squarely for that. memkeeper does record temporal validity, with valid-from and valid-to on both memories and relationships, observed-at timestamps, fact supersession, and TTL expiry, but it does not yet make time a retrieval dimension: no point-in-time "what was true on date X" queries, and search does not filter by validity window. And, like the rest of it, the graph is built from explicit assertions and links rather than extracted from raw text by a model. We are also pre-release. Naming that plainly is the point of a fair comparison. The places memkeeper wins are deliberately smaller and sharper: a single-machine, inspectable memory that keeps the context behind each fact, with a graph and semantic retrieval included, that costs nothing per query and tells you when it cannot answer.
So who is it for
memkeeper is not trying to be a hosted enterprise memory platform or a temporal knowledge graph. It is the simplest local-first, inspectable memory layer for people building agents and coding workflows who do not want hosted infrastructure, per-write metering, a graph database to operate, or a model silently reconciling what they remember behind the scenes. If that is you, start with the ten-minute walkthrough. If it is not, one of the systems above probably fits better, and now you know which axis decides it.