How Mem0 Cut Claude Code's Memory Footprint by 97%

Claude Code is a staple for any developer working on a codebase. But most managers emphasize token-saving techniques to save on Claude tokens. However, this does not solve the problem of context wiping over sessions. Here is where Memory comes into play. It is said memory can save tokens, but we wanted to put it to the test.

We ran two experiments directly inside Claude Code, one session with memory using Mem0 and one without Mem0 on the same repo. We looked into answering two questions:

1. Footprint: How much context does memory actually cost, measured through Claude Code's own /context command rather than a vendor-reported number.

2. Recall: Does a preference stated once, mid-conversation, survive a hard context boundary /clear, without being written down anywhere.

If you haven't set up Mem0 in Claude Code yet, the step-by-step setup guide covers installation via the plugin marketplace. This post is the data: what changes once it's running.

Experimental setup

Both experiments used Claude Code v2.1.209 with the Mem0 plugin installed via the plugin marketplace, so lifecycle hooks were active alongside the MCP server.

Experiment 1 ran against an existing project with 26 memories already stored from earlier sessions. While, Experiment 2 ran against a separate demo project, deliberately including a /clear between the setup prompt and the test prompt to simulate a session with zero shared history.

Experiment 1: Memory injection and token saving

We ran two Claude Code sessions with an existing repo side by side, such that one had access to Mem0 and the other did not. The one with Mem0 had access to 26 existing memories from earlier work on the project.

Both terminals were passed the same prompt, and here are the results with and without Mem0:

The session without Mem0 worked it out from scratch by listing directories, running a shell command, cross-referencing test files across both SDKs, and finding gaps in the repo. The Mem0 session answered with a more specific breakdown in fewer steps. However, both answers were accurate, but the Mem0 session got there faster because it wasn't starting from zero.

We then asked both sessions to close one of those gaps and write a full unit test suite for the Qdrant backend in TypeScript, including mocking a client and covering CRUD, filter translation, and initialization edge cases. The output quality was comparable, but the Mem0 session's suite additionally covered migration-helper functions (getUserId, setUserId) that the other session's suite skipped.

Here's what the /context command showed after that two-part task, on identical footing otherwise:

Let's check the numbers for this experiment:

The gap comes down to how each approach loads context. Without Mem0, the session was drawing on three loaded memory files totaling 13.7k tokens, while Mem0 retrieves only the memory chunk(445-token slice) that the current query actually needs. This helps us to save on tokens and add context to every new session at the same time. That's roughly a 97% smaller memory footprint for the same task, on the same repo, with equivalent output quality.

Experiment 2: Does a preference survive a full context wipe?

In this experiment, we set out to find the answer to “whether a preference would survive a full context wipe or not?”

Token savings only matters if the retrieved information is useful. So, we tested recall directly using /clear command to simulate a test case with a completely fresh session with zero shared history.

In the first session, we asked Claude to write a function, followed by our preference to write functions with standard for loops instead of using a list. With the Mem0 plugin active, Claude Code wrote the function as per our preference.

We then ran /clear command, wiping out all context and started a new session. We then passed a completely unrelated prompt to Claude. Without memory, this is a coin flip at best. The new session had no way to know a preference existed in a conversation it can no longer see, so a generic answer defaults straight to a list comprehension. With Mem0 connected, Claude opened with an explicit for-loop, unprompted, and recalled our preference without any preference being explicitly mentioned in the prompt.

The result

The two experiments show two properties of Mem0, i.e, Retrieval and Recall.

Retrieval is per-query. Without a memory layer, the alternative is usually to dump everything into the context window up front, most of which the current task never touches. Mem0 instead pulls back only the slice relevant to what's actually being asked, so the token cost scales with the query rather than with however much has accumulated in memory over time.

Recall is the other half, and it's what Experiment 2 actually tested. Here's how many tokens that retrieval difference actually cost us:

Conclusion

The above two experiments explain the mechanism behind Mem0, not anything specific to Claude Code. Mem0 searches a stored memory index and injects relevant chunks into the prompt rather than dumping a session state file into the context window at the beginning of the session. That's the direct cause of the footprint difference in Experiment 1, i.e, 13.7k tokens loaded unconditionally, versus 445 tokens pulled on demand.

The /clear command wipes the model's context, but not Mem0's stored memories, which live on Mem0's platform and stay reachable through the MCP server no matter what's in the current session. That's why the convention in Experiment 2 survived the wipe, as it never depended on the context window in the first place.

Mem0's latest algorithm uses single-pass, ADD-only extraction with multi-signal retrieval, combining semantic similarity, keyword matching, and entity linking. That's a separate reason retrieval tends to surface the right memory instead of a stale or contradictory one, though we didn't specifically stress-test that in either experiment here.

Frequently Asked Questions

Q: Is this the same as Mem0's published LoCoMo/LongMemEval benchmark numbers?

No. Those are third-party evaluation benchmarks Mem0 reports on its own research page. This post is a direct, first-party test inside Claude Code on real repos, not a benchmark run.

Q: Can I reproduce this myself?

Yes, the setup is the plugin marketplace install from the setup guide, plus running /context before and after a task, with and without the plugin connected. The /clear recall test just needs two prompts and a convention Claude hasn't seen before.

Q: Does this mean I should delete my CLAUDE.md / AGENTS.md files?

Not from this data. We didn't test a Mem0-vs-markdown-file comparison here — the baseline in both experiments was simply "no memory layer connected." Whether Mem0 should replace, supplement, or import an existing CLAUDE.md is a separate question this post doesn't answer.

Q: Why did the two test suites in Experiment 1 have different test counts?

The session without Mem0 wrote three test categories (CRUD, filter translation, initialization) totaling 31 tests. The Mem0 session wrote four categories, adding migration-helper coverage (getUserId, setUserId) the other session skipped entirely, while still landing at a lower total. It covered more ground with fewer, more consolidated test cases per category rather than enumerating every case separately, which points to the Mem0 session drawing on precedent for how tests are usually structured in that repo instead of building each case from scratch.

Q: Does the token savings number change with a bigger memory store?

The Mem0 session in Experiment 1 was already holding 26 memories; a project with thousands of memories could retrieve a different amount depending on how many chunks are relevant to a given query. We're not extrapolating a slope from a single data point.

References:

• Add Persistent Memory to Claude Code with Mem0 (5-Minute Setup)

• Mem0 Claude Code Integration Docs

• Mem0 Platform

• Mem0 GitHub