The most useful number in Graft's results table is not the 60% latency cut. It is the pattern the maintainers describe behind their SWE-bench Verified wins: every correctness gain has the same shape, because the cold baseline patches one file and misses its siblings. On django-11532 the report says the baseline patched 1 of the 5 files the fix requires and broke 18 previously-passing tests. On django-16263 it patched 1 of 4. Those are not slow runs. They are confident, fast, incomplete ones.
Graft is a TypeScript CLI from NanoNets that writes a context layer into your repo so a coding agent stops rediscovering the codebase on every task. Install it with npm, run graft init, and it asks which agents to wire up, builds a graft/ folder from your source, and drops a statusline plus hooks into .claude/.
Rediscovery is the tax, incompleteness is the bill
The README's problem statement is blunt about what an agent does before it changes anything: grep a term, open a file, follow an import, back out, try again. It is rebuilding a picture of a codebase it mapped an hour ago and threw away. The exploration cost gets paid again from zero on the next task, and whatever the agent worked out dies with the session. Humans onboard to a codebase once; agents onboard every single time.
Most tools that attack this sell you the token savings. Graft's own controlled sweep does report those, and they are real by the project's measurement: 162 runs across two repos, same Claude Sonnet 5 agent, same file tools, only the context differs. Mean tool calls drop from 4.2 to 2.3, tokens from 8,070 to 4,650, latency from 39.8 seconds to 15.8. Correctness in that sweep stayed flat at 93%.
Flat correctness is the honest part. The savings claim and the accuracy claim come from two different harnesses, and the project says so.
The graph is a folder you can grep
There is no vector store here. graft build produces a set of linked markdown files, one node per system, API, or concept, with typed links between them. The agent opens and follows them the way it reads any other file in the repo. No embeddings, no similarity search, no index to keep warm.
Two LLM passes build it. The first summarizes each source file into a short description. The second groups those summaries into a curated node set, picking a level of detail so a large repo lands at a few dozen readable nodes rather than one node per file. Running alongside that is a deterministic tree-sitter tier that emits a per-symbol code graph into graft/.graph/wiring.json and never calls a model at all.
The storage decision is the one operators will appreciate. graft build adds graft/ to .gitignore and treats it as a regenerable local cache, in the same spirit as node_modules. What you commit is the small wiring that init left behind in .claude/, AGENTS.md, and the MCP config, and each teammate builds their own graph. Every query rebuilds against the working tree first, which the project clocks at roughly 3 milliseconds of structural work when nothing moved, so uncommitted edits are covered without a stale index to babysit.
Push and pull are different products
The sweep ran three variants, not two. Push injects a graft ask bundle up front. Pull exposes graft_find_code and graft_file_api as tools and injects nothing, so context is paid for only when the agent asks. Push bought the speed. Pull gave most of that speed back and took correctness to 98%, five points over cold, which the project calls the strongest single result in the sweep.
That is a genuine fork, and the README does not paper over it: push when speed is what you need, pull when being right matters more. If your agent's mistakes look like the django cases, where it stops at the first plausible file, the pull configuration is the one worth trying first.
Summaries run under your own key against whichever provider you pick, including a local model, and the structural commands never touch one. The project is MIT licensed with a telemetry badge reading none. The check to run on your own codebase is not whether the token counter drops. It is whether the next multi-file change lands on all of the files it should.
GitHub: https://github.com/NanoNets/Graft
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (0)