Graft Gives Your Coding Agent A Map So It Stops Re-Reading Your Repo

A coding agent rebuilds its mental map of your codebase every session, then throws it away, and you pay for that exploration every time. Graft, an open-source tool from Nanonets, fixes this by building a permanent map of your repo once and saving it as a folder of markdown files inside the project. It wires into Claude Code and Cursor so the agent reads the map instead of re-crawling your files. The video shows the GitHub README with a benchmark claiming fewer tool calls, fewer tokens, and less time at equal correctness.

The Problem Graft Targets

When an AI agent starts a task, it searches your files to figure out where things are. That work builds a picture of the codebase that lives only for the session. Close the session and the picture is gone, so the next task starts the same crawl again. Every one of those searches costs tokens and time. On a large repo the exploration can dominate a task before the agent writes a single useful line.

How It Works

Graft builds a graph of your codebase once and stores it as plain markdown files in a graft/ folder in the repo. The README frames the setup as three commands: npm install -g @nanonets/graft, then graft init, then run your agent. The graft init step asks which coding agents to wire up, builds the graph from your code, and drops a statusline and hooks into .claude/. From the next session on, Graft rides along in Claude Code and pulls the matching nodes into each prompt so the agent starts oriented. It rebuilds the graph in the background after every turn, so the map stays current without a daemon or a manual re-index.

The Benchmark Claims

The README table compares a standard agent session against the same session with Graft, on a stated 162-run controlled benchmark using the same agent and same file tools with only the context differing. The claimed results: 46% fewer tool calls, 42% fewer tokens, 60% less time, and equal correctness. The README also cites a separate real-repo sweep across projects like PocketBase, Ollama, and Excalidraw where the biggest single-task wins reach up to 4x cheaper and 3x faster. Treat these as the project's own reported numbers, not independent results.

Files, Not A Service

The design choice worth noting is that the map is just files in the repo. The graph is a local cache that Graft adds to .gitignore automatically, similar to node_modules. What a team commits is the wiring in .claude/, and each teammate runs graft build to generate their own graph. The README also lists an MCP server with tools for finding code, tracing calls, and mapping the repo, plus a graft viz command to visualize the graph. It ships under the MIT license.

Key Takeaways

The waste is repeated exploration. Agents rebuild and discard a codebase map every session, and each rebuild burns tokens and time.
Graft persists the map as markdown. A graft/ folder in the repo holds the graph so the agent reads it instead of re-crawling.
Setup is three commands. Install the CLI, run graft init to wire your agents, then start coding.
The claimed gains are project-reported. 46% fewer tool calls, 42% fewer tokens, 60% less time, and equal correctness on a 162-run benchmark, per the README.
It stays out of your commits. The graph is gitignored like a cache; teammates regenerate it locally with graft build.