The 60% Claude Code speedup came from a local repo cache, not a smarter model

On a fresh Claude Code session, the model has no idea what is in the repo, so it begins a small archaeology project: grep a term, open a file, follow an import, back out, try a different path. By the time it has a working map, it has already burned a large fraction of its tool-call and token budget on what is, in effect, rediscovery. NanoNets' Graft, shipped this week on Show HN, is an open-source attempt to skip that step.

Graft's design fits on a sticky note. A per-repo code knowledge graph (nodes for files, functions, and types; edges for imports and references) is injected into each prompt through a Claude Code hook and a statusline. There is no daemon and no background re-indexing step the user has to run. Setup is npm install -g @nanonets/graft, then graft init and graft build; the resulting graft/ directory is auto-added to .gitignore, so it behaves like node_modules: local, regenerable, not committed.

The headline numbers all come from NanoNets' own README benchmark, a 162-run controlled comparison the vendor describes as "same agent, same file tools, only the context differs." On that setup, Graft cuts tool calls by 46%, token spend by 42%, and wall-clock time by 60% versus the same Claude Code agent running cold. On SWE-bench Verified, graded by the official harness, the same setup lifted pass rate from 54% to 66%, a 12-point swing.

Those four numbers are vendor-reported on a vendor-defined benchmark of the vendor's own tool. The README does not surface the exact Claude snapshot, prompt template, or how the 162 runs were distributed across repos, and NanoNets has not published a third-party replication. The 12-point SWE-bench jump is the most load-bearing claim, and the easiest to overstate: it could be the graph, or it could be subtle differences in the agent harness.

A 42% token saving without a model change is, by definition, a cache hit. Once the model stops paying to re-discover the codebase on every turn, a large slice of what looked like inference cost turns out to be context-construction cost. That is the category claim hiding in a vendor benchmark: a meaningful share of today's AI coding-agent spend is the cost of the agent not knowing the repo it is sitting in.

Graft's deep integration is described only for Claude Code. Cursor, Codex, and Gemini are listed as supported via an MCP server and a CLI, but the README's "every coding agent" framing outruns the documented integration depth. The auxiliary surface (graft grep, graft map, and graft viz for graph visualization) is monorepo-aware and tested against popular repos, which is what a developer would want from a tool that has to remain useful as the codebase grows.

Because graft/ is gitignored, team uniformity depends on every teammate running graft build against the same commit, and a cache that is local and regenerable is also a cache that can drift. If the 12-point SWE-bench bump survives an independent rerun, the next question is whether the graph is a personal accelerator or a team artifact that has to be enforced in CI.

The Show HN thread has already absorbed the framing. Top-voted comments validate the "agent starts blind" diagnosis and add a side thread on Opus 5 "turbo-encabulationitis", the tendency of newer Claude models to over-explore rather than commit to a read. The overlap is suggestive: if context construction is the bottleneck, every fix that gives the agent a better prior on the repo is a lever, and the graph is one of the more general ones.

An independent rerun of the 162-task benchmark with a different Claude snapshot would either confirm the SWE-bench swing or collapse it. If it collapses, the four vendor numbers are a harness artifact, and the cache story goes with them. If it holds, the next round of coding-agent benchmarks will measure something other than model quality: the cost of making the model stop being a stranger to the repo it is editing.