# How Blast Radius Analysis Works in code-review-graph: Token Reduction and Graph Traversal Explained

> Discover how blast radius analysis in code-review-graph reduces LLM tokens with bounded BFS, decay scoring, and graph traversal. Optimize your code analysis now.

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

---

**Blast radius analysis in code-review-graph uses a bounded breadth-first search with decay-based scoring to isolate only the most relevant code dependencies, reducing LLM token consumption by limiting traversal depth, capping result counts, and pruning low-impact nodes before context generation.**

Blast radius analysis determines how far the effects of a code change spread across a repository's knowledge graph. In the `tirth8205/code-review-graph` project, this analysis—implemented primarily through the `get_impact_radius` function—serves as the foundation for intelligent code review by filtering out irrelevant files and minimizing the context sent to large language models. By focusing exclusively on high-impact dependencies, the system ensures that AI-assisted reviews remain both cost-effective and contextually precise.

## Core Architecture of Blast Radius Analysis

The blast radius engine operates through a multi-stage pipeline that transforms raw file changes into a curated subset of relevant symbols. According to the source code in [`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py), the process combines graph traversal algorithms with SQLite-based scoring tables to compute precise impact boundaries.

### Seed Selection from Changed Files

The analysis begins by converting modified files into qualified name seeds. In [`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py) (lines 13-15), the `_impact_seed_qns` method builds the initial seed set, including language-specific namespace seeds for C# and other supported languages. These seeds represent the entry points for the dependency graph traversal.

### Bounded Traversal Engine

The traversal engine executes a breadth-first search propagating from seeds through dependency edges such as `IMPORTS_FROM` and `TESTED_BY`. The `get_impact_radius` function (lines 1317-1345 in [`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py)) supports multiple backend engines including SQL and NetworkX. The search respects hard boundaries: it terminates when reaching either the `max_depth` limit (defaulting to 2 hops) or the `max_nodes` threshold (exposed as `max_results` in the public API).

### Impact Scoring and Decay

Each traversed edge carries directional weights defined by `IMPACT_EDGE_WEIGHTS` and `IMPACT_EDGE_DIRECTIONS`. The algorithm applies `IMPACT_DEPTH_DECAY` to reduce scores as the search moves farther from the original change. The implementation uses temporary SQLite tables—`_impact_best`, `_impact_frontier`, and `_impact_next` (lines 46-66 in [`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py))—to track only nodes whose best-path scores improve on subsequent iterations, effectively pruning low-relevance paths.

### Token Estimation and Bounding

Before executing the graph query, the wrapper function in [`code_review_graph/tools/query.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/query.py) (lines 52-56) invokes `estimate_file_tokens` to approximate the raw token cost of changed files. This pre-check allows the system to adjust bounds dynamically. The result object includes a `truncated` boolean flag when the search hits the `max_nodes` limit (lines 59-62 in [`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py)), alerting callers that the blast radius exceeded the configured token budget.

## How Blast Radius Analysis Reduces LLM Tokens

The token reduction impact stems from four specific architectural constraints implemented in the codebase:

- **Depth Limiting**: By default, the engine examines only the first 2 hops (`max_depth=2`) from any changed file. This prevents the exponential expansion typical of unbounded dependency graphs.

