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, but, just the pointers.
To confirm this behaviour, I did a small test run. This is in no way conclusive, but, the results do align with what I been observing:
---
Task: trace full ingestion and search paths in some okayish complex project. Harness is Pi.
1. With "codebase-memory-mcp": 85k/4.4k (input/output tokens).
2. With my own regular setup: 67k/3.2k.
3. Without any of these: 80k/3.2k.
As we see, such a tool made it worse (not by much, but, still). The outputs were same in quality and informational content.
---
Now, what my "regular setup" mentioned above is?:
Just one line in AGENTS.md and CLAUDE.md: "Start by reading PROJECT.md" .
And PROJECT.md contains just following: 2-3 line description of the project, all relevant files and their one-line description, any nuiances, and finally, ends with this line:
## To LLM
Update this file if the changes you have done are worth updating here. The intent of this file is to give you a rough idea of the project, from where you can explore further, if needed.
> 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?
Lol... I noticed it does weird stuff sometimes. I'll see it generate a python script inline on the CLI to edit files. Like... Yo what the fuck? It literally used the edit tool until 5 turn ago.
Also, it'll run a formatter, read, edit to undo auto formatting and then continue on its merry way. What is the point of that??? Lol
Hey, codebase-memory-mcp and semble are not exactly the same, but it's an interesting comparison, I'll put it on the todolist to check that out and add it to our benchmarks if feasible. If you ever get a chance to do this same comparison with semble it would be super useful feedback since these "real" scenarios are hard to benchmark/replicate.
So, I just tested with semble. Your MCP integration did not work, and kept throwing error (Failed to connect to "semble": MCP error -32000: Connection closed) though I installed using documented manner (tried both: pip and ux methods).
Anyways, I made it work by making it generate relevant doc (using semble init), and then copying this into AGENTS.md, and then prompting it with this line:
"""
Start by reading AGENTS.md in current folder. Now, the task::: `Explore the ingestion and search paths. Do not read README.md at all`. Prefer to use `semble` search for code search. Do not do new installation. semble is already available at `/Users/nitinbansal/.local/bin/semble` .
"""
The results are much better. Even better than my own setup, but, vary a lot. I did 4 runs:
Sorry to hear about the MCP integration, that's definitely something we'll look into. If you have any info about your system or how to reproduce it please let me know. Very nice to hear about the results, thanks for checking this! The variance is interesting to see, that's probably non-determinism in the LLM rather than semble since semble is deterministic. But I'm guessing we can make that better with the prompt, I'll look into this.
uv failed for me once, but then worked the second time. I think it has to do with uv just taking a while to install the first time. Maybe if you pre-run the installation it'll work better.
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 <error message> coming from?"
```
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, the odds these things make agents worse is FAR higher than they make them better.
Not saying it's impossible, but if it was possible on the scales they are claiming, it probably would already be done, or put into the next release of the agents...
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 own experience of using it for the past months while in development (or at the very least, cheaper).
> 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...
Doing that would mean copying and keeping in-sync two files: AGENTS.md and CLAUDE.md since I use both, claude, and others intercheangeably in one project.
Also, I dont want to keep my project's details in those files, but, keep it separate.
With current setup/way, a single line in both satisifies all constraints and requirements.
I use AGENTS.md as the "global" agent file, then use CLAUDE.md as a light wrapper with Claude-specific instructions which ends in an instruction to read AGENTS.md .
Interesting. I too have been working in this space, though I took a different approach. Rather than building an index, I worked on making a "smarter grep" by offering search over codebases (and any text content really) with ranking and some structural awareness of the code. Most of my time was spend dealing with performance, and as a result it runs extremely quickly.
I will have to add this as a comparison to https://github.com/boyter/cs and see what my LLMs prefer for the sort of questions I ask. It too ships with MCP, but does NOT build an index for its search. I am very curious to see how it would rank seeing as it does not do basic BM25 but a code semantic variant of it.
This seems to work better for the "how does auth work" style of queries, while cs does "authenticate --only-declarations" and then weighs results based on content of the files, IE where matches are, in code, comments and the overall complexity of the file.
I was going to share a link to this. Thank you for making `cs`, I use it both with LLMs and directly in the terminal, despite not performing indexing it's pretty fast for my needs. Also definitely planning to try out semble.
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 AGENTS.md and the pi system prompt/tool instructions and gotten better results, because if there's one thing running evals taught me it's that subtle differences there can change the results a lot.
However, I got clearly better results with both off, enough to convince me to stop the tests immediately after 3 rounds.
The problem was that while context use did go down (sometimes), the number of turns to complete went up so the overall cost of the conversation was higher.
It's made me very aware of one thing: so many people are sharing these kind of tools, but either with zero evals (or suspiciously hard to reproduce), or in the case of this one, extensive benchmarks testing the wrong thing.
I'm sure this tool does use fewer tokens than grep, and the benchmarks prove it, but that's not what matters here. What matters is, does an agent using it get the same quality of work done more quickly and for lower cost?
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.
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.
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 compared to default workflows. But my evals with RTK and Headroom have made me wary that a tool can look like it should work, conceptually make sense, pass non-agentic benchmarks, and still make an actual agentic workflow worse.
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
When you share them, please also share the setup for people to easily rerun them. Nearly every eval I've seen shares the llm session transcript but not the actual harness setup etc. that they used.
yeah I think I'm prone to do the same, it is so easy to create and we get too excited by it instead of first doing the research necessary which is much more boring than actually producing something.
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.
I've tried all sorts of tricks with Copilot CLI to get it to use LSP; project instructions, file extension instructions, but it just keeps forgetting. And says "yea you're right I should have used it" but then doesn't.
Full output below. There's other stuff in there, the "working with unfamiliar data or systems" is maybe slightly risky but (seemingly, after a week or two) much more token efficient and effective.
I also added the plugins directly to Claude Code:
ty Plugin · claude-code-lsps · enabled
vscode-langservers Plugin · claude-code-lsps · enabled
vtsls Plugin · claude-code-lsps · enabled
~ cat ~/.claude/CLAUDE.md
# Python Environment
- ALWAYS use uv — never use pip, pip install, python, or python3 directly
- Activate venv: `source .venv/bin/activate`
- Install deps: `uv sync`
- Add a dep: `uv add <package>`
- Run scripts: `uv run <script.py>`
- Run tools: `uvx <tool>`
# Long-running scripts
- Any script, command, migration, data job, or test run that may take more than 2-3 seconds should emit regular status updates while it runs.
- Prefer progress that is useful for diagnosing where time is going: current phase, item counts, batch numbers, elapsed time, retry/backoff state, or the external service being waited on.
- For loops or batch jobs, log progress periodically rather than only at start/end; keep the cadence readable and avoid flooding output.
# Code Intelligence
- LSP servers available: ty (Python), vtsls (JS/TS), vscode-langservers (HTML/CSS/JSON)
- Use LSP for:
- findReferences before any refactor
- goToDefinition when navigating unfamiliar code
- diagnostics after edits to catch type errors
- grep/search is fine for simple lookups in small files
- NEVER refactor without findReferences impact analysis first
- After every edit, check LSP diagnostics before moving on
# Documentation
- Context7 is available for up-to-date library docs
- Use `ctx7 docs <libraryId> <query>` to fetch current documentation
- Use `ctx7 library <name> <query>` to find a library ID first
# Working with unfamiliar data or systems
- Prefer experimenting on real data over reasoning about it in the abstract. Your outputs are noticeably better when grounded in a concrete sample than when derived from minutes of speculation.
- When a task involves parsing/processing/integrating with some external artifact (a report, an API response, a file format, a third-party tool's output), the FIRST step is to fetch or generate a real example and inspect it. Do not write code against an imagined shape.
- Experiments must be non-destructive: read-only fetches, copies into a scratch dir, dry-run flags. Never mutate the user's real data to learn about it.
- Before assuming you lack credentials, check the current working directory's `.env` file (and `.env.example` for hints about which keys exist) — API keys, tokens, and connection strings for the relevant service are very often already there.
- If you cannot obtain real data on your own (auth genuinely missing, lives on another machine, behind a paywall, etc.), STOP and ask the user to provide a sample rather than guessing.
- Example: asked to process an Amazon sales report, the first action is to fetch (or have the user paste) one actual report and look at its columns — not to draft a parser based on what such a report "probably" contains.
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
I found judicial use of rtk on specific commands that you know can be improved with rtk, e.g. go test, pnpm test (vitest), etc. to be worthwhile, at least in CC. But using their default setup which is to prepend rtk to everything is more trouble than its worth. I have a custom-built hook that prepends rtk based on a hierarchical whitelist.
And you should disable the savings reporting feature since it’s worse than useless—it breaks sandboxing and always reports ~100% savings for me because rtk obviously doesn’t know about the head/tail the agent pipes into.
I can't find the relevant issues in their repo, but I've been somewhat skeptical of their tool over-reporting token savings and there are many issues to that effect in the repo.
I'm not likely to install it again in my latest configuration, instead applying some specific tricks to things like `make test` to spit out zero output exit on unsuccessful error codes, that sort of thing. Anecdotally, I see GPT-5.5 often automatically applying context limiting flags to the bash it writes :shrug:
I've had the same experience with RTK, where my agent got stuck in a loop with a faulty RTK command and could not escape it since RTK hard overwrites anything automatically. I've uninstalled it again for the time being.
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.
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.
Token savings is more and more important, but it also important if the agent trusts the result and stops searching. it should measure the full agent loop instead of just the search output
At least codex listens to me telling it to use rg instead of grep, cause grep is often so slow. But when adding rtk it uses grep through rtk which is kind of annoying.
I think the best bet is to use some kind of proxy so when the model calls grep, you intercept the call, use other tool to search and give back the results to the model.
Hey, this is something we're actively working on, but this is hard (and expensive) to do well across harnesses/models. The grep pretraining thing is very interesting though, I've noticed the same. E.g. Sonnet 4.6 seems to trust semble but Opus 4.7 less so. I'm hoping we can quantitatively test this and improve it when we have proper benchmarks for this as well. If you do have any feedback though let me know!
Seems like a cool idea so I decided to play with it a bit. The test I ran was in the browsercode (https://github.com/browser-use/browsercode) repo with the following prompt:
"Answer this question by only using the `semble` CLI (docs below):
> What tools does Browsercode provide to the agent other than the base OpenCode tools? Provide the exact schema for tool input and tool output and briefly summarize what they do and how they work
"Answer this question by only using the `rg` and `fd` CLIs:
> What tools does Browsercode provide to the agent other than the base OpenCode tools? Provide the exact schema for tool input and tool output and briefly summarize what they do and how they work"
In both cases, I used Pi with gpt-5.4 medium and a very minimal setup otherwise. (And yes, I did verify that either instance only used rg & fd, or only used semble.)
Without Semble, it used 10.9% of the model context and used $0.144 of API credits (or, at least, that's what Pi reported - I used this with a Codex sub so cannot be sure). With Semble, it used 9.8% of the model context and $0.172 of API credits. The resulting responses were also about the same. Very close!
I tried one more test in the OpenCode repo. The question was
> Trace the path from 1) the OPENCODE_EXPERIMENTAL_EXA env var being set to to 1 to 2) the resulting effects in the system prompt or tool provided to the OpenCode agent.
And I included the same instructions/docs as above. The non-Semble version was a bit more detailed -- it went into whether the tool call path invoked Exa based on whether Exa or Parallel was enabled for the web search provider -- but w.r.t. actually answering the question, both versions were accurate. The Semble version used 14.7% context / $0.282 API cost, while the non-Semble version used 19.0% / $0.352. Clearly a win for Semble for context efficiency, but note that the non-Semble version finished about twice as fast as the Semble version.
> 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).
I know this tool was meant for AI, but I am more interested in using it myself when exploring new code bases or even my own, when I want to refactor something and want an overview of where to change stuff. LSPs do that, but this tool sounds like it can go one step further.
Nice, this sounds great. I want to mention a related issue here, which is that on small codebases, Claude spends a lot of time looking for stuff when it could have just dumped the whole codebase into the context in one go and used very little tokens.
I found a nice workaround which is that you can just dump the whole directory into context, as a startup hook. So then Claude skips the "fumble around blindly in the dark" portion of every task. (I've also seen a great project that worked on bigger repos where it'll give the model an outline with stubs, though I forget what it was called.)
I actually made a custom harness based on Aider's edit format (the find/replace thing). (I think most AI stuff ended up using a very similar format.)
It just does what I need and no more: load code into context, append my question or instruction, call LLM, apply patches. Repeat.
I haven't used Aider itself though, maybe it does that too.
My harness was nice relative to Claude Code and Codex because, it doesn't need to poke around the filesystem (cause I have small repos and dump the whole thing), and it makes all edits simultaneously (doesn't need to edit one file at a time).
It reads all files and edits all necessary files in a single round trip.
The really nice thing is that when you're making many small fine grained changes like that, you can use a much smaller, faster, cheaper model.
And if it's fast enough, it actually becomes a real-time activity. It's not "prompt, wait..." but "prompt, immediately get the result." It's interactive. You stay active and engaged. It's great.
Yeah I agree. I have used semble to quickly index a large monorepo and just ask a question about it, it surfaced the right files pretty quickly. Although without an IDE, it's difficult to display them in nice way
LSPs are already miles better than grep-like tools. This was true for humans as much as it is for LLMs. It's a shame that Claude still treats it as a second-class citizen (both in the app itself and in the training). A simple "remember to use LSP instead of grep" is usually enough to get it on the right track.
Try running both on the CK codebase. CK takes like 15 minutes to index itself and gives hundreds of completely irrelevant doc comments as results for “run model on CPU” query. Semble indexes for like 3 seconds and prints out the actual code that runs the model on the CPU.
No? CK is better than I gave it credit for, didn’t take 15 minutes, took 2, somehow a lot faster than before, probably system busy. I was using hybrid which is wrong for this query.
Still semble is a few orders of magnitude faster and gave better results against ck —-sem. I am running both on rust-lang/rust and CK is going to take hours at least, extrapolating from current stats probably 3 days? Semble: 26 seconds without any caching. The thing doesn’t have a cache and it’s still massively faster. I added caching support and watchman integration and got it down to 1.4 seconds. 3 days is basically not good enough for this use case. It’s slow enough that indexing is going to lag your code changes. Semble is fast enough that it’s not going to be behind.
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 libc).
So about a year ago I wrote my own attempt at something like this using vector indexing and BM25 (the latest version uses CocoIndex, I had a custom coded solution using ChromaDB before). I wrote a comprehensive enough test set that showed performance increases on the quality of search results and reduction in token usage versus grep and rg. I haven't had time to really polish it but it worked well enough, particularly for one project where I have around 250k documentation files and docs out number code files 1000 to 1 (about 50% reduction in tokens and 30% increase in successful searches). Yesterday for grins I tried this project and was fairly disappointed to see it blow away my kludged solution particularly given that it doesn't have a lengthy indexing process. I haven't tested it on the 250k doc project yet, but in another project that I have a test suite for semantic search on it outperformed my solution by about 20% even on documentation in terms of successful search results (which I didn't expect given that it seems to only be tuned for code). I haven't gone through the code to see what its doing differently than what I tried, but what ever its doing it seems to have potential.
I also like the index feature form https://maki.sh
Source code has a lot of structure, using a real parser instead of grepping and reading files can potentially save a lot of tokens
Afaik many harnesses ship the "default" which is grep+read (like Claude Code). But I agree, IMO it's a weird gap. To be fair I don't think providers are that incentivised to reduce token burn at the moment, but my guess is that that will change and tools like this will become at least an natively supported option in some harnesses.
I would be surprised if, in the "mature" future of AI tools/products, the labs building the models are also selling/building to end users like they are now.
Would or wouldn't be? I think it makes sense that they will be because of the feedback loop on training. The lab generates tons of example text as part of the training run and if they have that using their own tools then the models will tend to prefer those tools.
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.
The bigger problem with solutions like these is that most AI already know how to use grep and search really well because of their training. Any such new tool that you handle to the AI, takes away from the cognitive capability of the AI. Humans would normally 'learn' how to operate tools like this - but the learning in LLM's is frozen and they already with a very strong depth in existing tools like grep.
For example, an AI would already use linux commands like tree to traverse the code base. And again it already has good training in this.
The other problem is that it is easy to cook up examples which demonstrate the efficacy of tools like these - but actually proving that the cognitive deficit that such tools result it, is surmounted by their efficacy in long horizon runs. My first contact instinct is that this will result in a net negative 'deployable intelligence' over long horizon runs - make the agent perform worse than using existing tools.
Proving the opposite is a non-trivial problem - but maybe it might be something you want to take up.
Metric that measures the quality beyond simple tokens count: correction loop frequency.
When grep does not find a file of interest, the agent does not fail; it will continue working on an incomplete context. For a monolingual code base, the miss rate is okay. In case of polylingual code (Python backend code and TypeScript frontend code), the problems emerge when it comes to querying for cross-file dependencies. Grep will return a route from the backend API. However, there is an interface in TypeScript that needs to be matched. Agent generates a response that does not fit the type. Correction cycle is one; two if the type conflict is ambiguous.
Combining grep with the understanding of semantic relations between files is a solution. Number of tokens saved is real but underestimates the actual benefit since fewer correction cycles are more valuable than tokens themselves.
Cool project. I built a custome IDE and coding agent harness and will integrate this into it. If you’re interested in a collaboration, I’d be happy to share revenue to sponsor your open source repo.
Interesting for sure, but I think I need to be convinced this is necessary. How many tokens does Grep use on the average response anyways? Does this reduce input token usage from 100k to 2k per query or from 1k to 20? How does this effect output code quality?
There's a "semble savings" command you can run to see token savings. It varies heavily based on the repo: in general, the larger the project the larger the savings. Output code quality is something we're still trying to measure, but it's much harder than measuring retrieval quality.
Gotcha. Might be interesting to show some plots of average/median/max input token savings per query as a function of repo size if you're going to do some more comparison testing. The efficiency gains are compelling, but I'd want to see the magnitude of gains as well to get a full picture. Regardless, cool project and I'll check it out for myself
So are we supposed to believe that grep is so wasteful that models are reading 98% useless garbage every time they call it? Either this claim is not representative, or you're missing something else when you throw away the vast majority of context for the model.
The 98% is vs the grep+read loop, not grep output alone. When an agent hits an unfamiliar codebase it typically does "cat file" or reads the whole thing first, at least in my experience. If you're reliably getting agents to do "grep -C N" and stop there I'd genuinely be curious what your setup looks like, because I think the quality of the results is just too low to serve as useful context.
> When an agent hits an unfamiliar codebase it typically does "cat file" or reads the whole thing first, at least in my experience.
Depends on the size of the project and specific files. I have definitely seen agents make smart use of pi's "read" tool, which can take an offset and line limit (or defaults to a max 2000 lines/50KiB if the model doesn't specify). The bash tool also has the same max output, so if a model decides to cat instead of using the read tool it still wont blow out its context window with a single large file read.
But this sort of thing is going to vary with harness, model, project, and whatever the RNG delivers for the day.
I had problems with Claude reading hundreds of kilobytes of outputs because grep found things in node_modules. (ripgrep helps, so it makes sense to add a line about it into some memory file.)
Grep prints out every matching line. For some searches a LLM might do it will get a lot of noise, and it might have to make that search because it cannot be specific. Targeted search can reduce the number of tokens.
I suspect this comparison is against reading the whole codebase though compared to just getting the bits you need.
codex-cli hangs when calling this through the MCP. The semble process even sticks around as a zombie, forever stalled out. No idea why, logs have nothing.
When called through a skill via CLI style calling, GPT 5.5 loves to give a ton of search terms like it is used to doing with ripgrep. Not sure how effective this is, the short docs in the github and the instructions the agent has isn't clear on what is optimal.
Lastly, I got some errors with external connections to github when I was installing it for bash use. Maybe its related to the hanging? No idea.
edit: My agent also loves to follow-on with ripgrep, which seems redundant. Acts like it has trust issues. I think a more extensive agent skill description could guide the agent into proper use.
Hey, thanks for the detailed feedback. For the bug, would you mind opening an issue with your setup details? This is definitely something we want to investigate and fix. The multiple queries thing is really good feedback, thanks for that, we'll update the prompt/instructions to prevent this from happening and we'll try to add some tests for this. The external connection errors during install are uv fetching deps from PyPI I think, those should not be the reason it's hanging.
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.
Serena does a lot more than semble (I actually used serena before building this and didn't like how much it does by default). That also made it hard to see if it was actually working well with how many moving parts there are. Semble only does 1 thing: very quick code search, that's it. Context-mode I have not used before though, I will have a look at that, thanks for sharing!
This looks great! I built a tool in the same space- and I found that the biggest challenge was often to get the agent to prefer to use the tool over bash tools. What’s your experience with that?
"The problem is that there are several bottlenecks internally," which include the requirements, specs, and testing. Another one not mentioned in the article.
Before you had faster implementation times, something would take six weeks to implement. Feedback from the client about how far off target you were came through in the same amount of time: a help desk ticket, a post-call check-in, a quarter end review. The price you paid for being off target was proportional to how long it took to figure out.
Now, when you can ship features in an afternoon, the customer feedback loop remains the same speed. Surveys, help desk tickets, and churn analysis come back days, even weeks later, by which point you've shipped five new features going the same way.
You can fix the internal bottlenecks easily enough: write better specs, have faster test cycles, deploy continuously. The customer feedback loop bottleneck is built into the system. It won't get any faster just because implementation did.
Today most organizations are busy fixing the internal bottleneck, but not the external one.
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?
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.
Have you considered solving a different problem? What are agents trying to achieve when searching a code base? Finding seams. How about indexing seams instead?
The first is hard to test for us unfortunately since we don't use Cursor. But the Claude thing is interesting. I think that providers (especially the ones that directly sell LLM calls like Anthropic) are not incentivised per se to think about token efficiency vs performance, so if you're chasing pure performance, just loading the full codebase into memory might still be the "benchmark topping" way to go. I think the dust hasn't really settled yet and we'll likely see a lot of changes in the coming year about what's the "correct" way to solve it. It might be different based on your harness/budget/model as well.
In theory maybe, but in practice it hurts more than it helps I think. Irrelevant context makes the model more likely to reason from the wrong code (and it's slower and more expensive).
Exciting. I've been playing with AI dev pipelines and the "give the agent the full codebase vs. let it search" trade-off is what I keep running into - both have pros and cons depending on the task. This looks like the latter pushed harder than I've seen before. Looking forward to trying it
For chunking Semble supports all languages supported by tree-sitter-language-pack. The models we train are trained on 6 languages, but can handle way more.
Fair, many tools trade off cost for performance/adherence. So far our experience is good with Semble (at least with Anthropic/OpenAI models), but if you have any feedback feel free to reach out. We're working on evaluations for this as well, though it will take some time as this is much harder than benchmarking retrieval quality.
We might not be AI/agent enough for this product. I wondered about that as well, but it's not actually a grep problem, it's an ingest problem for agents. Apparently some agents use grep to navigate code and it's this "operation" that consume tokens, grep does in fact consume zero tokens.
Hey, what's the issue with a disk search-lib in python specifically? The library is extremely fast. Yes, we could probably squeeze some more performance in Rust, but that's not our native programming language, so we opted for doing it correctly rather than use a language that we don't understand well enough.
Perhaps Python is their main language (they seem to be ML peeps, which would make that most likely), which means it's easier for them to do manual reviews even if they're using AI for implementing, etc.
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, but, just the pointers.
To confirm this behaviour, I did a small test run. This is in no way conclusive, but, the results do align with what I been observing:
---
Task: trace full ingestion and search paths in some okayish complex project. Harness is Pi.
1. With "codebase-memory-mcp": 85k/4.4k (input/output tokens).
2. With my own regular setup: 67k/3.2k.
3. Without any of these: 80k/3.2k.
As we see, such a tool made it worse (not by much, but, still). The outputs were same in quality and informational content.
---
Now, what my "regular setup" mentioned above is?:
Just one line in AGENTS.md and CLAUDE.md: "Start by reading PROJECT.md" .
And PROJECT.md contains just following: 2-3 line description of the project, all relevant files and their one-line description, any nuiances, and finally, ends with this line:
> 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?
Lol... I noticed it does weird stuff sometimes. I'll see it generate a python script inline on the CLI to edit files. Like... Yo what the fuck? It literally used the edit tool until 5 turn ago.
Also, it'll run a formatter, read, edit to undo auto formatting and then continue on its merry way. What is the point of that??? Lol
I’ve seen Claude write a one line Perl script to pull items from a json file.
Hey, codebase-memory-mcp and semble are not exactly the same, but it's an interesting comparison, I'll put it on the todolist to check that out and add it to our benchmarks if feasible. If you ever get a chance to do this same comparison with semble it would be super useful feedback since these "real" scenarios are hard to benchmark/replicate.
So, I just tested with semble. Your MCP integration did not work, and kept throwing error (Failed to connect to "semble": MCP error -32000: Connection closed) though I installed using documented manner (tried both: pip and ux methods).
Anyways, I made it work by making it generate relevant doc (using semble init), and then copying this into AGENTS.md, and then prompting it with this line:
""" Start by reading AGENTS.md in current folder. Now, the task::: `Explore the ingestion and search paths. Do not read README.md at all`. Prefer to use `semble` search for code search. Do not do new installation. semble is already available at `/Users/nitinbansal/.local/bin/semble` . """
The results are much better. Even better than my own setup, but, vary a lot. I did 4 runs:
95k/2.9k
25k/2.7k
71k/2.9k
37k/4.0k
Sorry to hear about the MCP integration, that's definitely something we'll look into. If you have any info about your system or how to reproduce it please let me know. Very nice to hear about the results, thanks for checking this! The variance is interesting to see, that's probably non-determinism in the LLM rather than semble since semble is deterministic. But I'm guessing we can make that better with the prompt, I'll look into this.
uv failed for me once, but then worked the second time. I think it has to do with uv just taking a while to install the first time. Maybe if you pre-run the installation it'll work better.
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 <error message> 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).
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, the odds these things make agents worse is FAR higher than they make them better.
Not saying it's impossible, but if it was possible on the scales they are claiming, it probably would already be done, or put into the next release of the agents...
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 own experience of using it for the past months while in development (or at the very least, cheaper).
> 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...
> Just one line in AGENTS.md and CLAUDE.md: "Start by reading PROJECT.md" .
> And PROJECT.md contains...
…Why not just use that PROJECT.md as the AGENTS/CLAUDE.md?
Doing that would mean copying and keeping in-sync two files: AGENTS.md and CLAUDE.md since I use both, claude, and others intercheangeably in one project.
Also, I dont want to keep my project's details in those files, but, keep it separate.
With current setup/way, a single line in both satisifies all constraints and requirements.
I use AGENTS.md as the "global" agent file, then use CLAUDE.md as a light wrapper with Claude-specific instructions which ends in an instruction to read AGENTS.md .
That works better. I just personally avoid touching global configs, hence, the project specific copy-pasting of two files.
Interesting. I too have been working in this space, though I took a different approach. Rather than building an index, I worked on making a "smarter grep" by offering search over codebases (and any text content really) with ranking and some structural awareness of the code. Most of my time was spend dealing with performance, and as a result it runs extremely quickly.
I will have to add this as a comparison to https://github.com/boyter/cs and see what my LLMs prefer for the sort of questions I ask. It too ships with MCP, but does NOT build an index for its search. I am very curious to see how it would rank seeing as it does not do basic BM25 but a code semantic variant of it.
This seems to work better for the "how does auth work" style of queries, while cs does "authenticate --only-declarations" and then weighs results based on content of the files, IE where matches are, in code, comments and the overall complexity of the file.
Have starred and will be watching.
I was going to share a link to this. Thank you for making `cs`, I use it both with LLMs and directly in the terminal, despite not performing indexing it's pretty fast for my needs. Also definitely planning to try out semble.
You are welcome. Glad to hear its working for you. I have a few ideas I am working on to improve its relevance too that I hope pan out.
Nice! Let us know if you have any feedback or results to share, would be happy to do the same.
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 AGENTS.md and the pi system prompt/tool instructions and gotten better results, because if there's one thing running evals taught me it's that subtle differences there can change the results a lot.
However, I got clearly better results with both off, enough to convince me to stop the tests immediately after 3 rounds.
The problem was that while context use did go down (sometimes), the number of turns to complete went up so the overall cost of the conversation was higher.
It's made me very aware of one thing: so many people are sharing these kind of tools, but either with zero evals (or suspiciously hard to reproduce), or in the case of this one, extensive benchmarks testing the wrong thing.
I'm sure this tool does use fewer tokens than grep, and the benchmarks prove it, but that's not what matters here. What matters is, does an agent using it get the same quality of work done more quickly and for lower cost?
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.
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.
with AI the "they could so they never wondered if they should" will be a very frequent thing.
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 compared to default workflows. But my evals with RTK and Headroom have made me wary that a tool can look like it should work, conceptually make sense, pass non-agentic benchmarks, and still make an actual agentic workflow worse.
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
When you share them, please also share the setup for people to easily rerun them. Nearly every eval I've seen shares the llm session transcript but not the actual harness setup etc. that they used.
yeah I think I'm prone to do the same, it is so easy to create and we get too excited by it instead of first doing the research necessary which is much more boring than actually producing something.
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.
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.
I've tried all sorts of tricks with Copilot CLI to get it to use LSP; project instructions, file extension instructions, but it just keeps forgetting. And says "yea you're right I should have used it" but then doesn't.
My q would have been this. Lsp solved this no?
can you share that prompt?
Full output below. There's other stuff in there, the "working with unfamiliar data or systems" is maybe slightly risky but (seemingly, after a week or two) much more token efficient and effective.
I also added the plugins directly to Claude Code: ty Plugin · claude-code-lsps · enabled vscode-langservers Plugin · claude-code-lsps · enabled vtsls Plugin · claude-code-lsps · enabled
# Python Environment - ALWAYS use uv — never use pip, pip install, python, or python3 directly - Activate venv: `source .venv/bin/activate` - Install deps: `uv sync` - Add a dep: `uv add <package>` - Run scripts: `uv run <script.py>` - Run tools: `uvx <tool>`# Long-running scripts - Any script, command, migration, data job, or test run that may take more than 2-3 seconds should emit regular status updates while it runs. - Prefer progress that is useful for diagnosing where time is going: current phase, item counts, batch numbers, elapsed time, retry/backoff state, or the external service being waited on. - For loops or batch jobs, log progress periodically rather than only at start/end; keep the cadence readable and avoid flooding output.
# Code Intelligence - LSP servers available: ty (Python), vtsls (JS/TS), vscode-langservers (HTML/CSS/JSON) - Use LSP for: - findReferences before any refactor - goToDefinition when navigating unfamiliar code - diagnostics after edits to catch type errors - grep/search is fine for simple lookups in small files - NEVER refactor without findReferences impact analysis first - After every edit, check LSP diagnostics before moving on
# Documentation - Context7 is available for up-to-date library docs - Use `ctx7 docs <libraryId> <query>` to fetch current documentation - Use `ctx7 library <name> <query>` to find a library ID first
# Working with unfamiliar data or systems - Prefer experimenting on real data over reasoning about it in the abstract. Your outputs are noticeably better when grounded in a concrete sample than when derived from minutes of speculation. - When a task involves parsing/processing/integrating with some external artifact (a report, an API response, a file format, a third-party tool's output), the FIRST step is to fetch or generate a real example and inspect it. Do not write code against an imagined shape. - Experiments must be non-destructive: read-only fetches, copies into a scratch dir, dry-run flags. Never mutate the user's real data to learn about it. - Before assuming you lack credentials, check the current working directory's `.env` file (and `.env.example` for hints about which keys exist) — API keys, tokens, and connection strings for the relevant service are very often already there. - If you cannot obtain real data on your own (auth genuinely missing, lives on another machine, behind a paywall, etc.), STOP and ask the user to provide a sample rather than guessing. - Example: asked to process an Amazon sales report, the first action is to fetch (or have the user paste) one actual report and look at its columns — not to draft a parser based on what such a report "probably" contains.
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
how effective is RTK for you? worth using?
I found judicial use of rtk on specific commands that you know can be improved with rtk, e.g. go test, pnpm test (vitest), etc. to be worthwhile, at least in CC. But using their default setup which is to prepend rtk to everything is more trouble than its worth. I have a custom-built hook that prepends rtk based on a hierarchical whitelist.
And you should disable the savings reporting feature since it’s worse than useless—it breaks sandboxing and always reports ~100% savings for me because rtk obviously doesn’t know about the head/tail the agent pipes into.
I can't find the relevant issues in their repo, but I've been somewhat skeptical of their tool over-reporting token savings and there are many issues to that effect in the repo.
I'm not likely to install it again in my latest configuration, instead applying some specific tricks to things like `make test` to spit out zero output exit on unsuccessful error codes, that sort of thing. Anecdotally, I see GPT-5.5 often automatically applying context limiting flags to the bash it writes :shrug:
I've had the same experience with RTK, where my agent got stuck in a loop with a faulty RTK command and could not escape it since RTK hard overwrites anything automatically. I've uninstalled it again for the time being.
I had better results with lean ctx and context mode than with rtk.
Wondering too
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.
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.
Token savings is more and more important, but it also important if the agent trusts the result and stops searching. it should measure the full agent loop instead of just the search output
>so heavily RL'd with grep
At least codex listens to me telling it to use rg instead of grep, cause grep is often so slow. But when adding rtk it uses grep through rtk which is kind of annoying.
I tried to use rtk once and the model got stuck just running and rerunning and rerunning in a loop, until I killed it. I have no idea what happened.
I think the best bet is to use some kind of proxy so when the model calls grep, you intercept the call, use other tool to search and give back the results to the model.
True. Just have the interface that behaves like grep and the output is as expected like grep but internally: indexed, ranked, ...
So the model trusts the output because it is grep :D
Hey, this is something we're actively working on, but this is hard (and expensive) to do well across harnesses/models. The grep pretraining thing is very interesting though, I've noticed the same. E.g. Sonnet 4.6 seems to trust semble but Opus 4.7 less so. I'm hoping we can quantitatively test this and improve it when we have proper benchmarks for this as well. If you do have any feedback though let me know!
Seems like a cool idea so I decided to play with it a bit. The test I ran was in the browsercode (https://github.com/browser-use/browsercode) repo with the following prompt:
"Answer this question by only using the `semble` CLI (docs below):
> What tools does Browsercode provide to the agent other than the base OpenCode tools? Provide the exact schema for tool input and tool output and briefly summarize what they do and how they work
---
[the AGENTS.md snippet provided from https://github.com/MinishLab/semble#bash-integration]"
And the equivalent for the non-Semble test:
"Answer this question by only using the `rg` and `fd` CLIs:
> What tools does Browsercode provide to the agent other than the base OpenCode tools? Provide the exact schema for tool input and tool output and briefly summarize what they do and how they work"
In both cases, I used Pi with gpt-5.4 medium and a very minimal setup otherwise. (And yes, I did verify that either instance only used rg & fd, or only used semble.)
Without Semble, it used 10.9% of the model context and used $0.144 of API credits (or, at least, that's what Pi reported - I used this with a Codex sub so cannot be sure). With Semble, it used 9.8% of the model context and $0.172 of API credits. The resulting responses were also about the same. Very close!
I tried one more test in the OpenCode repo. The question was > Trace the path from 1) the OPENCODE_EXPERIMENTAL_EXA env var being set to to 1 to 2) the resulting effects in the system prompt or tool provided to the OpenCode agent.
And I included the same instructions/docs as above. The non-Semble version was a bit more detailed -- it went into whether the tool call path invoked Exa based on whether Exa or Parallel was enabled for the web search provider -- but w.r.t. actually answering the question, both versions were accurate. The Semble version used 14.7% context / $0.282 API cost, while the non-Semble version used 19.0% / $0.352. Clearly a win for Semble for context efficiency, but note that the non-Semble version finished about twice as fast as the Semble version.
Of course this is just me messing around. ymmv.
Wow awesome, thanks for sharing! This is really useful and very much like the experiments we want to be doing in the near future
Related 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.
I know this tool was meant for AI, but I am more interested in using it myself when exploring new code bases or even my own, when I want to refactor something and want an overview of where to change stuff. LSPs do that, but this tool sounds like it can go one step further.
Nice, this sounds great. I want to mention a related issue here, which is that on small codebases, Claude spends a lot of time looking for stuff when it could have just dumped the whole codebase into the context in one go and used very little tokens.
I found a nice workaround which is that you can just dump the whole directory into context, as a startup hook. So then Claude skips the "fumble around blindly in the dark" portion of every task. (I've also seen a great project that worked on bigger repos where it'll give the model an outline with stubs, though I forget what it was called.)
Maybe aider? https://aider.chat/2023/10/22/repomap.html
I actually made a custom harness based on Aider's edit format (the find/replace thing). (I think most AI stuff ended up using a very similar format.)
It just does what I need and no more: load code into context, append my question or instruction, call LLM, apply patches. Repeat.
I haven't used Aider itself though, maybe it does that too.
My harness was nice relative to Claude Code and Codex because, it doesn't need to poke around the filesystem (cause I have small repos and dump the whole thing), and it makes all edits simultaneously (doesn't need to edit one file at a time).
It reads all files and edits all necessary files in a single round trip.
The really nice thing is that when you're making many small fine grained changes like that, you can use a much smaller, faster, cheaper model.
And if it's fast enough, it actually becomes a real-time activity. It's not "prompt, wait..." but "prompt, immediately get the result." It's interactive. You stay active and engaged. It's great.
Good old aider ahead of its time
This is true, agents just don't know a lot about the things they're looking at, e.g., the number of files, file sizes, etc.
Although for small codebases it also holds that whatever you would like to find it easy to find, so search still might help you with cost
Semantic code search seems like a useful tool for a human too. Not just for agents.
Yeah I agree. I have used semble to quickly index a large monorepo and just ask a question about it, it surfaced the right files pretty quickly. Although without an IDE, it's difficult to display them in nice way
LSPs are already miles better than grep-like tools. This was true for humans as much as it is for LLMs. It's a shame that Claude still treats it as a second-class citizen (both in the app itself and in the training). A simple "remember to use LSP instead of grep" is usually enough to get it on the right track.
Better than grep obviously, but how does this compare to existing LSPs?
Or tools like `ck`: https://beaconbay.github.io/ck/
Try running both on the CK codebase. CK takes like 15 minutes to index itself and gives hundreds of completely irrelevant doc comments as results for “run model on CPU” query. Semble indexes for like 3 seconds and prints out the actual code that runs the model on the CPU.
You didn’t use `ck` directly, you instructed Claude Code to use `ck`, right?
No? CK is better than I gave it credit for, didn’t take 15 minutes, took 2, somehow a lot faster than before, probably system busy. I was using hybrid which is wrong for this query.
Still semble is a few orders of magnitude faster and gave better results against ck —-sem. I am running both on rust-lang/rust and CK is going to take hours at least, extrapolating from current stats probably 3 days? Semble: 26 seconds without any caching. The thing doesn’t have a cache and it’s still massively faster. I added caching support and watchman integration and got it down to 1.4 seconds. 3 days is basically not good enough for this use case. It’s slow enough that indexing is going to lag your code changes. Semble is fast enough that it’s not going to be behind.
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 libc).
Related: https://github.com/jahala/tilth Edit: recent HN discussion: https://news.ycombinator.com/item?id=46952321
So about a year ago I wrote my own attempt at something like this using vector indexing and BM25 (the latest version uses CocoIndex, I had a custom coded solution using ChromaDB before). I wrote a comprehensive enough test set that showed performance increases on the quality of search results and reduction in token usage versus grep and rg. I haven't had time to really polish it but it worked well enough, particularly for one project where I have around 250k documentation files and docs out number code files 1000 to 1 (about 50% reduction in tokens and 30% increase in successful searches). Yesterday for grins I tried this project and was fairly disappointed to see it blow away my kludged solution particularly given that it doesn't have a lengthy indexing process. I haven't tested it on the 250k doc project yet, but in another project that I have a test suite for semantic search on it outperformed my solution by about 20% even on documentation in terms of successful search results (which I didn't expect given that it seems to only be tuned for code). I haven't gone through the code to see what its doing differently than what I tried, but what ever its doing it seems to have potential.
Wow, thanks for sharing, and cool that you're working on similar things! Feel free to drop any feedback on the repo if you want!
I also like the index feature form https://maki.sh Source code has a lot of structure, using a real parser instead of grepping and reading files can potentially save a lot of tokens
Interesting, will have a look at this, thanks for sharing.
How does this compare with colgrep?
https://github.com/lightonai/next-plaid/tree/main/colgrep
The comparison is in the benchmarks, see the README
Shouldn’t it be a part of the harness at least for local codebase? I wonder how many harnesses are doing that already.
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
allegedly this one is good for PI https://pi.dev/packages/@ff-labs/pi-fff
Afaik many harnesses ship the "default" which is grep+read (like Claude Code). But I agree, IMO it's a weird gap. To be fair I don't think providers are that incentivised to reduce token burn at the moment, but my guess is that that will change and tools like this will become at least an natively supported option in some harnesses.
I would be surprised if, in the "mature" future of AI tools/products, the labs building the models are also selling/building to end users like they are now.
Would or wouldn't be? I think it makes sense that they will be because of the feedback loop on training. The lab generates tons of example text as part of the training run and if they have that using their own tools then the models will tend to prefer those tools.
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.
The bigger problem with solutions like these is that most AI already know how to use grep and search really well because of their training. Any such new tool that you handle to the AI, takes away from the cognitive capability of the AI. Humans would normally 'learn' how to operate tools like this - but the learning in LLM's is frozen and they already with a very strong depth in existing tools like grep.
For example, an AI would already use linux commands like tree to traverse the code base. And again it already has good training in this.
The other problem is that it is easy to cook up examples which demonstrate the efficacy of tools like these - but actually proving that the cognitive deficit that such tools result it, is surmounted by their efficacy in long horizon runs. My first contact instinct is that this will result in a net negative 'deployable intelligence' over long horizon runs - make the agent perform worse than using existing tools.
Proving the opposite is a non-trivial problem - but maybe it might be something you want to take up.
Metric that measures the quality beyond simple tokens count: correction loop frequency.
When grep does not find a file of interest, the agent does not fail; it will continue working on an incomplete context. For a monolingual code base, the miss rate is okay. In case of polylingual code (Python backend code and TypeScript frontend code), the problems emerge when it comes to querying for cross-file dependencies. Grep will return a route from the backend API. However, there is an interface in TypeScript that needs to be matched. Agent generates a response that does not fit the type. Correction cycle is one; two if the type conflict is ambiguous.
Combining grep with the understanding of semantic relations between files is a solution. Number of tokens saved is real but underestimates the actual benefit since fewer correction cycles are more valuable than tokens themselves.
Cool project. I built a custome IDE and coding agent harness and will integrate this into it. If you’re interested in a collaboration, I’d be happy to share revenue to sponsor your open source repo.
https://calendly.com/ryanwmartin/open-office-hours
Interesting for sure, but I think I need to be convinced this is necessary. How many tokens does Grep use on the average response anyways? Does this reduce input token usage from 100k to 2k per query or from 1k to 20? How does this effect output code quality?
There's a "semble savings" command you can run to see token savings. It varies heavily based on the repo: in general, the larger the project the larger the savings. Output code quality is something we're still trying to measure, but it's much harder than measuring retrieval quality.
Gotcha. Might be interesting to show some plots of average/median/max input token savings per query as a function of repo size if you're going to do some more comparison testing. The efficiency gains are compelling, but I'd want to see the magnitude of gains as well to get a full picture. Regardless, cool project and I'll check it out for myself
> uses 98% fewer tokens than grep
So are we supposed to believe that grep is so wasteful that models are reading 98% useless garbage every time they call it? Either this claim is not representative, or you're missing something else when you throw away the vast majority of context for the model.
The 98% is vs the grep+read loop, not grep output alone. When an agent hits an unfamiliar codebase it typically does "cat file" or reads the whole thing first, at least in my experience. If you're reliably getting agents to do "grep -C N" and stop there I'd genuinely be curious what your setup looks like, because I think the quality of the results is just too low to serve as useful context.
> When an agent hits an unfamiliar codebase it typically does "cat file" or reads the whole thing first, at least in my experience.
Depends on the size of the project and specific files. I have definitely seen agents make smart use of pi's "read" tool, which can take an offset and line limit (or defaults to a max 2000 lines/50KiB if the model doesn't specify). The bash tool also has the same max output, so if a model decides to cat instead of using the read tool it still wont blow out its context window with a single large file read.
But this sort of thing is going to vary with harness, model, project, and whatever the RNG delivers for the day.
I had problems with Claude reading hundreds of kilobytes of outputs because grep found things in node_modules. (ripgrep helps, so it makes sense to add a line about it into some memory file.)
Grep prints out every matching line. For some searches a LLM might do it will get a lot of noise, and it might have to make that search because it cannot be specific. Targeted search can reduce the number of tokens.
I suspect this comparison is against reading the whole codebase though compared to just getting the bits you need.
Feedback:
codex-cli hangs when calling this through the MCP. The semble process even sticks around as a zombie, forever stalled out. No idea why, logs have nothing.
When called through a skill via CLI style calling, GPT 5.5 loves to give a ton of search terms like it is used to doing with ripgrep. Not sure how effective this is, the short docs in the github and the instructions the agent has isn't clear on what is optimal.
Lastly, I got some errors with external connections to github when I was installing it for bash use. Maybe its related to the hanging? No idea.
edit: My agent also loves to follow-on with ripgrep, which seems redundant. Acts like it has trust issues. I think a more extensive agent skill description could guide the agent into proper use.
Hey, thanks for the detailed feedback. For the bug, would you mind opening an issue with your setup details? This is definitely something we want to investigate and fix. The multiple queries thing is really good feedback, thanks for that, we'll update the prompt/instructions to prevent this from happening and we'll try to add some tests for this. The external connection errors during install are uv fetching deps from PyPI I think, those should not be the reason it's hanging.
Would this replace something like codebase-memory-mcp[1] or improve when both is being used?
[1] - https://github.com/DeusData/codebase-memory-mcp
Is the benchmark measuring one-shot retrieval accuracy, or Coding agent response accuracy?
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.
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?
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
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.
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.
Does this work well for non-coding documents as well? Say api docs or AI memory files?
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.
How does it compare to context-mode or serina that are both well established now?
Serena does a lot more than semble (I actually used serena before building this and didn't like how much it does by default). That also made it hard to see if it was actually working well with how many moving parts there are. Semble only does 1 thing: very quick code search, that's it. Context-mode I have not used before though, I will have a look at that, thanks for sharing!
This looks great! I built a tool in the same space- and I found that the biggest challenge was often to get the agent to prefer to use the tool over bash tools. What’s your experience with that?
This is mostly done with the prompt. To be fair, we are still evaluating and improving this as well!
Setup hooks. Hooks are how your harness forces compliance with your own rules.
fantastic token savings and performance... but unlike grep it's probabilistic search on search terms.
is that an issue? the tiny model might not surface something important
It's not probabilistic, and exact matches will always be preferred over non-exact. So if you search for a function name this will surface it.
The instructions on how to install and use it could use some work. I did eventually install it. Will try it later and report back.
Oh sorry that happened. Feel free to open an issue or report it here
"The problem is that there are several bottlenecks internally," which include the requirements, specs, and testing. Another one not mentioned in the article.
Before you had faster implementation times, something would take six weeks to implement. Feedback from the client about how far off target you were came through in the same amount of time: a help desk ticket, a post-call check-in, a quarter end review. The price you paid for being off target was proportional to how long it took to figure out.
Now, when you can ship features in an afternoon, the customer feedback loop remains the same speed. Surveys, help desk tickets, and churn analysis come back days, even weeks later, by which point you've shipped five new features going the same way.
You can fix the internal bottlenecks easily enough: write better specs, have faster test cycles, deploy continuously. The customer feedback loop bottleneck is built into the system. It won't get any faster just because implementation did.
Today most organizations are busy fixing the internal bottleneck, but not the external one.
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?
“> Claude: Semble surfaced things grep missed — here are the additions to the earlier answer.”
Nice!
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.
Have you considered solving a different problem? What are agents trying to achieve when searching a code base? Finding seams. How about indexing seams instead?
What do you mean by this exactly?
How does that compare to Cursors’s workspace indexing?
Also curious what the authors think about Claude team explicitly trying out indexing and deciding against it.
The first is hard to test for us unfortunately since we don't use Cursor. But the Claude thing is interesting. I think that providers (especially the ones that directly sell LLM calls like Anthropic) are not incentivised per se to think about token efficiency vs performance, so if you're chasing pure performance, just loading the full codebase into memory might still be the "benchmark topping" way to go. I think the dust hasn't really settled yet and we'll likely see a lot of changes in the coming year about what's the "correct" way to solve it. It might be different based on your harness/budget/model as well.
Do inefficient grep/sed behaviors have a secondary benefit in seeding the context with breadcrumbs of code from irrelevant matches?
In theory maybe, but in practice it hurts more than it helps I think. Irrelevant context makes the model more likely to reason from the wrong code (and it's slower and more expensive).
Congratulations on the release!
Could you add fff to the benchmarks?
We hadn't found that one yet. Will do!
Exciting. I've been playing with AI dev pipelines and the "give the agent the full codebase vs. let it search" trade-off is what I keep running into - both have pros and cons depending on the task. This looks like the latter pushed harder than I've seen before. Looking forward to trying it
Does this support any language or is it limited to a specific set of languages?
For chunking Semble supports all languages supported by tree-sitter-language-pack. The models we train are trained on 6 languages, but can handle way more.
These almost always come with the cost of worse adherence
Fair, many tools trade off cost for performance/adherence. So far our experience is good with Semble (at least with Anthropic/OpenAI models), but if you have any feedback feel free to reach out. We're working on evaluations for this as well, though it will take some time as this is much harder than benchmarking retrieval quality.
Interesting approach, gonna leave a gh star clap
grep doesn't need tokens, so what is 98% fewer than zero?
We might not be AI/agent enough for this product. I wondered about that as well, but it's not actually a grep problem, it's an ingest problem for agents. Apparently some agents use grep to navigate code and it's this "operation" that consume tokens, grep does in fact consume zero tokens.
You need readfile to do something with those tokens. Grep only gives you the matching lines, not the context.
`grep -C $NUM` ? ;)
Even so. Take a look at the NDCG numbers for grep. It's not pretty
ripgrep exists though
The comparison is with ripgrep, see the benchmarks.
I feel this should be a mode on ripgrep. a disk search-lib in python? really?
Burntsushi (author of ripgrep), please chime in!
Hey, what's the issue with a disk search-lib in python specifically? The library is extremely fast. Yes, we could probably squeeze some more performance in Rust, but that's not our native programming language, so we opted for doing it correctly rather than use a language that we don't understand well enough.
thanks for sharing!
amazing jobs
Nice!
Very useful thanks for sharing!
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?
Perhaps Python is their main language (they seem to be ML peeps, which would make that most likely), which means it's easier for them to do manual reviews even if they're using AI for implementing, etc.
Yes, this is the main reason. We've released some rust stuff in the past, but Python is our main language