Code-Review-Graph: Can a Local Code Graph Cut AI Coding Costs?

AI coding agents are improving quickly, but repository-scale work still has an expensive weakness: context. Before an assistant can review a pull request, trace a dependency, or estimate the blast radius of a change, it may inspect many files that are only loosely related to the task.

code-review-graph is an open-source attempt to reduce that waste. It creates a persistent local graph of functions, classes, imports, calls, inheritance relationships, tests, and other code structure. Compatible agents can query that graph through the Model Context Protocol instead of rebuilding a mental model of the repository during every session.

The project is MIT licensed, distributed through PyPI, and currently requires Python 3.10 or newer. Its documentation lists integrations for tools including Codex, Claude Code, Cursor, Windsurf, Zed, Continue, OpenCode, Gemini CLI, Qwen, Kiro, and GitHub Copilot.

The verdict

code-review-graph is a credible example of an emerging category: reusable context infrastructure for AI coding agents.

It is most relevant for medium and large repositories, repeated pull-request reviews, monorepos, and developers who switch between several MCP-compatible clients. It is much less compelling for small projects where the relevant code already fits comfortably inside the model context window.

The central limitation is evidence. The project publishes substantial context-reduction benchmarks, but those are author-produced results—not an independent guarantee for every repository. Treat the numbers as a reason to run a controlled test, not as a universal savings estimate.

What the project actually does

The core workflow is straightforward:

1. Tree-sitter and targeted parsers analyze the repository.
2. The resulting structure is stored locally in SQLite.
3. Functions, classes, imports, calls, inheritance, tests, and related entities become graph nodes and edges.
4. File changes can be processed incrementally rather than rebuilding the complete graph.
5. An MCP server exposes compact repository context to compatible AI clients.
6. Review-oriented tools calculate change impact and the likely blast radius.

The project includes commands for building, updating, watching, querying, and visualizing the graph. It can also export graph data in formats such as JSON, GraphML, SVG, Obsidian, and Neo4j Cypher.

For code review, the documented workflow centers on commands such as:

• /code-review-graph:build-graph to build or rebuild the graph;
• /code-review-graph:review-delta to examine changes since the previous commit;
• /code-review-graph:review-pr for pull-request analysis with blast-radius context.

The exact integrations and command surface may change between releases, so verify the current README before automating it across a team.

Why a structural graph can help

Plain semantic search retrieves files or chunks that look textually similar to a query. That is useful, but source code contains relationships that similarity alone can miss.

Imagine a change to an authentication function. The most relevant review context may include:

• every caller of the changed function;
• imported permission and session utilities;
• interface implementations that share the same contract;
• tests covering the affected path;
• downstream services inside the change's blast radius.

A structural graph makes those relationships explicit. Instead of repeatedly searching the repository, an agent can request a dependency-oriented slice and then read the smaller set of files most likely to matter.

This does not replace semantic search, a language server, tests, or model reasoning. It adds a navigation layer that may make those systems more efficient.

Installation

The official quick-start flow is:

pip install code-review-graph
code-review-graph install
code-review-graph build

The documentation also suggests pipx as an isolation-friendly installation method. The installer can detect supported coding tools and write MCP configuration for them.

Before running an automated installer inside a production repository:

• use an isolated Python environment or pipx;
• run installation against a disposable repository first;
• review every generated configuration file;
• back up existing MCP, editor, and agent configuration;
• commit configuration changes separately so they are easy to audit and revert.

The project also documents an uninstall command. That matters because developer-tool installers frequently modify several configuration locations, and removal should be as predictable as setup.

Local-first does not mean the whole workflow is local

The repository graph and SQLite database are local. That is a meaningful advantage for private codebases because the indexing layer does not require a hosted code-search service.

However, the connected coding agent may still send prompts and retrieved code to an external model provider. The real privacy boundary therefore depends on both layers:

• where code-review-graph parses and stores repository data;
• where the selected AI client sends the context returned by the graph.

