Graft Gives Your AI Coding Agent a Map of the Codebase Before It Starts
Graft builds a codebase map for AI coding agents so they stop re-exploring your repo on every task. Free, open source, and 46% fewer tool calls in testing.
On a controlled sweep of 162 runs, Claude Code needed 46% fewer tool calls, 42% fewer tokens, and 60% less time to finish the same tasks once it had a codebase map for AI coding agents to work from instead of exploring from scratch. That map is what Graft builds: a free, open-source tool that generates a knowledge graph of your codebase and hands it to Claude Code, Cursor, Codex, or Gemini upfront, instead of letting the agent grep and re-derive your architecture on every single task. It's the fastest-rising repo on today's GitHub radar, up to 4,586 stars from a July 3 start, MIT licensed.
The problem Graft is solving is one anyone running a coding agent daily on a real codebase already knows by feel: a fresh agent session spends a meaningful chunk of its budget just figuring out where things live before it can touch the actual bug. A codebase map for AI coding agents removes that repeat cost by keeping the orientation work done once and current, not redone from zero every time.
Two passes, and only one of them needs an LLM
Graft builds its graph in two stages. The first is structural: a tree-sitter pass that extracts every function, class, type, call edge, and import relationship, deterministic, no API key required, and fast enough to run on every refresh (about 3 milliseconds). The second is optional and does need an LLM: an enrichment pass that summarizes each file in plain English and synthesizes those summaries into higher-level concept nodes, linked to each other with typed relationships like depends_on, part_of, and implements. That pass is cached by content hash, so only files that actually changed get re-summarized.
The output is a set of markdown files under a graft/ directory, git-ignored like node_modules. Each node holds three depths at once: a summary of what the code does, a "crux" excerpt of the actual logic, and a source reference back to the real file. Nodes carry wikilinks to related nodes and preserve any notes you add across regenerations. Graft's own framing for this is direct: the summary says what the code does, the crux shows how, and the sources point to the rest, so an agent (or a person) doesn't have to open the source file for every question.
Wiring into an existing agent takes two commands
Setup is npm install -g @nanonets/graft followed by graft init, which detects whatever coding agents are already installed and wires the map into each one's native config: a skill file and MCP server for Claude Code, a rules file for Cursor, AGENTS.md for Codex, and equivalents for Copilot, Gemini, Kiro, and Windsurf. The Claude Code integration goes furthest, adding a live statusline, auto-sync hooks that keep the graph current as files change, and six MCP tools an agent can call directly, including graft_trace_calls and a graft_check_freshness tool that flags when the graph has drifted from the working tree.
The graph auto-refreshes before every query by diffing working-tree bytes against the last build, so it reflects uncommitted edits, not just the last commit. It's also provider-agnostic for the LLM enrichment step: point it at OpenAI, Anthropic, OpenRouter, Fireworks, Groq, or a local model, using your own key.
What the benchmark numbers actually show
The 162-run controlled sweep is one data point; the more interesting one is Graft's SWE-bench Verified result, run against 50 real GitHub issues with Claude Sonnet 5. Cold, the agent resolved 27 of 50 (54%). With Graft's map available, it resolved 33 of 50 (66%), a 12-point jump, alongside a 23% token reduction and 25% fewer tool calls. Graft's own read on why correctness improved, not just speed, is specific: "every correctness win has the same shape: the baseline patches one file and misses its siblings." Having the call graph and the dependency map up front meant the agent found the related files a blind agent didn't know to look for, not just that it found them faster.
A smaller production test on PocketBase, a real ~350-file Go codebase, showed a more modest but still real gain: 21% lower cost and 14% faster wall-clock time across 15 tasks, with both the baseline and Graft-assisted agent matching the actual maintainers' file set for the same fixes.
Where it stops being worth the setup
Graft supports 21 languages at varying fidelity. Full cross-file call resolution works for TypeScript, JavaScript, Python, Go, and Java; a broader tier covers languages like Rust, C++, Ruby, and Swift with symbol-level but not fully resolved call tracking; anything outside that list gets skipped entirely rather than partially mapped. Graft's own positioning is honest about who this isn't for: single-file scripts and trivial repos don't have enough structure for a map to pay for itself, the tool is built for agentic work on codebases large enough that an agent's exploration cost is actually the bottleneck.
The tradeoffs worth knowing before adopting it: the enrichment pass costs real LLM spend on first build and after large changes (though it's cached and incremental after that), and the graph itself is a local artifact, no daemon, no hosted service, nothing running except the LLM calls you explicitly configure. Telemetry is opt-out and anonymous by default (bucket counts only, no code or paths), and off automatically in CI.
For anyone running Claude Code, Cursor, or another coding agent against a codebase big enough that "let me re-explain the architecture" is a recurring line in your prompts, Graft is a low-cost way to test whether a persistent map actually changes how the agent performs, rather than just how it feels.
Source: Graft on GitHub.
Join the newsletter
AI workflows and systems, straight to your inbox.
No spam. Unsubscribe anytime.