> ## Content Index
> Fetch the complete content index at: https://kudithipudi.org/llms.txt
> Use this file to discover other available public pages before exploring further.

# HOW TO : Save coding-agent tokens across repos with Graft
- URL: https://kudithipudi.org/how-to-save-coding-agent-tokens-across-repos-with-graft/
- Published: 2026-08-23T13:11:24.000Z
- Updated: 2026-08-23T13:20:05.000Z
- Description: A simple setup to save AI tokens when using coding agents
- Author: Vinay Kudithipudi
- Tags: AI, Programming, Technology, tools

I have been using coding agents extensively as they have become more useful. It has resulted in developing several projects in my [lab](https://lab.kudithipudi.org/?ref=kudithipudi.org).

The expensive part for a coding agent is not usually the edit. It is the first few minutes: grepping, opening files, and rebuilding a mental model of a codebase the agent has already seen before. Especially if you are working on an existing project.

I set up [Graft](https://www.npmjs.com/package/@nanonets/graft?ref=kudithipudi.org) for the coding agents in [lab.kudithipudi.org](https://lab.kudithipudi.org/?ref=kudithipudi.org) so they can share a prebuilt view of each repository instead of re-deriving it in every session.

```bash
npm install -g @nanonets/graft
cd /var/www && graft init --yes
```

Graft builds a local context graph for a repository:

- Markdown notes describing systems, with exact `file:line` references
- A graph of call relationships
- A small set of commands agents can query before they start reading source

In some of my recent coding sessions, Graft reported roughly 80% tokens saved per repository compared with reading the files it covered. Whether that number is exact is less important to me than the behavior change: agents start with an architectural view instead of treating every session as a cold start.

The setup has three parts.

**A generated graph**  
Graft writes markdown and wiring data into `graft/`. I keep it out of git because it is deterministic and easy to rebuild `graft build` . There is no API key, embedding pipeline, or hosted service involved.

1. **Agent wiring**  
`graft init` adds an `AGENTS.md` block, a skill, and MCP configuration to the repo. Claude Code and OpenCode (agents I am playing with now) can use those conventions, so I do not need separate context setups for every agent. Most of the popular agents use the same pattern.
2. **A parent-level index**  
I ran `graft init` once at `/var/www ` where I have all my projects hosted. That gives sessions started there a federated view across the projects below it, with results labeled by repository.

The practical benefit is that the graph stays current. Graft installs Claude Code hooks during initialization: a session-start hook tells the agent to use the graph first, and edit/stop hooks sync it after changes. Queries also refresh before answering, including against uncommitted edits.

That matters because a stale index is worse than no index.

I looked at these alternatives, but did not test them deeply:

- **Aider’s repo map** is useful prompt-time context, but it is not a persistent graph that multiple agents can query.
- **Serena** provides strong LSP-based symbol navigation, but I wanted a persistent prose layer that I could browse too.
- **Cursor** and **Windsurf** provide retrieval within their own environments.
- **Repomix** and **gitingest** flatten repositories into context files. They move the token cost around rather than reducing the amount of source an agent needs to inspect.