CodeGraph Real-World Test: Can a Code Graph Indexing Tool Actually Save Tokens? The Results Were Surprising

The Structural Pain Point of AI Coding Tools: Inefficient File-by-File Scanning

Current mainstream AI coding tools, whether Claude Code or Cursor, face the same structural problem when dealing with large codebases: to understand project architecture, AI needs to repeatedly execute a "search → read → search again" loop. It first uses Grep to locate keywords, then reads files one by one after finding them, and repeats this cycle over and over.

The cost of this process is twofold — massive Token consumption and latency stacking from frequent tool calls. In complex projects, AI easily falls into a trap of jumping back and forth without ever finding the core call chain. This isn't a model capability issue — it's a structural deficiency in how information is accessed.

CodeGraph's Core Solution: Local Semantic Graph Network

CodeGraph targets exactly this problem. Its core approach deeply integrates static code analysis with local retrieval.

Specifically, CodeGraph uses Tree-sitter to locally parse source code into Abstract Syntax Trees (AST). Functions, classes, and interfaces are abstracted as nodes in the graph, while call relationships, inheritance relationships, and module imports are defined as edges. The entire graph is stored in a local SQLite database. When AI needs to understand code structure, instead of blindly scanning files one by one, it issues a single graph query to the local database via the MCP protocol, directly retrieving the needed symbol information and context slices.

Technical Background: Tree-sitter and Abstract Syntax Trees (AST)

Tree-sitter is an incremental parsing library developed and open-sourced by GitHub, originally designed for syntax highlighting and code navigation in code editors. Its core advantage lies in "incremental parsing" — when code undergoes local modifications, there's no need to re-parse the entire file; only the changed subtree is updated, making it extremely efficient in real-time editing scenarios. Tree-sitter currently supports syntax definitions for over 100 programming languages and has become the underlying parsing engine for tools like Neovim and GitHub Copilot.

An Abstract Syntax Tree (AST) is a tree-structured representation of source code that strips away syntactic noise like parentheses and semicolons, preserving only the logical skeleton of the program. For example, a function call foo(a, b) would be represented in the AST as a hierarchical structure of "call node → function name node + parameter list node." CodeGraph leverages Tree-sitter to further abstract the AST into a graph structure, extracting symbols like functions and classes as nodes, and extracting call relationships as directed edges, thereby building a semantic network that can be efficiently queried.

The query path is compressed from multiple explorations to a single targeted hit — this is a qualitative leap.

Framework Awareness: Beyond Simple Symbol Matching

You might not have noticed, but CodeGraph doesn't just do simple symbol matching — it can also recognize route mappings in mainstream backend frameworks, trace event flow trigger chains, and follow complete paths from React state updates to rendering. This means AI can achieve true end-to-end call chain tracing, rather than staying at the level of local understanding of individual functions.

Three Engineering Values CodeGraph Delivers

From an engineering value perspective, CodeGraph brings improvements in three areas:

1. Token consumption optimization: AI receives structured, precise context rather than repetitive bulk reads of raw file content
2. Faster response times: The entire indexing and query pipeline runs completely locally with no network dependencies
3. Code privacy protection: Project structure never flows to any third-party service

Technical Background: MCP Protocol

MCP (Model Context Protocol) is an open protocol released by Anthropic in November 2024, aimed at standardizing interactions between AI models and external tools and data sources. Before MCP, each AI tool needed to develop separate integration interfaces for different data sources, creating massive amounts of redundant "M×N" adaptation work. MCP simplifies this to "M+N" by defining a unified server-client communication specification — tool developers only need to implement an MCP server once to be callable by all MCP-supporting AI clients (such as Claude Code, Cursor, etc.).

The core abstractions of the MCP protocol include three types of capabilities: Resources (data resource reading), Tools (executable operations), and Prompts (preset prompt templates). CodeGraph, as an MCP server, wraps the local SQLite graph database as a standardized query tool. AI clients issue structured query requests via the MCP protocol to obtain precise symbol information and call chain slices, completely bypassing traditional file system traversal.

Applicability Boundaries: Natural Limitations of Static Analysis

Every tool has its applicable scope. For projects that heavily rely on reflection, metaprogramming, or complex dependency injection, static analysis itself has a ceiling and cannot cover runtime dynamic behavior. In extremely large legacy codebases, the resource consumption of building the graph index for the first time also needs to be factored into evaluation.

Technical Background: The Boundary Between Static and Dynamic Analysis

Static analysis is a technique for performing structural and semantic analysis on source code without executing it. Its advantages include speed, no need for a runtime environment, and the ability to cover all code paths. However, static analysis has a fundamental limitation: it cannot handle behavior that can only be determined at runtime.

Typical challenging scenarios include: the extensive use of reflection mechanisms in Java/Spring (Class.forName() dynamically loading classes), dependency injection frameworks (Spring IoC containers dynamically assembling Beans at runtime), Python's __getattr__ magic methods, and various metaprogramming techniques (such as Ruby's method_missing). In these patterns, the target of a function call cannot be determined at compile time — static analysis tools can only see that "there is a dynamic call" but cannot trace its specific target.

Dynamic analysis (such as runtime tracing and instrumentation) can fill this gap, but at the cost of needing to actually execute the code and only covering specific execution paths. CodeGraph's choice of the static analysis route means its call chain tracing will encounter breakpoints in the above scenarios. This is a reasonable design trade-off, not a defect — for most well-structured modern codebases, static analysis can already cover the vast majority of valuable call relationships.

Unity Project Real-World Test: Costs Went Up but Quality Dominated

To verify CodeGraph's actual effectiveness, the author ran a comparative test using two identical Unity projects. Both sides used Claude terminal with DeepSeek^Ad v4, executing the same prompts.

Surface Data: Both Cost and Time Increased

The right side had CodeGraph enabled with a local index built, but the total cost not only didn't decrease — it actually surged from $1.13 to $1.87. API response time also doubled.

Does this mean CodeGraph's local index is useless?

Deeper Data: A Sophisticated Counter-Intuitive Phenomenon

Quite the opposite. Looking closely at the underlying data reveals a very interesting counter-intuitive phenomenon.

CodeGraph did work — the right side's prompt cache hit volume reached 1.3M tokens, nearly double that of the left side. This proves it successfully helped the model precisely locate files, significantly slimming down the input side.

But why did the total cost actually increase? The answer is hidden in the Output Tokens: the right side's model output volume exploded by a full 6x.

Technical Background: Prompt Caching Mechanism

Prompt caching is a cost optimization mechanism introduced by Anthropic for the Claude API, allowing repeatedly occurring context content