Better than grep obviously, but how does this compare to existing LSPs?
jerezzprime 2 hours ago [-]
I'd be interested in seeing actual agent benchmarks (eg CC or Copilot CLI with grep removed and this tool instead).
For example, I have explored RTK and various LSP implementations and find that the models are so heavily RL'd with grep that they do not trust results in other forms and will continually retry or reread, and all token savings are lost because the model does not trust the results of the other tools.
AussieWog93 51 seconds ago [-]
I just put something in my global CLAUDE.md (under ~/.Claude) asking it to use the LSP instead of grep and have never had this issue since.
nextaccountic 27 minutes ago [-]
Codex CLI is quite happy running RTK. Well with GPT 5.5 xhigh anyway
One thing that irks me is that when it doesn't support eg. a cli flag of find, it gives an error message rather than sending the full output of the command instead. Then the agent wastes tokens retrying, or worse, doesn't even try because the prompting may make them afraid to not run commands without rtk
aleksiy123 11 minutes ago [-]
how effective is RTK for you? worth using?
40 minutes ago [-]
giancarlostoro 1 hours ago [-]
I forced Claude to have a global memory for RTK and my own AI memory system (GuardRails) which it happily uses both, the only times it doesnt use GuardRails is if I dont mention it at all, otherwise it always uses RTK unless RTK falls apart running a tool it does not support.
stephantul 2 hours ago [-]
Yeah we're also interested in doing this, it's on the roadmap together with optimization of the prompt and descriptions so that models have an easier time using it.
Perhaps anecdotally: we do use this tool ourselves of course, and it's been working pretty well so far. Anthropic models call it and seem to trust the results.
abcdefg12 27 minutes ago [-]
Shouldn’t it be a part of the harness at least for local codebase? I wonder how many harnesses are doing that already.
dopidopHN2 20 minutes ago [-]
I'm playing with PI as a custom harness ( for Claude code because that what is provided to me )
I will try that ! It make sense and I'm curious to see results, for this or any similar projects mentioned in the thread
Semantic code search seems like a useful tool for a human too. Not just for agents.
porker 30 minutes ago [-]
Congratulations on the release!
Could you add fff to the benchmarks?
smcleod 1 hours ago [-]
How does it compare to context-mode or serina that are both well established now?
mrpf1ster 4 hours ago [-]
Does this work well for non-coding documents as well? Say api docs or AI memory files?
stephantul 4 hours ago [-]
Hey, this is something we're actively investigating. We recently added a flag, `--include-text-files`, which, when set, also makes Semble index regular documents (i.e., markdown, text, json). This should also work relatively well.
esafranchik 5 hours ago [-]
Is the benchmark measuring one-shot retrieval accuracy, or Coding agent response accuracy?
stephantul 5 hours ago [-]
Hey! Co-author here. The benchmark currently only measures retrieval accuracy.
We’re interested in measuring it end to end and also optimizing, e.g. the prompt and tools, for this, but we just haven’t gotten around to it.
esafranchik 4 hours ago [-]
Two follow-ups:
1) How do you compare accuracy? by checking if the answer is in any of the returned grep/bm25/semble snippets?
2) How do you measure token use without the agent, prompt, and tools?
stephantul 4 hours ago [-]
1) yes! It’s not accuracy, but ndcg
2) we assume that if the agent gets the correct answer in the returned snippets it does not need to read further
esafranchik 4 hours ago [-]
Wouldn't NDCG/token results vary wildly depending on the agent's query and the number of returned items?
e.g. agents often run `grep -m 5 "QUERY"` with different queries, instead of one big grep for all items.
stephantul 4 hours ago [-]
The same holds for semble: the agent can fire off many different semble queries with different k/parameters.
I guess the point we’re trying to make is that you need fewer semble queries to achieve the same outcome, compared to grep+readfile calls.
ludicrousdispla 4 hours ago [-]
grep doesn't need tokens, so what is 98% fewer than zero?
stephantul 4 hours ago [-]
You need readfile to do something with those tokens.
Grep only gives you the matching lines, not the context.
djaboss 3 hours ago [-]
`grep -C $NUM` ? ;)
stephantul 3 hours ago [-]
Even so. Take a look at the NDCG numbers for grep. It's not pretty
vikeri 1 hours ago [-]
very curious to give it a spin but why write a cli in python? would surely be faster and more portable with go or rust?
Rendered at 22:17:22 GMT+0000 (Coordinated Universal Time) with Vercel.
For example, I have explored RTK and various LSP implementations and find that the models are so heavily RL'd with grep that they do not trust results in other forms and will continually retry or reread, and all token savings are lost because the model does not trust the results of the other tools.
One thing that irks me is that when it doesn't support eg. a cli flag of find, it gives an error message rather than sending the full output of the command instead. Then the agent wastes tokens retrying, or worse, doesn't even try because the prompting may make them afraid to not run commands without rtk
Perhaps anecdotally: we do use this tool ourselves of course, and it's been working pretty well so far. Anthropic models call it and seem to trust the results.
I will try that ! It make sense and I'm curious to see results, for this or any similar projects mentioned in the thread
https://github.com/lightonai/next-plaid/tree/main/colgrep
Could you add fff to the benchmarks?
We’re interested in measuring it end to end and also optimizing, e.g. the prompt and tools, for this, but we just haven’t gotten around to it.
1) How do you compare accuracy? by checking if the answer is in any of the returned grep/bm25/semble snippets?
2) How do you measure token use without the agent, prompt, and tools?
e.g. agents often run `grep -m 5 "QUERY"` with different queries, instead of one big grep for all items.
I guess the point we’re trying to make is that you need fewer semble queries to achieve the same outcome, compared to grep+readfile calls.