Mem0 vs Zep vs Letta vs a local ledger

Choosing agent memory in 2026, including the cases where the answer is not us.

The question that actually separates them

Every option below can store and retrieve memories. The differences that matter in practice are four: where your memory lives (their database, their platform, or your repo), what it costs to have installed (tokens of tool definitions before your first prompt), what happens to a number you corrected (does the agent keep quoting the old one from history?), and what happens when the agent writes the old number back anyway (is the correction merely shown, or enforced?).

What we lead with

Corrections surface first, and are enforced. A correction recorded once outranks the history that contained the old number, at every brief size, in every session. Surfacing alone is not enough: a correction remembered in one session can be re-violated in the next (TRACE, arXiv 2606.13174, measured that with Mem0 memory, 57.5% of applicable preference checks were still violated). So the guard hook checks every edit before it lands and gives one of three verdicts: verified (the edit agrees with the ledger), blocked (it writes a withdrawn value back, and the verdict names the ledger line and date that retired it), or no evidence (the ledger has nothing to say, reported as exactly that and never as a pass). A comparison that names the replacement beside the old value goes through. This is the behavior you can test in five minutes, or right now in the browser.

You can show your memory was not altered. Hash-chained audit logs are common now. What we have not found elsewhere is keyless verification: give an auditor the receipt and the public verify endpoint and they can confirm it without your key and without anything from us. A substituted, deleted, reordered or truncated event fails by name.

The context cost is small. All four tool definitions come to ~900 tokens, or 3.3 KB, enforced by a test that fails the build past 4 KB. Independent measurements put a typical multi-server MCP setup at 50–67k tokens before the first prompt.

Nothing of yours is stored unless you ask. Your memory is a file in your repo and we keep no copy of it, so there is nothing on our side to leak and nothing to migrate if you leave. The exception is hosted memory, which you turn on per project on a paid plan to sync machines; turning it off erases our copy. The free tier needs no account at all.

Industry benchmarks, with the method attached

LongMemEval and LoCoMo are the two benchmarks the field quotes. A score on either is only comparable when the reader model, the judge model, the retrieval unit and the question set are named. The official LongMemEval judge is gpt-4o-2024-08-06 with per-type prompts, LoCoMo's official metric is token F1 with no judge, and vendors disagree even on LoCoMo's category labels. So every row below carries its method, and a row without one is not here.

Our retrieval rows have no model in the loop: the memory system's job is to hand the reader the right evidence, and that is measured directly against each question's labelled evidence. Our QA rows are the complete runs, every question, on a local 8B reader and judge (qwen3:8b on an M1 Pro, $0) with the official prompts. Because the judge is not the official gpt-4o, read them exactly against our own arms and only approximately against vendor rows. On both benchmarks the shape is the same: single-hop questions are strong and multi-hop and temporal questions are the weakest, which is where the work goes next. Vendor rows are as each vendor published them, read 1 September 2026. The readers and judges differ from row to row.

The five-minute test

Installation (claude mcp add memory-pulse -- npx -y memory-pulse), one correction recorded with remember (kind=correction), a new session, and a question about the old number. The same sequence against your current setup makes the comparison.