A Tool Promising 99.2% Token Savings, and Why I Didn't Install It

Anyone using AI to edit code has hit the same wall.

You ask it to change a feature, and first it has to understand your project. It cannot take in the whole repository at a glance, so it opens one file after another. Once the project gets a bit large, the context fills up, tokens burn fast, and the answers start drifting — it forgets what it agreed to a moment ago.

I have a few projects I work on with AI daily, and I have fallen into this hole plenty of times.

So when I saw something called codebase-memory-mcp a few days ago, I paid attention.

Its idea: instead of letting the AI dig through files every time, parse the entire repository into a graph up front — which functions, which classes, who calls whom — and store it in a database. When the AI needs something it queries the graph instead of reading files.

The official example: 410,000 tokens compressed to 3,400. A 99.2% saving.

Seeing that number, I was genuinely tempted.

Then I looked at the scenario used for the demo: the Linux kernel. 28 million lines of code, 75,000 files.

The bigger the repository, the more this is worth doing. At 28 million lines, making an AI page through files is a disaster on its own, and 99.2% holds up completely.

The problem is that none of my projects are 28 million lines.

Here is the part that is easy to miss: what this class of tool saves is the overhead of an AI repeatedly opening files to find one thing. So the benefit is almost entirely determined by repository size. The smaller the repository, the smaller that overhead already is — one search, two files, a few seconds, not many tokens.

What it saves does not cover its entry cost.

There is another layer. Official numbers always come from the scenario the tool is best at. 410,000 down to 3,400 used the Linux kernel. That is not fraud — every tool markets this way, showing you the case with the largest gain.

The 99.2% is real. The denominator behind that percentage just is not my denominator.

In the end, the reason I did not install it was less about small savings and more about the shape of its cost.

It is a resident process. Once installed it does not start when you use it; it runs in the background continuously, syncing and rebuilding the index incrementally.

It also injects hooks and skills into your clients automatically. Which means it changes the default behavior of your existing tools without you participating.

The core is a precompiled closed-source binary, and installation rewrites several client config files.

Each of these alone is tolerable. Together they are what stopped me: it wants to read all of your code and build a complete structural map of it, while being closed source, resident in the background, and permitted to change your configuration.

To save some tokens, that is more trust surface than I can carry.

There are smaller things too. It officially supports 37 clients, including Claude Code but not Codex CLI, and there is no one-click installer on Windows. None of these matter alone, but stacked on top of a benefit that was never obvious, the scale tips clearly.

The cost of a tool is never just its price tag. How much background it occupies, how much invisible trust it asks for, whether you can open it up when something breaks — all of that is money.

This is not to say the tool is bad. On a 28-million-line repository it may be a genuine necessity — at that scale what it saves is not money but whether the AI can function at all.

What I gave up is also clear: the token savings. I accept that, without pretending otherwise.

I also wrote down when I would revisit it. Two conditions must hold together: a repository grows past several hundred thousand lines, and I start repeatedly needing to trace calls across modules, find dead code, and ask architectural questions. Note "repeatedly" — for an occasional need, digging myself is faster.

On that day I will connect one client only, not juggle two.

Most tool decisions can be read this way: before asking whether it is good, look at how far its demo scenario is from your real one. The further apart, the less that beautiful number has to do with you.

The hard question was never whether it is good. It is whether I am currently the person who gets its benefit.

Next time you see a stunning percentage, do not start with the ratio. Go find how big the denominator is.