COMPARISON
causal-memory vs mem0
mem0 is the better fact store. causal-memory answers the next question: why did that decision work, and what did it prevent?
Updated · English
The short version
mem0 is the reference implementation of the fact-memory layer: pull facts and preferences out of a conversation, deduplicate them, and return the ones closest to the current query. It is good at that job, and the benchmark table below says so before this page says anything else.
causal-memory stores a different object. Alongside facts it keeps typed edges between a decision, the context it was made in, and what happened — caused, enabled, prevented, no_effect. Those edges live in one SQLite file that sits outside the agent's context window, so compaction cannot rewrite them.
The difference only shows up at a specific moment: the agent is about to do something again. Fact recall answers 'what does the user prefer?'. Causal recall answers 'last time we skipped the migration lock, production login failed for 40 minutes, and adding the lock prevented it'. The second answer changes the next action; the first one decorates it.
This page is deliberately structured so that the gaps come before the pitch. If your workload is fact recall, mem0 is the correct default and there is no reason to migrate.
The gap, up front: mem0 is stronger at fact recall: 91.6% vs 79.1% on LoCoMo with a strict judge. If fact recall is the job you are hiring memory for, mem0 is the better tool and this page will not pretend otherwise.
causal-memory vs mem0, capability by capability
The last block of this table is deliberate: it lists the places where causal-memory is the weaker choice. A comparison page that only has winning rows is an advertisement.
| Capability | causal-memory | mem0 |
|---|---|---|
| What gets stored | Facts, temporal state and decision → outcome causal edges in one SQLite file | Extracted facts, preferences and entities, retrieved by semantic similarity |
| Causal edge types | caused / enabled / prevented / no_effect, each with a fixed spread coefficient | Memory relations are not typed as causal; there is no prevented edge |
| Pre-action check | intervention_query returns a ranked warning chain before the tool call happens | Retrieval is query-driven; there is no forward-simulation entry point |
| Inhibition | prevented spreads −0.3, so a known-bad approach ranks below neutral instead of tying with it | No negative activation; semantic similarity is the only ranking signal |
| Belief revision | Soft superseded_by keeps the falsified edge readable for counterfactuals | An update usually replaces or adds a fact; the old belief is not queryable as the loser of a comparison |
| Compaction survival | 100% causal recall after 5x compaction — the table is outside the context window | 45% textual recall after 5x compaction in our harness |
| Deployment shape | One binary plus SQLite; stdio or HTTP MCP; no external service required | SDK plus a vector store; a managed cloud platform is available |
| Fact recall (LoCoMo, strict judge) | 79.1% | 91.6% — mem0's home turf |
| Client surface | Rust core, Python bindings, 17 MCP tools; TypeScript through any MCP client | First-class Python and TypeScript SDKs with broad framework integrations |
| Where causal-memory is weaker — read this before the pitch | ||
| Fact recall — LoCoMo (strict judge) | 79.1% | 91.6% |
| Fact recall — LongMemEval-S | 76.4% @ 11.5K tok/q | 94.4% official · 73.8% independent repro |
| Lesson transfer — CausalEval C6 | 20% | 30% (mem0, 70q protocol) |
| SDK surface | Rust core and Python bindings; TypeScript only through MCP | Native Python and TypeScript SDKs |
| Managed platform maturity | Hosted memory is early; self-hosting is the documented path | Managed cloud, dashboards and team features |
| Community and integrations | Small team, v0.10.0-alpha, Apache-2.0 | Larger ecosystem and more framework adapters |
When to choose each one
Choose mem0 when
- Your memory is mostly user preferences, profile facts and entity lookups, and LoCoMo-style recall is the metric you report.
- You want native Python and TypeScript SDKs plus a managed service with team-facing controls.
- You already run a vector database and want memory to sit behind it rather than in a separate file.
- You are not recording decisions and outcomes, so there is nothing causal to store yet.
Choose causal-memory when
- Your agent repeats the same mistake after every context compaction, and you can name the mistake.
- You need a pre-action warning on risky operations — a deploy, a destructive migration, a production write.
- You want the falsification trail: what was believed, when it was superseded, and what the old belief still explains.
- You want local-first memory in a single file, with no service to operate and no data leaving the machine.
The numbers, with their provenance
Source: causal-memory README v0.10.0 · CausalEval v13, read 2026-10-21. The baseline column is the mem0 run on the same 70-question protocol; a like-for-like comparison.
| Capability | causal-memory | mem0 (70q baseline) | What it tests |
|---|---|---|---|
| C7 Update | 100% | 80% | Supersede an old belief after it is falsified, and keep the old edge retrievable |
| C3 Counterfactual | 95% | 80% | Choose between alternatives with known outcomes |
| C2 Intervention | 75% | 40% | Forward prediction: if X happens again, what follows? |
| C4 Inhibition | 80% | 50% | Separate the root-cause fix from the blast-radius limiter |
| C1 Attribution | 85% | 90% | Walk a backward causal chain to the root cause |
| C5 Temporal-causal | 90% | 90% | Order events on a causal chain |
| C6 Lesson transfer | 20% | 30% | Cross-task analogy through meta edges — still an open limitation |
| Overall | 78% | 65% | All C1-C7 classes weighted equally |
Fact recall, where mem0 wins
These suites measure atomic fact extraction and recall. causal-memory is competitive but does not lead, and two of these numbers need context: LongMemEval-S compares a single-model stack against a platform stack, and the official 94.4% has an independent reproduction at 73.8%.
| Capability | causal-memory | mem0 / baseline | What it tests |
|---|---|---|---|
| LoCoMo (strict judge) | 79.1% | 91.6% | mem0's home turf — atomic fact extraction and recall |
| LongMemEval-S | 76.4% @ 11.5K tok/q | 94.4% official · 73.8% independent repro | Single-model stack vs a platform stack; not a like-for-like number |
| Memora MPA | 67.4% | 71.8% | −4.4pp; fact-heavy multi-session recall |
| Compaction survival | 100% | 45% | Recall after 5x context compaction; the causal table lives outside the window |
| Agent repeat-mistake | 33% | 67% | −34pp on trap-world: how often the agent repeats a known-bad action |
What the difference looks like in practice
Use mem0 when the question is 'what is true about this user?'. Use causal-memory when the question is 'what happened last time we did this, and what stopped it from being worse?'. Running both is a legitimate answer: fact recall in mem0, decision edges in causal-memory, each queried for what it is actually good at.
- Both systems can be mounted at once. Nothing in causal-memory requires you to remove an existing memory layer.
- The comparison is about the stored object, not about which project is better engineered.
- Every claim about the competitor on this page is either a public product fact or a row from the causal-memory README differentiation table.
mem0 questions, answered plainly
- Is causal-memory a drop-in replacement for mem0?
- No. The stored object is different. mem0 stores and retrieves facts; causal-memory stores facts plus typed decision → outcome edges. If you replace mem0 with causal-memory and keep asking fact-recall questions, you will get worse answers — 79.1% vs 91.6% on LoCoMo.
- Why is LoCoMo lower if causal memory is supposed to be better?
- Because LoCoMo measures atomic fact extraction and recall, which is exactly what mem0 optimises for. causal-memory's write path distils decisions and outcomes, so some fact detail is traded away. The capabilities causal-memory is built for — C2 intervention, C4 inhibition, C7 update — are not measured by LoCoMo at all.
- Can I run both at the same time?
- Yes, and that is the recommended migration path. Keep mem0 for facts, add causal-memory as an MCP server for decision edges. They do not share state, so neither can corrupt the other, and you can evaluate the causal side on real incidents before deciding whether it earns its place.
- Do I have to migrate existing mem0 memories?
- Facts can be re-recorded through record_fact, one of the 17 MCP tools. Causal edges cannot be migrated, because they have to come from real decisions and real outcomes — a fact export does not contain the reasoning that makes an edge useful. Start recording from today and let the graph grow.
- What does a prevented edge actually change?
- It spreads negative activation (−0.3). When the agent asks what would happen if it skipped the test suite, the outcome that was prevented by adding tests ranks below neutral instead of being silently filtered out or ranked alongside positive outcomes. That is the difference between 'I don't know' and 'that specifically goes wrong'.
Related
Use case
- Causal memory for a coding agentA coding agent already remembers the diff. Causal memory makes it remember why the diff was wrong the first time.
- Causal memory for an on-call agentAn incident timeline records what happened. Causal memory records which mitigation actually prevented the worse outcome — and which one only looked like it did.
Integration
- causal-memory with Claude CodeClaude Code already reads your repository. Give it the one thing a repository cannot store: why a decision was made, and what it prevented.
- causal-memory with CursorThe same repository, the same compaction problem. Cursor gets a causal record that survives the context window.
Try causal-memory next to mem0
It installs as an MCP server, stores everything in one SQLite file, and does not require you to remove whatever you already use for facts.