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

> Discover how code-review-graph slashes token usage by 65x. This workflow queries only impacted code nodes, a massive improvement over sending entire repositories to LLMs.

- Repository: [Tirth Kanani/code-review-graph](https://github.com/tirth8205/code-review-graph)
- Tags: performance
- Published: 2026-08-06

---

**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`](https://github.com/tirth8205/code-review-graph/blob/main/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`](https://github.com/tirth8205/code-review-graph/blob/main/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`](https://github.com/tirth8205/code-review-graph/blob/main/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`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/parser.py)** – Handles Tree-sitter AST extraction and graph population
- **[`code_review_graph/context_savings.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/context_savings.py)** – Computes `context_savings` metadata with estimated token counts
- **[`code_review_graph/tools/analysis_tools.py`](https://github.com/tirth8205/code-review-graph/blob/main/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:

```bash

# 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:

```python
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`](https://github.com/tirth8205/code-review-graph/blob/main/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`](https://github.com/tirth8205/code-review-graph/blob/main/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`](https://github.com/tirth8205/code-review-graph/blob/main/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`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/parser.py) for Tree-sitter-based AST extraction and graph construction, while [`code_review_graph/context_savings.py`](https://github.com/tirth8205/code-review-graph/blob/main/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.