u/shhdwi — reddlx

Built an open-source tool that stops AI coding agents from re-reading your whole codebase every time

If you've used Codex or Claude Code on a real project, you've probably noticed it re-explores the same files every session, like it's never seen your code before.

Built Graft to fix that. It writes a map of your codebase into files, once, so the agent reads that instead of starting from scratch each time. Works with Codex through its MCP support, plus a hook that keeps the map up to date automatically after edits.

Open source, free to try: github.com/NanoNets/Graft

u/shhdwi — 8 days ago

▲ 356 r/developersIndia

My open-source project just crossed 1,800+ stars on GitHub. Sharing the story.

Started this because I kept watching Claude Code re-explore the same codebase every single session, re-reading files it had already read, re-tracing imports it had already traced, nothing carried over from one session to the next.

Built Graft to fix it. It writes a map of the codebase into markdown files, commits them to git, and the agent reads that map instead of starting from zero each time.

First version was an MCP server, six tools the model could call whenever it wanted context. Watched it run for a while and it just didn't call them most of the time, fell back on grep and file reads instead, and got things wrong on exactly what those tools would've told it. So I stopped waiting for it to ask and wired it into Claude Code's hooks instead, the context gets pushed in automatically now, no tool call needed.

Wasn't expecting much when I open sourced it. Just crossed 1,800+ stars, which has been a genuinely nice surprise. Happy to answer anything about the build, the tree-sitter parsing side, or the hooks integration if anyone's curious.

Repo link: github.com/NanoNets/Graft

u/shhdwi — 8 days ago

▲ 53 r/ClaudeMCP+7 crossposts

I solved the issue of Claude not using custom MCP/CLI tools, and open-sourced my approach.

Built an MCP server first. Gave Claude Code six tools for pulling codebase context. Watched it run for a while and it just didn't call them most of the time. Fell back on grep and file reads instead, same as it always does, and got things wrong on exactly the questions the tools would've answered directly.

Tool calls are opt-in. The model decides mid-task whether it needs the lookup, and on anything that looked simple enough to guess at, it usually decided no.

So instead of giving it a tool to call, I stopped giving it a choice. Wired the whole thing into Claude Code's hooks. A SessionStart hook pulls the relevant context into the prompt automatically, before the model's typed anything. A background hook re-syncs it after every edit. No tool call, nothing to skip.

The tradeoff: this only works on Claude Code. MCP works with any agent that speaks the protocol, hooks don't. Kept the MCP version around for Cursor and Codex, hooks just for Claude Code since I control both ends of that integration.

Open-sourced the whole thing: github.com/NanoNets/Graft

u/shhdwi — 6 days ago

▲ 3 r/OpenSourceeAI+1 crossposts

After 162 Claude Code sessions: context cut token use 42% and improved accuracy on sonnet

I wanted to know whether giving a coding agent a persistent map of the codebase actually pays for itself, or whether it just moves tokens from one place to another. So I built the harness before I trusted the tool.

The setup

Same agent, same model, same tool access, same task list. One variable: whether a context layer was loaded. 162 Claude Code sessions total, split across both conditions. Tasks were real change requests against a real repo, not synthetic retrieval questions, because retrieval benchmarks reward whatever your retriever already does well.

Correctness is graded by a separate model that never sees which condition produced the diff. Without that, a cheaper session that quietly does less work scores as an improvement.

The result

	Cold	With context
Input tokens	8,070	4,650 (−42%)
Tool calls	4.2	2.3 (−46%)
Cost	$0.043	$0.029 (−32%)
Correctness	93%	98%

For a lot of tasks it got equal or better accuracy on Claude sonnet 5 using graft than just standard Claude sonnet session, on opus it was more towards token reduction than accuracy.

Replication on real PRs

Benchmarks I write myself are benchmarks I can accidentally tune to. So: 5 merged PocketBase PRs, re-implemented from the base commit in both conditions, scored on whether the diff touched the files the maintainers touched. 5/5 reproduced, at 21% lower cost. Small n, and I'd rather say small n than round it into a headline.

What I'm working on is Graft: It's a Context layer for large repos. No vector DB, no embeddings. Structural pass runs on tree-sitter for $0.
MIT Licensed

npm install -g u/nanonets/graft
graft init

Harness details in the repo. Tell me where the measurement is wrong and I'll rerun it.

u/shhdwi — 23 days ago

▲ 68 r/aipromptprogramming+16 crossposts

The problem with MCP-based codebase context tools: the model just doesn't call them

Something I kept running into building agent tooling: giving an agent an MCP

