code-review-graph is a local-first CLI and MCP server that parses your repository into a structural graph so AI coding agents read only the files a change actually touches, and it added roughly 355 stars in a day on the way to 20,342 total. The pitch is narrow and testable: instead of letting Claude Code, Cursor or Codex re-read half your codebase on every review question, the graph answers with a targeted slice, which the project's own benchmark puts at a median 82x fewer tokens per question across six real repositories. Installing it takes two commands and about ten seconds of indexing on a 500 file project.

  • Two commands to working. pip install code-review-graph then code-review-graph install auto-detects your AI tools and writes the MCP config for each one.
  • It is genuinely local. The graph is a SQLite file in .code-review-graph/, there is no external database, no cloud service and no telemetry. Vector embeddings are optional and opt-in.
  • Review is the niche, not search. Blast-radius analysis traces every caller, dependent and test affected by a change, which is the multi-hop question grep is bad at.
  • The maintainer publishes the weak spots. Search ranking sits at MRR 0.35, flow detection at 33% recall, and the headline recall figure is openly labelled a circular upper bound. That honesty is rarer than the benchmark.
The code-review-graph pipelineA repository is parsed by Tree-sitter into a SQLite graph, queried for blast radius, and returned to the AI agent as a minimal review set. PIPELINE Whole repo in, only the files that matter out Repository tracked files Tree-sitter AST parse SQLite graph nodes + edges calls, imports, tests Blast radius what breaks Minimal set to your agent over MCP Incremental update on save: diff changed files, find dependents by SHA-256, re-parse only those. 2,900 files re-index in under 2 seconds genztech.blog
Fig 1 Tree-sitter parses once, SQLite persists the graph, and the agent gets a slice instead of the corpus.

What is code-review-graph and why is it trending?

The problem it targets is boring and expensive. When you ask an AI assistant to review a change, it has no persistent model of your codebase, so it greps, opens files, follows imports and burns context rediscovering structure it worked out yesterday. On a large repo that is most of your token spend and most of your latency.

RelatedSuperpowers Setup: Give Your AI Coding Agent a Real Workflow

code-review-graph parses your repository once with Tree-sitter into nodes (functions, classes, imports) and edges (calls, inheritance, test coverage), stores that in a SQLite file, and exposes 30 tools over the Model Context Protocol. When a file changes, it walks the graph to find every caller, dependent and test that could be affected, and hands the agent that list. The repo went up 355 stars in a day, is MIT licensed, and shipped v2.3.7 on July 18, 2026, which is a fast release cadence for a project created in February.

Parser coverage is unusually broad for a tool this young: Python, JavaScript, TypeScript and TSX, Go, Rust, Java, C and C++, C#, Ruby, Kotlin, Swift, PHP, Scala, Solidity, Dart, Elixir, Zig, plus Jupyter and Databricks notebooks. If your language is missing you can add it with a languages.toml file rather than forking.

Token reduction per repositoryBar chart of per-question token reduction across six benchmarked repositories, from 528x on fastapi down to 38x on httpx. BENCHMARK Per-question token reduction, whole corpus baseline vs graph query fastapi 528x this repo 93x gin 92x flask 71x express 41x httpx 38x Median across the six repos: 82x. The 528x figure is the best case, not the typical one. genztech.blog
Fig 2 · benchmark Reduction varies 14x across repositories, so treat the median as your expectation.

How do you install it on macOS or Linux?

Python 3.10 or newer is the only hard requirement. The quick start is two commands plus the initial parse:

# install the CLI (pipx works too)
pip install code-review-graph

# auto-detect your AI tools and write their MCP config
code-review-graph install

# parse your codebase
code-review-graph build

The install step is what makes this painless. It detects which AI coding tools you have, writes the correct MCP configuration for each, installs platform-native hooks or skills where supported, and injects graph-aware instructions into your platform rules. Supported targets include Codex, Claude Code, Cursor, Windsurf, Zed, Continue, OpenCode, Gemini CLI, Kiro and GitHub Copilot. Restart your editor afterwards. If you only want one platform:

code-review-graph install --platform claude-code
code-review-graph install --platform cursor
code-review-graph install --platform codex

If you have uv installed the generated MCP config will use uvx, otherwise it calls the code-review-graph command directly. Installing from a source checkout instead:

cd /path/to/code-review-graph
uv tool install . --force

How do you install it on Windows?

The pip install is identical, but there is a documented Windows gotcha worth reading before you file a bug. If Claude Code reports Invalid JSON: EOF while parsing or MCP error -32000: Connection closed, do not use a cmd /c wrapper in your config. Make sure fastmcp is at 3.2.4 or newer, then point the config at the executable directly and pass the UTF-8 flag through the environment:

"code-review-graph": {
  "command": "C:\\path\\to\\your\\venv\\Scripts\\code-review-graph.exe",
  "args": ["serve", "--repo", "C:\\path\\to\\your\\project"],
  "env": { "PYTHONUTF8": "1" }
}

