This is a selection: the project's own table runs to twenty-two rows. Beyond what is shown here sit Objective-C at 91.6%, Scala at 91.2%, Svelte at full coverage, plus Vue, Astro, Lua and Luau. And that is also where the bottom of the range lives, absent from the selection above: Liquid on a Shopify store gives 73.8%, Pascal and Delphi 77.4%.
The project does not hide the residual and explains it: runtime dynamic dispatch, reflection, dependency-injection containers, framework-convention entry points, vendored code. An honest frontier of static analysis, not a gamed denominator.
What to look at in that table is your language, not the average - a spread from 73 to 100 per cent is far too wide for an average to mean anything.
An index that does not fall behind
Every pre-built index has an inborn illness: it goes stale. The edit exists, the map does not know it, and the agent answers confidently from yesterday's code.
Here the file watcher catches changes through the operating system's native events and syncs exactly what changed. On a project of four thousand four hundred files that is about a third of a second of work; on the Swift compiler repository at twenty-seven thousand files, about four tenths. The tree is never re-scanned.
The delay before syncing is muddled in this project, and the code is the better guide than the README. In one place the README promises a trigger three hundred milliseconds after a lone save; in another it names a two-second debounce window. The second is right: the watcher source carries exactly two thousand milliseconds, overridable by an environment variable within a range from a hundred milliseconds to a minute. A burst of quick edits collapses into a single sync.
The difference from the usual approach is structural: the cost grows with the size of the change, not with the size of the repository. The project publishes a comparison against the fastest competing indexer across thirty-one repositories and thirty languages - two to seven times faster on medium and larger ones, and the gap widens as the project grows.
There is also a window between the save and the sync. Inside it the answer marks the file as pending and sends the agent to read the live file directly.
What the measurements show
The figures from the README: eighty-eight percent fewer tool calls, fifty-three percent faster, sixty-two percent fewer tokens processed, forty-four percent cheaper. Seven open-source repositories, re-measured in August 2026.
These are the project's own measurements, not an independent assessment. But the methodology is described more honestly than is customary: in the control arm the command line is blocked so that the agent "without CodeGraph" cannot accidentally find the installed CodeGraph through the shell.
Far more useful than the average is the spread. The saving turned out to track not the size of the repository but how much reconnaissance a question demands. Where the agent without the graph spent twenty-eight to forty-three calls, the saving was fifty-seven to seventy-eight percent. Where it got there in seven calls, the difference all but vanished.
Hence the practical conclusion: the benefit is counted on your questions, not on somebody else's average.
The number the project publishes against itself
And now the thing this project deserves separate respect for.
All the percentages above measure throughput: tokens processed, tools called, dollars spent to reach one answer. They say nothing about how much context is still sitting in the window afterwards. And on that axis CodeGraph does not win, it loses.
Across the same seven repositories in multi-turn sessions its responses leave roughly eighty percent more retrieval context resident than a file-reading agent's do. On the VS Code repository that is sixty-seven thousand tokens against eighteen.
The mechanism is the very one that makes it fast. CodeGraph returns one dense verbatim payload that answers the question - and then stays in the window. An agent with grep and file reads churns through many small results, and they get evicted.
Fewer tokens processed and a larger persistent footprint are two facts that are true at once, not a contradiction. If you work in long sessions inside a small window, budget for it up front.
The project could have said nothing about this. It not only said it but published the per-repository measurement as a separate document.
The condition without which there is no saving
There is a requirement that is easy to miss, and without it none of the above works.
The graph helps only when the agent queries it directly. If the model habitually hands reconnaissance to a sub-agent, and that sub-agent goes off to read files, CodeGraph becomes an extra layer on top of the same work - overhead rather than a replacement.
That is why the integration instructions explicitly steer agents to answer directly instead of delegating exploration to file-reading sub-agents.
Worth checking on your own setup: see whether the agent reaches for the graph or carries on with its old habits.
Installation, and three steps not to confuse
