"it works fine and this is not a bottleneck. For large projects, other parts are much slower": I don't think this is true, especially for large projects. I just ran your tool on the Kubernetes repo with 1536-dim embeddings. The isolated similar-pair search took ~130s and peaked at ~4.8 GB RSS, and the total runtime was ~250s with the same memory peak.
"In larger sets, all vectors are not loaded into memory at once": this is also not correct, at least in the implementation you shared. The similarity matrix is processed in blocks, but the embeddings themselves are loaded all at once and stacked into one NumPy matrix, hence the memory peak.
So in larger projects, more than half of the time is spent on the similarity search step, and almost all the memory is spent there as well.
I don't understand what you mean with your first sentence. Both SemHash and Slopo are deduplication libraries right? Regardless, finding similar code is the core functionality that enables (semantic) deduplication.
I also don't think the backend is the "easiest part" here, a lot of the scalability lives there, which is important for monorepos, or cases where you want to deduplicate across projects. For example, from looking at the implementation, you use exact brute-force similarity search (comparing every item to every other item) which is an O(n^2) operation. It also allocates large dense similarity blocks in memory, so memory use won’t scale well either.
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.
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.
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).
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.
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).
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.
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.
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.
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.
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?
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.
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.
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.
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!
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.
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!
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.