alt Hacker NewsLocal Indexing to reduce tool calling and token usage
Comments
OK, so, I too have built a local index tool called slopdex [1].
It's very simple, parses the repo code and docs with treesitter, indexes it, vectorizes everything, then allows you do things like create a map of the codebase or do a semantic search.
One cool trick that does work well is the cross-search command, which allows you to do a duplicate code search using the vector index. This gets rid of a blind spot that lots of LLMs have that make it create lots of dupliclate helper functions. This works quite well in practice.
It has a few evals that I'm still working on, showing only modest improvements in token usage when using the map command, maybe around ~10% less. I think this can depend a lot on the type of task though.
Would be happy to hear any feedback.
https://github.com/huggingface/funes/ has been my go-to here (specifically for conversation search), but I do appreciate that there's a frontend on this one that can recall a session and open the correct agent for it (rather than my opening one agent, then opening another when I've gotten it wrong). Looks nice. Well done.
Is "instructing users to ask their agent to curl a script and pipe to bash" the new "instructing users to curl a script and pipe to bash"?
If not for the rest of the page I would have assumed this was a joke.
I saw like 20 tools of this kind and there is a new one coming every month. Cursor had something like this at some point. They've removed it
Referencing other sessions is a cool idea tho
At some point if these types of front pages that are promoting a tool like this will be optimized for the agent itself to make the decision to install and use it. The human just says "please optimize for cost" and then the agent finds this thing and starts using it without the human even knowing or caring.
LLM generated websites are so instantly recognisable
Vibe coded tools are great. I have loads of them to work for my workflows. AI makes it almost free to make your own tools. Almost none of them are worth sharing or distributing
How fast is yours searching for files? Is it support fuzzy search?
Does this download an embedding model? If so which one? There is barely any information on how it works.
In general, in my experience, grep is better than almost anything else you can use. It's very very fast and efficient, very flexible, and does not require any indexing pass, is never out of date, and doesn't require you to guess ahead of time what files you might want to search or how to process search tokens.
"Search your files, repos and agent sessions, locally, and give your agents the best context for the job. One search points them to the few passages that matter, instead of grepping the whole disk."
Grep is already searching for relevant passages with a single tool call. This is clearly LLM written copy. It makes literally no sense.
This reminds me of the dating app advert I keep seeing on tiktok, which says that other dating sites "force you to be the loudest voice on your profile". There's no interpretation that makes sense, it's just the typical LLM gibberish.
Indexing local files makes search faster (in theory, but in practice maybe not for less than a few tens of GB of local files on fast SSD), but not more flexible or requiring less tool calls.
It also will always suffer from being a little behind the on disk state, which is terrible when you are trying to do something like find all the references to something under active development, or when changing branches. Consider you checkout a branch and call this tool, it will just lie to you, telling your LLM there are matches in files that no longer match, getting line numbers wrong, missing matches in other files. Every time you change branches it will go nuts trying to reindex everything. The best case scenario is still probably performance on par with grep but out of date and doing a ton of extra work to index files whether or not you ever need to search them.
Grep can take general regex, which more or less can't be indexed, so there's very few things that are more flexible or produce less tool calls than grep.
Grep is also absurdly fast, if you don't know how fast it is it's faster than you think. Here I use ripgrep to search every piece of code I have checked out, around 11GB of data (more or less) in 0.2s (regular gnu grep takes 4s, mostly because it doesn't exclude .git/ folders and only uses one processor):
xyz@xx:~% du -sh checkout
11G checkout
xyz@xx:~% time rg robotic checkout|wc -l
19
rg robotic checkout 1.14s user 1.07s system 1151% cpu 0.192 total
wc -l 0.00s user 0.00s system 1% cpu 0.192 totalWhere have API costs or agent token use hurt you most?
So basically this is ripgrep.
But someone will come in crying saying “Nooo!! It does so much more like indexing and bla bla etc”
I don't know if you've noticed, but when Claude Code, Codex, or any other agent needs to find code, it runs grep. It searches your files for an exact string, reads a few results, and greps again until it finds what it wants. You pay tokens and wait for every round.
That worked fine when repos were small. But codebases are growing fast, partly because agents now write so much of the code. Every grep round costs more than it did last month, whether you notice it or not.
There's a second problem: grep only finds what you already know how to name. Ask it for "where we handle rate limits from the billing provider" and it gets 0% right on the first try, because it needs the exact string.
So I built Pensieve. It's a local index of your code, documents, and past agent sessions. Any agent can query it over MCP and get the few files that matter on the first try. A few cents saved per lookup doesn't sound like much. It adds up over hundreds of lookups a day.
Check out Pensieve!
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
tl,dr: Semantic search based on "Qwen3-Embedding-0.6B and stored in SQLite (with a trigram full-text index for exact matches) plus turbovec vector indexes".
I feel a lot of these tools are barking up the wrong tree. Solving problems that are just symptoms of a deeper root cause. Index because my codebase is too big to grep. Index to paraphrase hard_decline via card retries. Reduce tool calling to save my agent YOLO search loops. etc. etc.
It feels like trying to overcome bad codebase hygiene by throwing more tools at it, and wallpapering the mold over. I've found that codebases left entirely to LLMs suffer from this gravely, but with even a bit of effort - you'll get outsized returns. Don't let the agent smosh up everything into a giant ball of code. Separate concerns, build services, do the architecture step of the software design with a bit more care than vibe coding.
A bit of a rant, yeah, but I don't see why tools like this exist (and ask you to curl a script into bash, no less). You're doing stuff a bit wrong if grepping is the bottleneck.