Live data from Hacker News

Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

github.com

91–100 of 187 posts

Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

#91
The savings are calculated against the assumption that agents read the matched files in their entirety. In my experience, they are smart enough to use grep to bring up a few lines of surrounding context, then read in full only the files that look relevant.

Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

#92

Earlier quoted context omitted.

This is a bit rude. We didn't generate this project, we wrote it, a lot of it manually, and trained custom models. We'd been working in the real-time retrieval space for a while, and we thought coding was a good fit for this specific technology.

My comment above wasn't meant to be rude. And you do have extensive benchmarks against grep etc so it's clear you understand the importance of that. But I still think you're missing the harder but more important proof which is agent evals. Have you done any of that? I would personally love to find tools in this space which can make agents more efficient and I do believe there's a scope for massive improvements compar…

It was directed at the parent who implied that we didn’t think about this.

I agree with your point about the evals and how you can get discontinuities: good search can be worse than bad search when agents can do many searches. We’re working on it

Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

#93

I 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…

There's an industry wide deficit of tests for AI right now. It's not just this tool, it's everything you add to your code base or your development flow that uses AI. Nobody had tests for "how fast/well was this developed" before AI and they haven't added them now.

Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

#94
Would be nice to see the actual % token/time saving across end-to-end coding sessions over these time periods https://github.com/MinishLab/semble#savings

My observation is that greps and the processing of grep outputs account for only a small portion of overall consumption; I haven't measured this scientifically though.

Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

#95

The savings are calculated against the assumption that agents read the matched files in their entirety. In my experience, they are smart enough to use grep to bring up a few lines of surrounding context, then read in full only the files that look relevant.

In practice this rarely happens though, at least in practice I rarely see agents "grep -C N" or something like that on files it didn't read yet. I use Claude Code and OpenCode extensively, and especially during the first pass through a codebase that is not well understood the agent often just does "cat file" or something similar and gets the entire file in context first, and only then starts doing more finegrained searches, but at that point you already have a lot of irrelevant context in memory. I think the whole value proposition of semble is that you don't have to do that initial read at all and can instead get the right (small) context bits. If you experience is different, would you mind sharing what your setup is like, e.g. how do you get the agent to read less?

Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

#96
post #94

Would be nice to see the actual % token/time saving across end-to-end coding sessions over these time periods https://github.com/MinishLab/semble#savings My observation is that greps and the processing of grep outputs account for only a small portion of overall consumption; I haven't measured this scientifically though.

Yeah this is a good point, but it's complicated to do well since semble then has to be aware of everything else that happens in a session, which would then make it more intrusive (and it's deliberately designed as a local, non-intrusive alternative to other solutions). I'm thinking that perhaps we can do an isolated opt-in benchmark for this perhaps.

Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

#97

What 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…

> These agentic AI's are already smart enough to figure out a highly optimized path to code exploration or search.

Hasn't been my experience. We used to use Augment Code at work which has a thing called Context Engine - basically an MCP that can answer natural language queries about pre-indexed code. Then we switched to Claude Code, which for some reason prefers to use sed to read from files using line ranges from its own memory (this despite having a range-capable read tool). I don't know, does that really mean that sed is the highly optimized path?

Re: Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep

#98

The one thing I'm a bit nervous about: security. Thoughts of supply-chain "what-ifs" gives me a bit of pause here. Would like to hear security-minded folks give their thoughts on this.

Hey, we do a couple of things specifically to prevent supply-chain attacks. We use trusted publishing on PyPI, and --exclude newer for uv's package resolution. We also try to use the least amount of dependencies possible. A transitive dependency could in theory still be problematic though, e.g. if there's a supply-chain attack on numpy.

The tool itself is fully local though, so there's no real security risks there, there are no outbound network calls or anything like that.

Post reply on HN