Trail-Code

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.

Contents

• Trail quick start: learnings your agent leaves for the next session, and your team's
• 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

Trail quick start

npm install -g @trailhq/trail
trail init
claude

Install once. trail init asks which agents your team uses, builds the code map and wires up Claude Code. Then work the way you always do.

When a session works something out, your agent saves a learning: what it decided, what it ruled out, and what to watch out for. It goes in the repo's .trail/learnings/, and you commit it with the change. The next session on that code, yours or a teammate's, gets it back before it starts digging, and ends with a line saying what it saved, like 📝 Started from Anirudh's learning · saved ~27k tokens. Teammates' Claude reads the learnings even before they install trail, and learnings on a teammate's pushed branch show up before it merges, along with any overlap with your work.

Before a PR, trail check compares your change with what the team has learned and flags anything that goes against it. It runs on your machine; nothing to sign in to.

When you want the team's view across repos, your agent offers a link at the end of a reply. Sign in, create a workspace, tick the repos it gets, and invite your team with a link. The team page shows who is learning what, how often learnings are reused, and where work overlaps.

Trying this branch before @trailhq/trail is published:

git clone -b feat/trail-cloud https://github.com/trailhq/Graft.git trail && cd trail
npm install && npm run build && node scripts/pack-trail.mjs
npm install -g ./build/trail

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 build writes graft/ and adds it to .gitignore — it's a regenerable local cache, like node_modules. What you commit is the small wiring graft init drops in (.claude/, AGENTS.md, the MCP config); each teammate runs graft build to 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 — so ask/grep/callers/skeleton/map describe the code as it is right now, including uncommitted edits. graft check is 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 dete