[flagged]
Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep
181–187 of 187 posts
Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep
#182Earlier quoted context omitted.
I'm seeing over and over again people claiming absurd optimizations for coding agents: > Our tool uses 99x fewer tokens and delivers 88x better results. Okay, great, but... 1) It's VERY difficult to quantify something is better . 2) They almost never post how they measured how much better it is and what the margin of error might be. 3) I assume they are incompetent and don't even try the tool. Like you pointed out, t…
Hey, this skepticism is fair and we share it, which is why we don't claim end-to-end agent improvements since we haven't measured those (yet). The benchmark we published measures retrieval quality and token count during search, not overall agent performance. We are working on agent-level evals, but those are unfortunately much harder to get right. However, we do believe that Semble makes agents better based on our ow…
> We are working on agent-level evals, but those are unfortunately much harder to get right.
It's unfortunately a nearly impossible task, as the models change regularly (without letting you know), so you have a moving (invisible) target that's 1) hard to test exhaustively, and 2) very expensive to test with any low margin of error.
This is why no one does it and just makes broad sweeping unverified claims instead.
If you figure out how to do it... You should probably just get a job at Anthropic or OpenAI and make $2M+ per year...
Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep
#183Related read (not from me): https://entire.io/blog/improving-agentic-search-in-coding-ag...
> The clearest result was that faster search alone only modestly helps, while better-ranked results improve first-query retrieval and help agents find the right code sooner.
Their tool "pgr" is a research preview only, so it'd be interesting to see semble vs pgr.
I'm also collecting other tools that are similar, most notably is probably Morph's WarpGrep (has a free tier too). Apart from that, there is codemogger (https://github.com/glommer/codemogger), cs (the author also commented in this HN post).
In the similar area, but not fully related, the author of fff is also pretty involved in any thread that goes into that direction (see e.g. https://x.com/neogoose_btw/status/2052161471296225710). Similar to colGREP is also mgrep (by mixedbread) and osgrep (but they seem to predate colGREP). I also found codedb on X (https://codegraff.com/blog/codedb-code-intelligence), the post reads well, but haven't tried.
Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep
#184I did some evals with pi and GPT 5.5. I tested RTK on / headroom on / both on / both off (all with the standard pi system instructions and no AGENTS.md). I forget the exact tests I used (a couple of the standard agent evals that people use, one python and one typescript because those are what I use). I don't claim it was an exhaustive test, or even a good one. It's possible I could have spent a day or so tuning my AG…
Have you tried https://github.com/mksglu/context-mode? I prefer it over rtk / headroom (at least in Cursor). The stop hooks seem to work well / prevent the agent from blowing up its context window.
Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep
#185What I have personally observed with such tools is that they make the AI's dumb, similar to how it makes coders dumb when relying more on AI tools. These agentic AI's are already smart enough to figure out a highly optimized path to code exploration or search. But, with these tools, they just go very aggressive, partly because the search results from these tools almost in 100% of the cases do not furnish full details…
I found this prompt works well to nudge it to use a better grep as the start, then just keep using grep (Cursors instant grep in my case):
``` - For planning, prefer using morph-mcp `codebase_search` - subagent that takes in a search string and tries to find relevant context. Best practice is to use it at the beginning of codebase explorations to fast track finding relevant files/lines. Do not use it to pin point keywords, but use it for broader semantic queries. "Find the XYZ flow", "How does XYZ work", "Where is XYZ handled?", "Where is coming from?" ```
(see also https://news.ycombinator.com/item?id=48205911; having higher quality results at the beginning of a thread seem to improve the output vs. having faster search later on).
Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep
#186Earlier quoted context omitted.
You didn’t use `ck` directly, you instructed Claude Code to use `ck`, right?
Tried both right now. Tried against a 84K loc C project. ck took at least 5 minutes to index, but replies are indeed fast. semble indexing (if any) took no noticeable time (except for the first download of HF model, which took a couple seconds), and replied in a couple of seconds. Unrelated but ck was a pain to install / compile (install instructions do not say you have to lock the build / you have to have latest lib…
Done some work fixing some of these issues. Please do raise issues when you find them and I'll get them fixed! (author)
Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep
#187What I have personally observed with such tools is that they make the AI's dumb, similar to how it makes coders dumb when relying more on AI tools. These agentic AI's are already smart enough to figure out a highly optimized path to code exploration or search. But, with these tools, they just go very aggressive, partly because the search results from these tools almost in 100% of the cases do not furnish full details…
I'm seeing over and over again people claiming absurd optimizations for coding agents: > Our tool uses 99x fewer tokens and delivers 88x better results. Okay, great, but... 1) It's VERY difficult to quantify something is better . 2) They almost never post how they measured how much better it is and what the margin of error might be. 3) I assume they are incompetent and don't even try the tool. Like you pointed out, t…
[deleted]