- **Result Capping**: The `max_results` parameter (internally `max_nodes`) caps the output at 500 nodes by default. When the engine hits this limit, it sets the `truncated` flag in the return dictionary (lines 26-30 in [`code_review_graph/tools/query.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/query.py)), allowing upstream systems to handle partial context gracefully.

- **Score-Based Pruning**: The best-path scoring mechanism discards nodes that cannot improve upon previously discovered paths. This eliminates peripheral dependencies—such as distant utility libraries—from the final context window.

- **Pre-Traversal Budgeting**: The `estimate_file_tokens` function provides an immediate token budget before expensive graph operations begin. Callers can abort or adjust parameters if the initial file set already exceeds available context limits.

Together, these mechanisms ensure that LLMs receive only the minimal necessary context to understand a change's implications, typically reducing token payloads by focusing on high-coupling neighbors rather than the entire codebase.

## Practical Implementation Examples

Developers can invoke blast radius analysis through either the command-line interface or direct Python API calls.

### CLI Usage

The `impact` subcommand provides immediate blast radius calculation for git diffs:

```bash
crg impact --max-depth 2 --max-results 300

```

This command scans the current git diff, computes the impact radius with a maximum depth of 2 hops, and limits results to 300 nodes, outputting a concise JSON summary suitable for CI/CD pipelines.

### Python API Integration

For custom scripts, import the `get_impact_radius` function from `code_review_graph.tools.query`:

```python
from code_review_graph.tools.query import get_impact_radius

# Define explicitly changed files

changed = ["src/foo.py", "tests/test_foo.py"]
impact = get_impact_radius(
    changed_files=changed, 
    max_depth=3, 
    max_results=200
)

print("Impacted files:", impact["impacted_files"])
print("Total impacted nodes:", impact["total_impacted"])
print("Was the result truncated?", impact["truncated"])

```

The `max_results` argument directly controls token usage by capping the node count returned to your application.

### Hub and Bridge Analysis Integration

Blast radius concepts underpin higher-level architectural analysis. The `get_hub_nodes_func` in [`code_review_graph/tools/analysis_tools.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/analysis_tools.py) (lines 21-27) identifies hub nodes—symbols with the largest potential blast radius—helping reviewers prioritize critical files:

```python
from code_review_graph.tools.analysis_tools import get_hub_nodes_func

hub_info = get_hub_nodes_func()
print("High-impact hub nodes:", hub_info["hub_nodes"])

```

## Summary

- Blast radius analysis in `code_review_graph` uses a bounded BFS algorithm with decay scoring to map change propagation while respecting token budgets.
- The system enforces hard limits through `max_depth` (default 2) and `max_results` (default 500) parameters to control context size.
- SQLite-backed scoring tables (`_impact_best`, `_impact_frontier`) implement efficient best-path pruning in [`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py).
- Pre-traversal token estimation via `estimate_file_tokens` enables budget-aware query adjustments before graph traversal begins.
- The `truncated` flag signals when results exceed configured bounds, preventing silent context overflow in LLM pipelines.

## Frequently Asked Questions

### What is blast radius analysis in code-review-graph?

Blast radius analysis is the process of determining how far the effects of a code change spread across a repository's knowledge graph. It is implemented as the `get_impact_radius` tool in [`code_review_graph/tools/query.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/query.py), which performs a bounded traversal from changed files to identify dependent symbols while excluding irrelevant portions of the codebase.

### How does the impact radius algorithm limit token usage?

The algorithm limits tokens through four mechanisms: restricting traversal to 2 hops by default (`max_depth=2`), capping results at 500 nodes (`max_results`), pruning low-score paths using `IMPACT_DEPTH_DECAY`, and pre-checking token budgets with `estimate_file_tokens`. These constraints ensure only high-relevance code reaches the LLM context window.

### What is the difference between max_depth and max_results?

`max_depth` controls the breadth-first search recursion depth (graph distance from changed files), while `max_results` (exposed as `max_nodes` internally) limits the total number of impacted nodes returned. When `max_results` is reached, the system sets the `truncated` flag to indicate incomplete traversal.

### How does the scoring mechanism prioritize nodes?

The scoring mechanism uses edge weights (`IMPACT_EDGE_WEIGHTS`) and directional flow (`IMPACT_EDGE_DIRECTIONS`) to calculate cumulative impact scores that decay with distance (`IMPACT_DEPTH_DECAY`). Nodes are only retained if they improve upon previously discovered best-path scores, ensuring that strongly coupled dependencies rank higher than distant, loosely connected symbols.