shrishdwi

that's just when our claude limit's were about to exhaust :/ as we have to spin up a whole claude session to test it.

but you could 100% be Sherlock Holmes!

Feedback taken, actually as we have been iterating on this everyday, the README got updated by the coding agents in this process.

we are running them on a recurring basis, so will keep on updating that 50 number. and hence as it's currently running that section gets updated by claude only.

LSP is for when you already know the symbol and want an exact answer, like go-to-definition or find-references. graft is for the step before that: you ask "where does auth happen" and it hands the agent the right files and lines to start from, so it reads a lot less to get oriented.

so graft solves for making claude code understand your codebase every session.

And I feel you can save a lot more tokens and also increase accuracy by just switching to new claude session without worrying about your codebase context. (doesn't solve for the session context yet, but we are still figuring out how can we solve for that. Maybe hooks that can manage your CLAUDE.md)

We made this for X audience initially but got a lot of praise for it on reddit, so decided to put in the README. Sorry it made it more difficult for you.

In our tests, graft found the right code about twice as often as graphify (MRR 0.73 vs 0.38, recall@10 54% vs 20%). The difference is simple: graft searches inside the actual code, while graphify only looks at names and file paths.

You feel it while working too. graft hands the agent the exact file and line it needs for each question, so Claude keeps using graft.

Same is true for any other cli tools, claude never actually uses them as it's trained to use grep. but for graft as we set the directive to use graft at the start of the session and before the turn, claude just knows graft exists and also get the relevant context without it going and calling tools it was not trained on.

for your point #2: people are trying out to give coding agents LSP support, not sure though how well it'll work but it gives coding agents a better idea of the language in which the code is written.

We are using hooks to direct the coding agent to use graft grep instead of just grep, so this should ideally not happen.

Also, for java projects we do support a more deeper graph, a few of our contributors are working on making it better for java projects, let us know if you have any ideas there.

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

if the changes are on your local when you pull those changes from the remote, graft will be auto-synced before graft tool use.

Opus 5 is very paranoid on giving proofs for every thing it claimed. so I let it keep this one line.

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.

Thanks for sharing!