tokensave vs codegraph: which code index saves more?

Part of the reduce Claude Code token usage pillar. This page is the head-to-head: two MCP servers that solve the same problem in almost the same way, and diverge on the things that turn out to matter.

Is tokensave or codegraph the better code index?

codegraph if you want a number you can check; tokensave if you want the wider language net and a compiled binary. They are closer than any other pair in this category — both build a symbol index with tree-sitter, both serve it over MCP, both stay out of your shell — so the choice comes down to two things neither README leads with: what each one has actually published about its savings, and how much of your context they were never going to touch. I maintain an open token optimizer benchmark and I sell a competing tool, so treat the ranking as an opinion and the mechanism as the thing to check. The mechanism is where this comparison is decided.

What does codegraph actually do?

It builds a knowledge graph of your code and lets the agent query it instead of reading files. tree-sitter parses the source, the symbols land in an FTS5 SQLite index, and the MCP server exposes impact analysis, call graphs and symbol lookup. Twenty-plus languages, fourteen frameworks, and a file watcher that keeps the index current. Three things set it apart in practice:

It ships a bundled Node.js runtime. No version juggling, no virtualenv, cross-platform out of the box. The installer detects eight agents — Claude Code, Cursor, Codex, opencode, Hermes, Gemini, Antigravity, Kiro — and wires the MCP config itself.
Framework-aware routing covers some genuinely rare ground, Drupal and Vapor included, not just the React-and-Django default set.
The watcher is debounced and honest about staleness. When files are pending re-index it says so in a banner, so the agent knows its answer may be behind the working tree. That is a small design decision with an outsized effect: a silent stale index is worse than no index, because the agent trusts it.

And it publishes a benchmark: −35% cost and −71% fewer tool calls, median across seven repositories. That is the strongest published claim in this whole category, and the tool-call figure is the more interesting half of it.

What does tokensave actually do?

The same job, in Rust, across a wider language set. tree-sitter extraction into a libSQL knowledge graph with FTS5, 34 languages, and 48 MCP tools — a much larger surface than codegraph exposes. Where it pulls ahead:

Compiled, so it starts fast and stays small. No Python, no Node, no runtime to install. Homebrew on macOS, Scoop on Windows, prebuilt binaries otherwise.
Multi-branch indexing. It can diff and search across branches without switching your checkout. Nothing else in this category does that, and if you review other people's branches it removes a whole class of context-burning git checkout round-trips.
Subprocess isolation. One parser crashing on a malformed file does not take the service down with it — which matters more than it sounds like when 34 grammars are in play.
Atomic edit primitives with AST rewriting. The agent renames a symbol through the tree rather than through a regex, which sidesteps the shell-quoting and partial-match hazards that make agentic edits go wrong quietly.

What it does not have is a number. There is no published benchmark, so the savings are unquantified. That is not an accusation — most tools in this category have no number either — but it is a real difference when the competing tool does have one.

Where does the token saving actually come from?

From tool calls, not from compression. Neither of these tools compresses anything. They replace a behaviour: instead of the agent reading four files to find where a function is used, it asks the index and gets a list. That is why codegraph's −71% tool calls is the figure to read, and its −35% cost is the figure to be careful with. Fewer tool calls is a direct, mechanical consequence of having an index — you can verify it in a single session. Cost is downstream of that and depends on what the agent does with the time it saved, which is why the same tool can show large variance across runs. codegraph's own numbers show a four-run spread on Tokio. On my long-session benchmark, codegraph shows no measurable cost saving — sessions end up costing about what they cost with no tool at all. tokensave has not been through it. Those two results are not the same claim, and I would rather say "unmeasured" than imply a verdict I have not earned. The reconciliation between −35% and break-even is not that one of us is wrong. It is that a symbol index reliably removes navigation reads and reliably does nothing about the other channels — and on a long session, the other channels are most of the bill.

What do both of them miss?

Everything that is not a file read. This is the honest limitation of the whole code-index category, and it is identical for both tools:

Command output. cargo test, npm install, git diff, a stack trace — all of it still reaches the model at full size. Neither tool sits on that path.
Whole-file reads that survive the index. The agent still opens files to edit them. An index tells it which file; it does not shrink the file.
MCP manifests. Every connected server ships its tool definitions before your first message. tokensave's 48 tools are themselves a standing input cost on every turn, paid whether you call one or not — the price of that surface area.
Re-reads. The same file entering context four times in one session costs four times. An index reduces the odds; it does not deduplicate.

If your sessions are terminal-heavy — a build loop, a test loop, an infrastructure loop — a code index is optimising the channel that was already the smaller one for you. That is worth knowing before you attribute a disappointing invoice to the wrong tool.

Which one should you pick?

Pick codegraph if you want the lowest-friction install, you work in a framework its routing knows well, and you would rather have a published number to argue with than a longer feature list. The bundled runtime and the eight-agent installer make it the easiest thing in this category to put in front of a team. Pick tokensave if your stack reaches past twenty languages, you want a single compiled binary with no runtime, or multi-branch search maps onto how you actually review code. The atomic edit primitives are a real safety improvement on any agent that edits through shell commands. Pick neither, yet, if you have not looked at where your tokens go. Run ccusage or your agent's own usage panel for a week first. If most of your spend is command output, an index will not move it, and you will have concluded the wrong thing about a tool that was working correctly. They also compose. Nothing stops you running a code index alongside a tool-boundary filter, because they intervene at different points and neither rewrites what the other produced.

How to apply this today

Count your tool calls, not your tokens, for one session. It is the metric a code index actually moves, and it is the one you can verify yourself in an afternoon.
Check the language and framework coverage against your real repository, not against the headline count. Thirty-four languages does not help if the one you use is served by a thin grammar.
Watch for staleness. Both tools index; only one of them tells you when the index is behind. Whichever you pick, know how you would find out.
Audit the channels the index does not cover before deciding the tool disappointed you.

What goes wrong (anti-patterns)

Reading −35% as a promise. It is a median over seven repositories with visible run-to-run variance, published by the vendor. It is a good-faith number and it is still a sample. Treating "not benchmarked" as "does not work". tokensave has no published figure. That is a gap in the evidence, not evidence of a gap. Stacking indexes. Two symbol indexes over the same repository double the MCP manifest cost and answer the same question twice. Pick one. Leaving the index connected for work that never queries it. A large tool surface is paid on every turn. If a session is pure terminal work, disconnecting is free money.

See also: