Every time I use an AI coding agent, I see the same thing happen:
It reads way more code than it actually needs.
I give it a simple question about a function, and suddenly it's searching through multiple files, opening entire source files, and filling the context window with tokens that have nothing to do with the answer.
That made me wonder:
How much token usage could I eliminate just by helping the agent find the right code faster?
So I tested codebase-memory-mcp on a real task in my Go codebase, git-lrc.
The task was simple:
Find and understand
ProcessReview.
The result surprised me.
The task
ProcessReview lives in:
internal/review/service.go
The file contains:
- 844 lines
- 29,926 bytes
- roughly 7,500 tokens
The ProcessReview function itself is 235 lines, around 2,300 tokens.
Normally, AI would start with something like:
grep -C 2 "ProcessReview" .
That gave me 24 matches across 7 files.
With context included, that was roughly 6 KB of output.
Then AI had to figure out:
- which match was the actual implementation
- which matches were callers
- which files were relevant
- where exactly the function started and ended
This is the part that feels harmless when I'm doing it manually.
For an AI agent, though, every file it opens becomes additional context.
Then I tried codebase-memory-mcp
Instead of searching the repository as plain text, I asked the knowledge graph:
search_graph("ProcessReview")
The result was essentially:
ProcessReview
internal/review/service.go:144-378
5 callers
19 callees
That's it.
It immediately told me:
the exact function, the exact location, and its relationships.
No seven files. No 24 grep matches. No guessing which result mattered.
The token difference was huge
The traditional discovery step was roughly 1,500 tokens.
The graph lookup was around 50 tokens.
That's approximately a 97% reduction — but only for the discovery step.
The graph isn't compressing my code. It's compressing the process of finding my code.
That's a very different claim.
Reading the actual function
After finding the exact location, I used:
get_code_snippet
It returned the ProcessReview function itself — around 2,300 tokens.
The code still has to be read. codebase-memory-mcp doesn't make 2,300 tokens of Go code disappear.
What it does is prevent me from reading the other ~5,200 tokens of the file when I don't need them.
This is where the real savings are
Imagine two workflows.
Without the graph
grep
↓
24 matches
↓
inspect 7 files
↓
open service.go
↓
find ProcessReview
↓
read function
With the graph
search_graph
↓
service.go:144-378
↓
read ProcessReview
The second workflow removes most of the unnecessary context.
And that's exactly the problem I wanted to solve:
"How do I stop the agent from reading code it doesn't need?"
What I actually saved
For this single task:
| Approach | Tokens |
|---|---|
| Grep + full-file read | ~9,000 |
| Search graph + function snippet | ~2,500 |
| Savings | ~70% |
Almost all of that saving came from not opening the entire file.
The honest claim is:
It dramatically reduces the tokens required to discover the code you actually need.
My takeaway
The biggest benefit of codebase-memory-mcp isn't token compression — it's navigation.
AI coding agents are very good at reading code. The problem is that they sometimes read too much of it.
A knowledge graph gives the agent a way to answer:
Where is the thing I'm looking for?
before it starts consuming thousands of tokens on irrelevant files.
Conclusion
This was only half of my experiment.
Tomorrow I'll test the other tool which helps in boosting agent workflow.
Thanks for reading!
If you are interested, you can check out my tool, MakeSense, which turns public GitHub pull requests into concise summaries, prioritized insights, and interactive quizzes.
It's free, unlimited, and source-available.
If you review open-source code, I'd love for you to give it a try and share your feedback.
MakeSense: makesensegithub.com
Top comments (0)