Graft - Context layer for coding agents
Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
Graft is an open-source context layer that builds a persistent, markdown-based graph of your codebase, enabling coding agents like Claude Code, Cursor, Codex, and Gemini to work faster and cheaper. By pre-computing a semantic map of your code, Graft reduces token usage by up to 42%, cuts tool calls by 46%, and speeds up tasks by 60%, while improving correctness on SWE-bench Verified by 12 points. It integrates seamlessly via hooks and an MCP server, supports multiple languages, and requires no daemon or external services—just files in your repo.
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.
- seizethecheese
This looks cool and the mechanism looks plausible. I found the experience of trying to understand whether the claims here are legit to be aggravating.
First of all, the whole readme section about benchmarks appears to be Claude/Codex written. What a slog to read this.
Second, they claim success on SWE-Bench Verified, but it's only on 50 tasks, not making clear how these tasks are chosen. I know from experience that you can keep selecting sets of tasks until you get a result. Also, this was run 1x, and the lift they show actually only has a p val of 0.22.
There's a famous book "how to lie with statistics". I don't think the continual posts about benchmark results here are purposeful lies, but I think it's just so easy to fool yourself (and I've been burned, most recently building http://pellmell.ai ). Also I don't think this post is the most egregious example.
- anotherhue
I'm glad Claude is so recognisable, it lets me bounce right off the empty calorie language very efficiently.
Maybe this thing is great, but it cannot be determined with this presentation.
- icodestuff
Love the idea, I was thinking about this problem a few weeks ago, but never got anywhere with it. I'm intrigued by the latency savings in particular, that sounds great.
One concern I have is that right now each session gets fresh "eyes" on the problem. Right now I find I get a lot of mileage out of a combination of long-running sessions and fresh ones. I worry with a single generated concept graph that gets only incremental refreshes will become stale slowly, and in subtle ways that are hard to detect. That could lead to semantic drift in the graph from reality, and every new session will take the drifted form as gospel. Have you run any long tests (weeks or longer) on this to make sure that this doesn't happen? My understanding is SWE Bench is only a point-in-time evaluation.
Also the graph is stored in the repo, right? How mergeable is it? I know I wouldn't want to do conflict resolution on that myself, and even Opus struggles to keep all the references correct (especially when comments are involved) when there's an B->C, A->B symbol rename.
- xhrpost
I intuitively and perhaps naively thought that Claude using the LSP server would negate a lot of grep use. Is this tool solving the same problem or something else?
- skerit
Does Claude's grep still prepend the relative path of the file before _every_ single line? Because that is nasty, especially in java projects.