How code-review-graph Reduces Token Usage by 65× Compared to Reading the Full Codebase

code-review-graph implements a structural knowledge graph workflow that queries only impacted code nodes, achieving a median 65× token reduction versus sending entire repositories to LLMs.

Traditional code review assistants exhaust context windows by dumping complete source trees into LLM prompts. code-review-graph (CRG) eliminates this waste by parsing your codebase once into a compact SQLite knowledge graph, then retrieving only the specific functions, classes, and tests relevant to each review question.

The Token Reduction Pipeline

CRG’s architecture follows a four-stage pipeline that transforms megabyte-size codebases into kilobyte-size context windows.

Parse Once with Tree-sitter

The process begins in code_review_graph/parser.py, which uses Tree-sitter to traverse your source tree and extract AST nodes—functions, classes, imports, and their relationships. These nodes are stored in a compact graph database rather than raw text files. This one-time parsing operation typically completes in under ten seconds for 500-file projects, after which the system never needs to re-read the full source text.

Blast-Radius Analysis

When a change occurs, CRG computes the minimal impact set by walking the graph to collect all callers, callees, and affected tests. This blast-radius analysis ensures that the LLM receives exactly the code that could be impacted by the modifications. According to the CRG source code, this approach avoids the "naïve full-corpus" problem where unrelated files clutter the context window.

Token-Efficient MCP Tools

High-level MCP tools such as get_review_context_tool and detect_changes_tool—registered in code_review_graph/tools/analysis_tools.py—fetch only the impacted nodes from the graph. Before returning results, these tools embed a concise summary of approximately 100 tokens, ensuring the LLM receives structured context rather than raw file dumps.

Quantifying Token Savings

CRG tracks exact token economics through the context_savings.py module. Using a 4-characters-per-token heuristic, the system compares the theoretical cost of reading the full codebase against the actual tokens consumed by the graph-based approach.

Benchmarks across six real-world repositories demonstrate a median 65× token reduction, with savings ranging from 36× to 376× depending on codebase size and change scope. For the CRG repository itself, queries drop from 208,000 source tokens down to approximately 3,200 tokens—a 68× reduction.

Implementation Details

The token savings mechanism relies on specific components working in concert:

• code_review_graph/parser.py – Handles Tree-sitter AST extraction and graph population
• code_review_graph/context_savings.py – Computes context_savings metadata with estimated token counts
• code_review_graph/tools/analysis_tools.py – Implements MCP tools that return minimal subgraphs

Before returning a response, CRG attaches metadata through the attach_context_savings function, which calculates the percentage reduction and breakdown by category (functions, tests, risk analysis).

Command-Line Interface

You can observe token savings directly through the CLI:

# Build the graph once (≈10s for 500-file projects)

code-review-graph build

# Show token savings for current changes

code-review-graph detect-changes --brief

Typical output displays the exact reduction:

┌─────── Token Savings ────────┐
│ Full context would be: 12,921 tokens │
│ Graph context used:      762 tokens │
│ Saved:                12,159 tokens (~94%) │
│ Breakdown: Functions 244·Tests 191·Risk 244·Other 83 │
└───────────────────────────────────────┘

For programmatic access, Python clients can retrieve the same metadata:

from code_review_graph.tools.context import attach_context_savings

result = get_review_context_tool(...)
result = attach_context_savings(result)
print(result['context_savings'])

Summary

• code-review-graph reduces token usage by storing code as a queryable knowledge graph rather than raw text
• Blast-radius analysis retrieves only affected functions, callers, and tests, avoiding irrelevant files
• Benchmarks show median 65× token reduction (up to 376× in large repositories)
• The context_savings.py module provides transparent accounting of token economics using a 4-characters-per-token heuristic
• MCP tools like get_review_context_tool return minimal subgraphs with pre-computed summaries

Frequently Asked Questions

How does code-review-graph estimate token savings?

The system uses a heuristic of approximately 4 characters per token to estimate the cost of reading the full codebase versus the selected graph nodes. This calculation is implemented in code_review_graph/context_savings.py and exposed through both CLI output and the attach_context_savings function, providing transparent metrics on context efficiency.

What is blast-radius analysis?

Blast-radius analysis is CRG’s method for determining the minimal set of code affected by a change. By traversing the graph to identify callers, callees, and related tests, the system isolates only the nodes that could impact or be impacted by modifications, typically reducing the review context from hundreds of files to a handful of relevant functions.

Can I use code-review-graph without an MCP server?

Yes. While CRG exposes high-level tools through MCP protocols, the core functionality—including graph building, blast-radius analysis, and token savings calculation—is available via standalone CLI commands like code-review-graph build and detect-changes. The analysis_tools.py module can also be imported directly into Python applications.

Which source files handle the graph parsing and token calculation?

The repository uses code_review_graph/parser.py for Tree-sitter-based AST extraction and graph construction, while code_review_graph/context_savings.py manages the token accounting logic. These components work together to ensure that only structural relationships—not raw source text—are stored and queried.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}