Stop Burning Tokens: How a Knowledge Graph Makes Your Agent Understand Your Repo
There’s a pattern you’ve probably already seen your coding agent repeat. You ask it where a function is used. It does grep. Reads a file. Greps again. Opens three more files, reads them top to bottom, and twelve tool calls later gives you an answer—having burned a small fortune in tokens to rebuild something your IDE’s “find references” does instantly.
The problem isn’t the agent. It’s that the agent doesn’t have a map. In each session, it rediscovers your codebase from scratch, reading one file at a time.
codebase-memory-mcp, from DeusData, is a bet that this can be fixed. It indexes your entire repository into a persistent knowledge graph—functions, classes, call chains, HTTP routes, links between services—and exposes it to your agent through 14 MCP tools. Instead of doing grep and read, the agent queries a graph. The repo is around 20.9K stars and growing fast, which tells you the pain point is widely shared.
What it actually does
The pitch is speed and efficiency. It parses code with AST analysis via tree-sitter across 158 languages, powered with semantic type resolution based on LSP for the heavy hitters (Python, TypeScript/JavaScript, Go, Rust, C/C++, Java, Kotlin, C#, PHP). The result is a persistent knowledge graph in SQLite that survives between sessions—so your agent doesn’t start from zero each time.
Indexing is the headline. The project claims it full-indexes an average repo in milliseconds and the entire Linux kernel—28M lines, 75K files—in about three minutes, answering structural queries in under a millisecond. The RAM-first pipeline (LZ4 compression, in-memory SQLite) frees the memory once indexing is done.
A watcher thread in the background monitors file changes and reindexes only what changed, so the graph stays current without a full re-parse.
The tokens argument
This is the part worth reading carefully, because it’s the tool’s raison d’être. The project reports that five structural queries cost around 3,400 tokens through the graph versus about 412,000 tokens via file-by-file exploration—which they frame as roughly 120x fewer tokens. There’s also a preprint (arXiv:2603.27277) that describes benchmarks across 31 real repos, reporting 83% answer quality with about 10x fewer tokens and 2.1x fewer tool calls than file-by-file exploration.
It’s worth being clear: these are the project’s own numbers, and the arXiv paper is a preprint from the same team—not independent validation. Take them as a strong claim to test on your own repo, not as closed fact. That said, the mechanism makes sense: a single graph query really does replace dozens of grep/read cycles, and that’s something you can verify yourself in a single session.
Installation and scope
This is the part that makes it genuinely easy to try. Ships as a single static binary for macOS, Linux, and Windows—no Docker, no runtime dependencies, no API keys. You download, run install, restart your agent, done. The installer auto-detects and configures in 11 coding agents, including Claude Code, Codex CLI, Gemini CLI, Zed, OpenCode, Aider, and others—so it’s not an exclusive Claude Code play.
There’s also an integrated 3D graph visualization (in the UI variant) that lets you explore the knowledge graph in your browser on localhost—useful for actually seeing the shape of a codebase you inherited.
Is it worth it?
If you work on large or multi-service repos where your agent burns real money rediscovering the structure each session, this is a high-value experiment with low entry cost: a binary, an install command. The efficiency claims are self-reported and you should verify them on your own code—but the core idea, giving your agent a persistent map instead of making it re-explore each time, is that kind of do-more-with-less win that’s hard to argue with once you’ve felt the token bill.