Long-term memory is no longer just about storing conversation history. The strongest memory systems combine selective extraction, hybrid retrieval, entity linking, and token efficiency.

Mem0’s latest memory algorithm uses single-pass ADD-only extraction, multi-signal retrieval, and built-in entity linking. Across current benchmarks, it reports strong accuracy while keeping retrieved context under 7,000 tokens per query.

TL;DR: an AI memory benchmark comparison

Why This Matters?

LLMs can stream text fluently, but they still lose continuity once useful context falls outside the active window. Real agents need to remember preferences, timelines, decisions, and facts across days or weeks.

The production question is no longer “can we store memory?” It is “can we retrieve the right memory, at the right time, without stuffing the prompt?”

That is why memory systems are now evaluated across three practical constraints:

• Accuracy on long-term recall

• Latency during retrieval and response generation

• Token cost per query

A memory layer that is accurate but expensive is hard to scale. A fast but shallow memory layer will miss the details that make agents feel useful.

Methodology & Why Numbers Differ Across Sources

The numbers in this post come from a specific benchmark run, not a general claim about "Mem0's accuracy" that holds across every version and setup. Before comparing scores, it's worth being precise about what was actually tested.

These numbers come from Mem0's open-source memory-benchmarks suite (mem0ai/memory-benchmarks) which runs each benchmark through the same three steps every time: it ingests conversations into Mem0, letting the system extract facts, embed them, and link entities; it searches that stored memory for each test question using a blend of semantic similarity, BM25, and entity boost; then it generates an answer from what got retrieved and has a separate judge model score that answer against ground truth. The scores in this post come from running that pipeline against the managed Mem0 Platform on its v3 memory pipeline, at a retrieval depth of Top 200.

That last detail, the retrieval depth, is also the simplest explanation for why you'll see other Mem0 numbers floating around that don't match these. The suite's own documentation is upfront that its scores aren't absolute: they move with embedding model quality, with how capable the extraction and judge models are, and with how deep you set that top-k cutoff. Run LongMemEval on the self-hosted pipeline and swap only the extraction model, keeping the same embedder and judge, and the overall score moves from 91.0% with GPT-5 down to 88.6% with Gemma 4 31B. So if a third-party comparison shows Mem0 scoring lower, the more likely explanation is a shallower top-k, a lighter extraction model, or a smaller embedder, not an error in either post.

The suite's results/platform/ and results/oss/ directories also carry the full per-question evaluation data behind every score in this post, if you want to see the work directly.

The Four Memory Approaches

Benchmark Setup

The current Mem0 benchmark suite evaluates memory across LoCoMo, LongMemEval, and BEAM.

• LoCoMo tests memory recall across multi-session conversations, including single-hop, multi-hop, open-domain, and temporal questions.

• LongMemEval evaluates single-session recall, assistant recall, preference recall, knowledge updates, temporal reasoning, and multi-session memory.

• BEAM tests memory at 1M and 10M token scales. It is especially relevant for production because it cannot be solved by simply expanding the context window.

The key metrics are:

• benchmark accuracy

• average tokens per query

Results

Mem0’s latest token-efficient memory algorithm reports the following benchmark results:

The important point is not just the score. It is the token budget. Full-context approaches on these benchmarks can consume 25,000+ tokens per query. Mem0 stays under 7,000 tokens per retrieval call. For a closer look at how token cost scales with reasoning-heavy queries specifically, check out our blog on cost reduction.

Here is a category-wise breakdown for each benchmark:

LoCoMo

LoCoMo tests single-hop, multi-hop, open-domain, and temporal memory recall across conversational sessions.

Mean tokens: 6,956

The two biggest gains are on temporal queries (+29.6) and multi-hop reasoning (+23.1). For a developer, this means the new algorithm handles questions like "when did the user first mention X?" or "what led to the user's current decision?" much more reliably. Both categories directly test the ADD-only architecture and the entity linking layer.

LongMemEval

LongMemEval evaluates memory across single-session and multi-session contexts, including knowledge updates and temporal reasoning.

Mean tokens: 6,787