How do you confirm the graph is actually working?

Build it, then check the stats. A 500 file project indexes in roughly ten seconds. After that, either watch mode or your editor's hooks keep it current:

code-review-graph status            # graph size and health
code-review-graph update --brief    # re-parse changes, print savings panel
code-review-graph watch             # continuous updates as you work

The clearest proof is the token savings panel. detect-changes --brief is read-only and takes about a second, querying the existing graph. update --brief re-parses changed files first and takes about five seconds, which is what you want after a rebase:

code-review-graph detect-changes --brief
code-review-graph detect-changes --brief --verify

The --verify flag cross-checks the displayed numbers against OpenAI's cl100k_base tokenizer and needs pip install tiktoken. The project's calibration data puts the estimate within about 1% of real GPT-4 tokens across 222 sample files, which is the kind of claim you can actually falsify on your own repo.

If your editor does not support hooks, run the daemon instead and let it keep multiple repos fresh in the background:

crg-daemon add ~/project-a --alias proj-a
crg-daemon start
crg-daemon status

To see it in CI, the same analysis runs as a composite GitHub Action that posts one sticky risk-scored comment per pull request, updated in place on each push. The graph is built on your own runner, so no source leaves CI:

# .github/workflows/code-review-graph.yml
on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: tirth8205/[email protected]
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

How does it compare to Serena, claude-context and repomix?

These solve adjacent problems and the maintainer's own comparison is refreshingly non-promotional about it. The short version: Serena is better if you want symbol-precise editing, claude-context is better if you want semantic search and are happy running a vector store, and repomix is simplest if your repo fits in a context window whole.

Relateddcg Setup: Block Destructive Commands From AI Coding Agents

code-review-graphSerenaclaude-contextrepomix
ApproachTree-sitter AST to structural graphLSP-backed symbol retrievalChunk and embed semantic searchPacks whole repo into one file
PersistenceSQLite, incrementalLanguage-server state plus memoriesVector index in a vector DBNone, regenerated per run
External depsNone for the coreA language server per languageEmbedding provider plus vector DBNode.js
Review focusBlast radius, risk scoring, test gapsGeneral agent toolkitSearch-focusedOne-shot context packing

Against plain grep the split is clean. Grep wins one-hop lookups. The graph wins multi-hop questions: impact radius, callers of callers, which tests cover this, which execution flows a change touches. Against a language server, LSP stays more precise per symbol; the graph's advantage is one persistent cross-language index that survives sessions and models edges no single LSP server sees.

What are the gotchas before you rely on it?

The README's limitations section is the most useful part of the project, and it argues against the tool in places most repos would stay quiet.

First, the accuracy headline is softer than it looks. Blast-radius analysis recovers every file in the ground truth on all 13 evaluation commits, but the ground truth is derived from the same graph the predictor walks, so recall 1.0 is circular by construction and should be read as an upper bound. Average F1 is 0.714 and average precision is 0.578, meaning it over-flags files on purpose.

Second, small changes can cost you tokens rather than save them. On express, graph context exceeded a naive file read for trivial single-file edits, because the response carries impact-radius metadata a one-line diff does not need. Repos under a few hundred files are explicitly not the target.

Third, two subsystems are weak and labelled as such: keyword search ranks at MRR 0.35, and flow detection sits at 33% recall with JavaScript and Go noticeably behind Python and PHP. Finally, if you enable cloud embeddings you are sending identifiers, signatures and a bounded docstring summary to that provider. Function bodies are not transmitted, the warning is on by default, and local embeddings via sentence-transformers avoid the question entirely.

What to watch · 2026
  • Co-change benchmark numbers. The honest evaluation mode grades against files the author actually touched in the same commit. Those numbers are promised but not yet published, and they will be lower than 0.71 F1. That is the figure to judge the tool on.
  • Search ranking. MRR 0.35 is the weakest published metric. If it climbs, the tool stops needing an agent to compensate for bad retrieval.
  • Whether MCP-native indexing eats this category. Editors are adding their own persistent code indexes. A standalone graph has to stay meaningfully better than the built-in.

Our take

This is worth installing if your repo is large, and worth skipping if it is not. That sounds like a hedge; it is actually the tool's own guidance and the reason we trust the rest of its numbers. A project willing to publish a precision of 0.578, an MRR of 0.35 and a paragraph explaining why its own best metric is circular is a project whose 82x median is probably real.

The install experience is the genuinely impressive part. One command detecting fourteen different AI coding tools and writing correct MCP config for each, with a symmetric uninstall --dry-run that touches only its own files, is more operational care than most MCP servers show. The failure mode we would watch for is trust drift: an agent handed a confidently scoped file list will not go looking for the file the graph missed, and precision of 0.578 means over-flagging today but says nothing about the edge it never modelled. Use it to cut waste on big reviews, not as a guarantee that nothing outside the blast radius matters.

Primary sources

Original analysis by GenZTech. Commands verified against the project README at github.com/tirth8205/code-review-graph.