Optional embedding providers also deserve review. Local embeddings preserve a different data boundary from cloud embeddings. For sensitive repositories, document which optional components are enabled and where each one processes code.

Where it should provide the most value

Large and interconnected repositories

The harder a repository is to understand from filenames alone, the more useful a dependency graph becomes. Monorepos, mature applications, shared libraries, and service collections are stronger candidates than a small landing page.

Repeated pull-request review

A persistent graph is more valuable when the same repository is reviewed continuously. The initial indexing cost is then amortized over many reviews and agent sessions.

Multi-agent development

Because the graph is exposed through MCP, one local index can serve several compatible clients. A team can experiment with different agents without requiring every tool to maintain a completely separate repository map.

Metered API usage

Developers paying per token have the clearest incentive to eliminate unnecessary file reads. Even then, context reduction matters only when review quality remains equal or improves.

Where it can add unnecessary complexity

You may not need another context layer when:

• the repository is small;
• the task is isolated to one or two known files;
• your current coding client already maintains an effective index;
• the languages or file types you rely on are not parsed accurately;
• the team will not keep the graph current;
• configuration overhead costs more time than context retrieval saves.

A graph is not automatically better because it is more sophisticated. It is useful only when its representation matches the code relationships that matter in your work.

How to interpret the benchmark claims

The project advertises large token reductions across its evaluation repositories. Those results are promising, but they remain project-published benchmarks and can vary substantially with repository structure, language mix, review task, and agent behavior.

A useful internal evaluation should measure more than token count:

• total input tokens for an equivalent review;
• number of files and symbols retrieved;
• relevant defects found;
• missed dependencies;
• false-positive findings;
• review latency;
• graph build and update overhead;
• developer acceptance of the final recommendations.

Token reduction by itself is not success. A system that reads less code but misses an affected caller is cheaper and worse.

A practical one-week evaluation

Select one active repository and ten representative changes. Include a mix of bug fixes, refactors, dependency upgrades, and cross-module features.

Review every change twice:

1. with the team's current agent workflow;
2. with graph-assisted context enabled.

Record context size, duration, findings, and missed dependencies. Have a developer assess the final reviews without being told which configuration produced each one.

Also inspect the generated graph manually. Missing edges, stale indexes, unsupported syntax, and generated-code noise often explain quality differences more clearly than aggregate token numbers.

At the end of the week, decide using three questions:

• Did the graph reduce context or latency on real tasks?
• Did review quality stay equal or improve?
• Is the operational overhead low enough to keep it updated?

Alternatives and adjacent approaches

code-review-graph is one approach to repository context. Depending on the use case, compare it with:

• built-in indexing from AI editors;
• language-server symbol and reference search;
• repository maps generated by coding assistants;
• semantic code-search systems;
• static-analysis and dependency-analysis tools;
• dedicated automated pull-request review products.

Its differentiator is the combination of a persistent local structural graph, incremental updates, review-specific tools, and MCP compatibility across several clients.

Should you use it?

Use code-review-graph when an AI agent repeatedly spends time rediscovering a sizeable repository, particularly when you review pull requests with more than one compatible client.

Skip it initially for small codebases and narrowly scoped tasks. In those cases, the indexing and maintenance overhead may exceed the context savings.

For teams already spending meaningful money or engineering time on repository-scale AI review, the project deserves a measured pilot. Its architecture targets a real bottleneck, its MIT license lowers adoption friction, and the local graph is not tied to a single editor. The right next step is not blind adoption—it is a repository-specific benchmark.

OpenSourceChoice assessment

• License: MIT
• Distribution: Python package, CLI, and MCP server
• Storage: Local SQLite graph
• Best for: Medium-to-large repositories and recurring AI-assisted review
• Main advantage: Reusable structural context across multiple AI clients
• Main risk: Benchmark transferability and parser coverage require validation
• Recommendation: Run a controlled pilot on one active repository before team-wide rollout

Official sources

• GitHub repository and current README
• PyPI package metadata and release history
• Model Context Protocol documentation