The biggest gains are on single-session assistant (+51.8), temporal reasoning (+45.9), and knowledge updates (+14.1). The jump in assistant memory recall means the new system reliably remembers things your agent said. That is the kind of thing developers assume will work until they actually test it. The old algorithm had a blind spot for agent-generated facts that the new one does not.

BEAM

BEAM evaluates memory systems at 1M and 10M token scales across ten task categories, including preference following, temporal reasoning, and contradiction resolution. It is the only public benchmark that operates at context volumes production AI agents actually encounter.

Mean tokens (1M): 6,719 Mean tokens (10M): 6,914

Performance is meaningfully stronger at 1M than at 10M. At the 10M scale, retrieval gets harder because similar content appears multiple times across the window, and the memory system cannot always surface the exact correct memory over other close matches.

What Changed in the Memory Architecture

Mem0’s current algorithm has three major pieces.

• Single-pass ADD-only extraction: The system extracts new memories in one pass and only adds facts. It does not overwrite or delete older memories during extraction. When information changes, the new fact is stored alongside the old one, preserving history. This approach to preserving rather than silently overwriting older facts is also what keeps memory from going stale as an agent runs for months; check out our blog for how this plays out over long time horizons.

• Multi-signal retrieval: Search combines semantic similarity, BM25 keyword matching, and entity matching. The signals are fused into one final score.

• Built-in entity linking: External graph memory has been replaced by entity linking inside the memory stack. Entities are extracted from memories, stored in a parallel entity collection, and used to boost relevant results during search. This entity layer is also what makes it possible to resolve the same person or account across sessions; see our blog for more on that specific problem.

Practical Recommendations

Reproducing Current Mem0 Behavior

For the latest Mem0 open-source setup:

pip install --upgrade mem0ai

pip install --upgrade mem0ai

pip install --upgrade mem0ai

For hybrid search and entity extraction:

pip install --upgrade "mem0ai[nlp]"
python -m spacy download en_core_web_sm

pip install --upgrade "mem0ai[nlp]"
python -m spacy download en_core_web_sm

pip install --upgrade "mem0ai[nlp]"
python -m spacy download en_core_web_sm

Note: The [nlp] extra currently works with Python 3.10–3.12. On Python 3.13, spaCy dependencies may fail to build.

For Qdrant users, install fastembed to enable BM25 sparse-vector search:

pip install fastembed

pip install fastembed

pip install fastembed

Search now uses filters for entity IDs:

results = m.search(
    "what did Alice say about deployment?",
    filters={"user_id": "alice"},
    top_k=20,
    threshold=0.1,
)

results = m.search(
    "what did Alice say about deployment?",
    filters={"user_id": "alice"},
    top_k=20,
    threshold=0.1,
)

results = m.search(
    "what did Alice say about deployment?",
    filters={"user_id": "alice"},
    top_k=20,
    threshold=0.1,
)

External graph memory setup is no longer required. The old enable_graph and graph_store configuration paths have been removed from the current OSS SDK.

Summary

Large context windows delay forgetting, but they do not solve memory problems. A production memory layer has to decide what to store, how to preserve changes over time, and how to retrieve the right facts cheaply.

The strongest pattern is selective memory plus hybrid retrieval. Mem0’s latest architecture reflects that direction: ADD-only extraction, entity linking, and multi-signal search under a practical token budget.

If your agent needs to live longer than its context window, memory is no longer optional infrastructure. It is part of the core agent stack.

Frequently Asked Questions

Q. Why do third-party benchmarks show different Mem0 scores?

Usually because of SDK version, harness, or replication differences rather than a real contradiction. See the Methodology section above for the specific reasons scores can diverge across sources, and the Reproducing Current Mem0 Behavior section if you want to verify these numbers yourself.

Q. Does Mem0 still support graph memory?

Standalone graph memory configuration (enable_graph, graph_store) has been removed from the current Mem0 OSS SDK. The relationship-aware recall it used to provide is now handled by built-in entity linking, described under "What Changed in the Memory Architecture" above.

Q. How does Mem0 compare to other memory tools like Zep or Letta?

Mem0 differs from Zep and Letta in retrieval strategy and architecture, covered in more depth in dedicated comparisons: see Mem0 vs Zep and Mem0 vs Letta for the full breakdown.