CodeGraph

Watch a coding agent answer a question about an unfamiliar repository and you will see it grep, read a file, grep again, read three more, and burn several thousand tokens rediscovering structure that never changes between runs. CodeGraph pre-indexes that structure into a local knowledge graph and hands the agent the answer in one call. Its own measurements across seven real codebases: 88% fewer tool calls, 62% fewer tokens, 44% cheaper. It is MIT, it is 100% local, and it works with nine different agents because it is an MCP server.

What it builds

Three layers, and the first one is not an LLM.

A native Rust kernel with tree-sitter grammars parses your source and extracts symbols, functions, classes and methods, plus the edges between them: calls, imports, inheritance. That goes into a local SQLite database with FTS5 full-text search under .codegraph/. A resolution pass then turns references into a real dependency graph, including framework-specific routing and cross-language bridges such as Swift to Objective-C and React Native.

It covers 31 languages and 17 frameworks, and keeps itself current with native OS file watchers, FSEvents on macOS and inotify on Linux, on a two-second debounce. You are not re-indexing manually.

The parallel with other indexing work we have covered is worth drawing: like PageIndex's Flash mode, the expensive structural work is done with deterministic parsing rather than a model, and the model only consumes the result. That is a pattern showing up repeatedly this month.

The numbers

Measured across seven real-world codebases with an agent answering architecture questions, author-reported.

The worked example is the VS Code repository: 58 seconds and 2 tool calls with CodeGraph, against 2 minutes 10 seconds and 28 calls without. The zero-file-reads row is the one that explains the rest. If the graph answers the question, the agent never opens a file, and every downstream number follows from that.

The tradeoff it publishes

This is the part that earns the project trust. CodeGraph documents a cost, not just savings: "CodeGraph's responses leave about 80% more retrieval context resident at the end of a session" than a file-reading approach in multi-turn work.

So you use fewer tokens getting each answer, and more of your context window stays occupied by graph results across a long session. Good for throughput, harder on a small context window. A project that publishes the metric that cuts against its own headline is a project reporting rather than marketing.

Coverage is uneven too, and stated: Spring framework routing reaches 83.3% while Django manages 74.1%, because reflection and dynamic dispatch defeat static analysis. Objective-C is marked partial support. Liquid and Pascal sit at 73.8% and 77.4% cross-file coverage.

Why it works with nine agents

CodeGraph integrates as an MCP stdio server, and its supported list reads like a census of this series: Claude Code, Cursor, Codex CLI, opencode, Hermes Agent, Gemini CLI, Antigravity IDE, Kiro and GitHub Copilot across VS Code, CLI and JetBrains.

That is the point worth pulling out. We have spent this series documenting harnesses that will not load each other's plugins, where a plugin written for one is worth nothing to another. CodeGraph reaches all nine of those agents without writing nine integrations, because MCP standardised the tool boundary even though nothing standardised the extension boundary. The agent-agnostic tooling layer is thriving precisely where a shared protocol exists.

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh
# or
npm i -g @colbymchenry/codegraph

codegraph install   # auto-detects agents and wires the MCP server
codegraph init      # build the index, run once per project

The installer configures each detected agent's MCP settings for you, which removes the fiddliest part of adopting any MCP server.

Local, and it means it

The privacy claim is unusually flat: "No data leaves your machine. No API keys. No external services. SQLite database only."

For a tool whose entire job is reading your proprietary source code, that sentence is the difference between adoptable and not. Compare claude-mem, which defaults to a hosted memory service and needs a flag to stay local. Same category of tool, opposite default.

Who should install it

Install it if your agent works in a large or unfamiliar codebase, if you pay per token and the bill is visible, or if you have watched an agent spend two minutes rediscovering your module layout for the fourth time today. The savings scale with repository size and with how little the agent already knows.

Skip it on a small project an agent can hold in context anyway, where the index is overhead for no gain. And check your framework in the coverage table first if you are on Django, where dynamic dispatch limits what static analysis can see.

Sources and further reading

• CodeGraph on GitHub
• Documentation, benchmarks and the coverage tables

Ten minutes: install it, run codegraph init in your largest repository, then ask your agent an architecture question you already know the answer to. Count the tool calls. That number, on your code, is the only benchmark that matters here.

Tested on: not independently tested. Every performance figure, the seven-codebase benchmark, the context-residency tradeoff and the framework coverage percentages are author-reported in the project's own documentation, with no independent replication. Install commands and the local-only claim are quoted from the same source. Repository statistics were read from the GitHub API on the date below.
Date checked: 2026-09-30