tool that *could* answer a question about the codebase doesn't mean it will.

Tool-call decisions are probabilistic, not guaranteed. The agent has to

recognize it needs the tool, remember it exists, and choose to call it over

just grepping. A lot of "codebase context" products are architected as

exactly that: an MCP server sitting in the tool list, unused more often than

not.

Graft's bet is different: don't wait to be asked. It hooks directly into

Claude Code. The matching nodes get pulled into every prompt automatically,

editing a file surfaces its dependents inline, and the graph re-syncs itself

in the background after every edit, all without the agent deciding to invoke

anything. Same reason Chrome doesn't ship with an ad blocker built in: the

core stays general, and the extension handles the specialized job. Graft is

that extension for context.

Underneath, it's a typed graph, not a vector index: tree-sitter builds a

deterministic per-symbol graph (no model call), and an optional `--deep` LLM

pass groups that into markdown nodes with typed links (`depends_on`, `uses`,

`produces`) an agent follows like any other file. Method calls resolve

through the receiver's type (constructor assignments and type annotations,

not just call-site name matching), so a common method name doesn't pull back

every unrelated method with that name across the codebase.

The claim: up to 4× cheaper and 3× faster, with better or no loss of

correctness. Setup: 162 runs, two repos (graft itself + a real Node/Express

auth service), 3 trials each, single-file and multi-file questions split

evenly. Three variants of the same Claude Sonnet 5 agent: cold (explores from

zero), push (context bundled up front), pull (MCP tools, nothing injected,

paid for only when asked). A separate Opus 4.8 model graded 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×) to match real billing.

Results: push cut cost 32%, tool calls 46%, latency 60%, at equal correctness

(93% both, no loss). Pull gave up most of the speed but correctness jumped

to 98%, +5 over cold, the "better" half of the claim, and worth noting: pull

*is* the MCP-tool-list approach, and it still worked, because the harness

forced the call. Left to its own judgment across a real session, that's

exactly the discipline that erodes.

Second test, because a benchmark on questions can still be gamed: reset

PocketBase to its base commit before 5 merged PRs, re-implemented each with

and without graft, scored by file-overlap with what the maintainers actually

changed. 5/5 reproduced, at 21% lower cost.

Opensource, MIT licensed

Here's the repo link : https://github.com/NanoNets/Graft

github.com

u/shhdwi — 8 days ago

▲ 3 r/BuildWithClaude

Most codebase-context tools wait for the agent to call them. This one doesn't. while still being 4× cheaper and 3× faster.

A lot of "give your agent context about your codebase" tools ship as an MCP

server: a set of tools the agent *can* call. In practice, half the time it

just doesn't. It has a hammer in the toolbox and still tries to bash through

the wall with its head: grep, open file, follow import, back out, the same

exploration it did an hour ago.

Why doesn't Claude Code just solve this by default? Same reason Chrome

doesn't ship with an ad blocker built in: keeping the core general is the

point, and extensions fill the specialized gaps. Graft is that extension. It

plugs into Claude Code's hooks so the right context shows up in every prompt

automatically, instead of sitting in an MCP tool list hoping to get called.

I built Graft to write what an agent learns about your codebase into the

repo itself, as a folder of plain markdown files kept in sync through git.

One `graft init` turned this repo's 247 files into 12 plain-English nodes.

    npm install -g @/nanonets/graft
    graft init

From then on: a live statusline (graph size, % enriched, a stale warning),

auto-sync in the background after every edit, and the matching nodes pulled

into every prompt without the agent needing to decide to ask for them.

Editing a file surfaces what depends on it inline. No vector DB, no

embeddings, no server. The graph is just files, grep them like anything else

in the repo. The structural pass is tree-sitter, no key or network call

needed at all.

The part I actually learned something building this: line numbers drift the

moment you touch unrelated code above them, but the guard clause or state

change that matters doesn't. Each node stores that as text lifted straight

from the source, not a line range.

Up to 4× cheaper and 3× faster, with better or no loss of correctness. I

measured that instead of asserting it. 162 controlled runs, same agent, same

tools, only the context differs: 32% cheaper, 46% fewer tool calls, 60% less

latency, same correctness (93% both).

Then re-implemented 5 real merged

PocketBase PRs from base commit with and without it: 5/5 reproduced, same

files as the maintainers, at 21% lower cost.

MIT licensed, I'm the maintainer, so weigh the numbers

accordingly. I'd be happy to have anyone has any questions on the methodology.

https://github.com/NanoNets/Graft

reddit.com

u/shhdwi — 23 days ago

▲ 1 r/cicd