← all comparisons vs CodeGraph · updated 17 Sep 2026

TokenSavevsCodeGraph

CodeGraph is where TokenSave came from — TokenSave began life as a ground-up Rust rewrite of it. Since then CodeGraph has itself moved to a Rust kernel and bundles its own runtime, which retires the single biggest claim TokenSave used to make against it. They have converged on architecture and diverged hard on philosophy.

TokenSave v7.12.1 · CodeGraph v1.6.0 (npm, Sep 2026)
A correction we owe CodeGraph. TokenSave's own docs have long said that "every alternative requires a runtime" and described CodeGraph as Node.js 18+ with ~80 MB of node_modules and WASM. That is no longer true. CodeGraph now ships a Rust kernel for parsing and extraction and bundles its own runtime — "nothing to compile, no native build, works the same everywhere." On the zero-dependency axis the two tools are now equals, and any page here claiming otherwise is out of date.

Credit where it is owed: CodeGraph pioneered this approach and TokenSave exists because of it. What follows is a comparison between two tools that now agree on how to ship and disagree on what to expose.

At a glance

DimensionTokenSaveCodeGraph
OriginRust rewrite of CodeGraph, diverged sinceThe original
ImplementationRust, single static binaryRust kernel + TS tooling, bundled runtime
Runtime depsNoneNone — bundles its own
LicenseMITMIT
MCP tools871 primary (codegraph_explore), others unlisted
Languages60 across 3 build tiers30+
Tool philosophyMany specialised tools, agent composes themOne tool that answers everything
Semantic searchKeyword expansion over FTS5, zero-costLocal embeddings (ONNX)
FreshnessOn demand — staleness check per call, work follows queriesNative OS file watcher — work follows saves
Multi-branchPer-branch graphs, cross-branch diffNo
Edit primitives4 atomic writers, re-index in placeNo
Health analyticsComposite score, Gini, DSM, test-riskNo
Agent integrations12+, native config per agentClaude Code
VisualizerRemoved in v4.0.1Yes

On the file watcher: the complexity is not worth it

CodeGraph embeds a native OS watcher — FSEvents, inotify, ReadDirectoryChangesW — debounced to a short quiet window, so the index tracks the filesystem continuously. That sounds strictly better than TokenSave's on-demand staleness check. It is not, and the reason is worth stating plainly.

A watcher does work proportional to edits. An on-demand check does work proportional to queries. Those are very different quantities. An agent mid-refactor writes files in bursts — and so does cargo build, npm install, a branch switch, a rebase, a code formatter. A watcher wakes up and re-indexes for every one of them. Why keep the graph fresh for a save that nothing is ever going to query? Most of that work is speculative, and most speculation is wasted.

The on-demand model inverts it: the index is brought up to date at the top of a tool call, when something is actually about to read it, with a short cooldown so a burst of calls does not re-check repeatedly. The sync itself is incremental — hash and mtime pre-filter, only changed files re-parsed — so the check is cheap precisely because the work was never deferred into a pile. You pay for freshness at the moment freshness has a consumer.

This is not a theoretical preference. TokenSave shipped a watcher in 6.0.0 and removed it in 6.1.1. On large monorepos it registered OS-level watches on nested node_modules, target and dist trees that the top-level ignore filter missed, producing event storms and unbounded memory growth — one report reached 19 GB. Removing it also dropped a dependency and a long-lived background thread from the process. The feature was tried, measured, and deleted.

The honest residual. On-demand does lose one thing: the first query after a large change pays the incremental sync inline, where a watcher would have done it in the background a second earlier. That is a few hundred milliseconds on a normal change set, once, against a permanent background process and an unbounded worst case. If your workflow is one enormous change followed by exactly one query, the watcher wins that round. Nothing else recommends it.

Where CodeGraph is the better tool

Where TokenSave is the better tool

Which should you use

Choose CodeGraph if…

you want the minimal surface: one tool, one call, an answer — and you value embedding-based recall over breadth. If you only use Claude Code and want the smallest thing that works, this is a very defensible choice.

Choose TokenSave if…

you want the graph to answer specific structural questions rather than one general one, you work across branches or worktrees, you want the agent to edit as well as read, or you need code-health metrics and broad agent support.

Method

Every TokenSave figure on this page was verified against the source at origin/master (v7.12.1), not taken from its own README: