Graft
trailhq · trailhq/Graft
Graft turbocharges AI coding agents by providing codebase-specific contextual understanding, leading to faster, cheaper, and more correct code generation, and manages agent rules.
Turbocharge Claude Code, Cursor, Codex, Gemini & every coding agent: faster, cheaper, with contextual understanding specific to your codebase.
Preview
What you can do with it
- Reduce token usage and improve correctness for a Claude Code agent working on a large repository.
- Ensure an agent remembers and applies specific coding rules by integrating CLAUDE.md and AGENTS.md.
- Visualize the code graph of a project to help an agent understand dependencies and structure.
Safety check
Usable, but read the notes first.
- ●npm package runs a script automatically on install.
package.json
Automated scan of the repo files. Always review code you run.
From the README
Turbocharge Claude Code, Cursor, Codex, Gemini & every coding agent: faster, cheaper, with contextual understanding specific to your codebase.
Up to 4× cheaper and 3× faster, with better or no loss of correctness.
| Metric | Cold Claude Code | Claude Code with graft |
|---|---|---|
| Tool-call reduction | Baseline | +46% |
| Token savings | Baseline | +42% |
| Time savings | Baseline | +60% |
| Correctness | 54% | 66% (+12 pts) |
Stop repeating yourself to your coding agent. You correct it, and by the next session it has forgotten. Trail manages your CLAUDE.md and AGENTS.md so it doesn't.
• Every correction you make becomes a rule your agent keeps. • The ones that can't break get a hook that blocks it, not a note it ignores.
Contents
- Quick start
- The problem
- What Graft does
- Benchmark
- SWE-bench Verified
- How the graph gets built
- Supported languages
- What's in a node
- What runs where
- Agent integration — MCP server · Claude Code (deep integration)
- CLI
- Search & orient (
graft grep/graft map) - Monorepos & multi-repo folders
- Visualize it (
graft viz) - Tested on your popular repos
- Development
- License
Quick start
npm install -g @nanonets/graft # install the CLI, once
graft init # build the graph + wire it into Claude Code
That is the whole setup. graft init asks which of your coding agents to wire up, builds graft/ from your code, and drops a statusline and hooks into .claude/, so from the next session on Graft rides along in Claude Code: it pulls the matching nodes into each prompt and rebuilds the graph in the background after every turn. No daemon, no re-indexing to remember, nothing to run or maintain by default — the graph is just files.
Nothing is written until you pick. Run graft init --dry-run to see every file it would touch first, or graft init --agents claude to skip the prompt and wire Claude Code alone.
graft build adds graft/ to your .gitignore automatically — the graph is a local, regenerable cache (like node_modules), not something you commit. What you share is the wiring init dropped into .claude/; each teammate runs graft build to generate their own graph:
git add .claude && git commit -m "wire in graft"
Prefer not to install globally? npx @nanonets/graft init works the same way.
The problem
Every task, your coding agent starts blind. Before it changes anything, it re-explores the repo: 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. That rediscovery burns most of a run's tool calls, tokens, and latency, and it is pure overhead:
- Repeated. Every task pays the exploration cost again, from zero.
- Discarded. Whatever the agent figured out dies with the session.
- Unshared. The next teammate, and their agent, start from scratch too.
Humans onboard to a codebase once. Agents onboard every single time.
What Graft does
Graft builds that understanding once and writes it into your repo as a folder of linked markdown files, one node per system, API, or concept.
- Real explanations, not a list of symbols. Each node says, in plain English, what a part of the system does and how it connects to the rest, the way a senior engineer would explain it. That is the part an agent actually needs so it can skip the exploration. It is not a dump of function names.
- A real graph you can read. No embeddings, no similarity search, no index to keep warm. The graph is a set of linked files your agent opens, greps, and follows, exactly the way it reads any other file in the repo.
- A local cache, not a committed artifact.
graft buildwritesgraft/and adds it to.gitignore— it's a regenerable local cache, likenode_modules. What you commit is the small wiringgraft initdrops in (.claude/,AGENTS.md, the MCP config); each teammate runsgraft buildto generate their own graph. No database, no server, no setup. - Always fresh, automatically. Every query rebuilds the graph against the working tree first — structural,
$0, ~3ms when nothing moved — soask/grep/callers/skeleton/mapdescribe the code as it is right now, including uncommitted edits.graft checkis a local freshness signal; there's no stale index to babysit. - Your provider, your key, your model. Summaries are written by any provider you choose — OpenAI, Anthropic (native), OpenRouter, Fireworks, Groq, OrcaRouter, a LiteLLM proxy, or a local model — under your own key. The structural code graph (
graft build,graft check) is deterministic tree-sitter and never calls a model at all.
Benchmark
An agent that reads the graph should be cheaper and faster without getting more answers wrong. That's the whole claim, so we measured it instead of asserting it.
The harness ran three variants of the same Claude Sonnet 5 agent with the same file tools: cold (explores from zero), Graft (a graft ask --source bundle pushed up front), and pull (graft_find_code/graft_file_api tools, nothing injected — context paid for only when asked). An Opus 4.8 judge scored correctness with a required-keyword floor, so a fast-but-wrong answer couldn't win by being fast. Cost is cache-aware: reads ≈0.1×, writes 1.25×, the billing model agents actually run under.
162 runs, two repos (gr