Why these animations in the github README? why? It just made understanding anything more difficult
Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
11–20 of 49 posts
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#12What's the benchmark against graphify?
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#13I'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.
You can actually tell from the very first real sentence in the README:
> Efficiency is a 162-run controlled benchmark (same agent, same file tools, only the context differs).
It's so bad that I can tell it's Claude, specifically Opus 4.8/5.0, from the first 6 words.
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#14I'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.
Opus 5 specifically seems to be affected by a severe case of turbo-encabulationitis, almost as if it was trained to spit out as complex of sentences as it can. And may your deity of choice help you if you decide to venture on subjects which you don't have a deep understanding of, as half the sentences it generates will be (barely) cohesive.
> almost as if it was trained to spit out as complex of sentences as it can.
It probably was, at least inadvertently. Very easy to imagine that one of the post-training step (RLHF, DPO etc) reinforced the "sounds clever" behaviour.
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#15Earlier quoted context omitted.
Opus 5 specifically seems to be affected by a severe case of turbo-encabulationitis, almost as if it was trained to spit out as complex of sentences as it can. And may your deity of choice help you if you decide to venture on subjects which you don't have a deep understanding of, as half the sentences it generates will be (barely) cohesive.
> almost as if it was trained to spit out as complex of sentences as it can. It probably was, at least inadvertently. Very easy to imagine that one of the post-training step (RLHF, DPO etc) reinforced the "sounds clever" behaviour.
"It tested well with the focus group..."
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#16Love 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.
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#17I'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.
You can actually tell from the very first real sentence in the README: > Efficiency is a 162-run controlled benchmark (same agent, same file tools, only the context differs). It's so bad that I can tell it's Claude, specifically Opus 4.8/5.0, from the first 6 words.
Opus 5 is very paranoid on giving proofs for every thing it claimed. so I let it keep this one line.
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#18Earlier quoted context omitted.
we use claude hooks. so that, post edits it auto updates and before using the graft tools also we check if it's already in sync. Hooks also solve for the issue of the LLMs not calling our CLI tools instead of Grep.
I'm thinking more in terms of the case where my coworkers' agents aren't working via graft, and changes are made without the post-edit update hooks.
if the changes are on your local when you pull those changes from the remote, graft will be auto-synced before graft tool use.
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#19Earlier quoted context omitted.
I'm thinking more in terms of the case where my coworkers' agents aren't working via graft, and changes are made without the post-edit update hooks.
if the changes are on your local when you pull those changes from the remote, graft will be auto-synced before graft tool use.
Oh, of course. Brilliant.
Re: Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
#20Love 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 incr…
For the staleness specifically we are using hooks on claude code and codex, where on every turn, or post edit or pre-tool use, we sync the graph. so that graph never goes stale.
We have run tests on DeepSWE as well which are long running tasks, we got 20% better accuracy on the tasks where sonnet 5 failed. didn't want to post that numbers yet as I think we can do better on DeepSWE and on a cheaper model like gpt-5.6-luna or grok-4.6