Rendered at 08:30:43 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
striking 4 hours ago [-]
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.
4 hours ago [-]
pcthrowaway 2 hours ago [-]
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.
swiftcoder 27 minutes ago [-]
I have seen this on at least half a dozen vibe-coded tool sites in the last few weeks
hanumseous 31 minutes ago [-]
How fast is yours searching for files? Is it support fuzzy search?
sheo 7 hours ago [-]
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
TowerTall 2 hours ago [-]
> Cursor had something like this at some point. They've removed it.
No, they say that they have removed it, but they haven't. Cursor claims they retired local indexing in favor of something they call "instant grep," which, according to their own support, doesn't use a local index, and they removed the tool in Cursor settings to rebuild the index.
But Cursor still uses a local index. They have just hidden it as a subfolder in your ".git" folder. "~/.git/cursor".
Their hidden index often goes stale, and I had to nuke that folder every time I changed many files. This isn't new; when they officially had a local index, it was often stale too. I developed a script that ran on a daily schedule, every few hours, to alert me when Cursor's index went stale.
I constantly had to watch for Cursor suddenly not finding documents that clearly existed, and it often worked on outdated content. Disabling instant grep removes the hidden index, btw and problem gone.
boyter 3 hours ago [-]
Hah yes. Ill throw my own into the ring too https://github.com/boyter/cs although its a lot older than most other tools having been started 7 years ago.
Cursor was an interesting case where they were maintaining an index. I think everyone has converged on not doing that, which is where I started, with BM25 with some tweaks on top.
Notable link related to this https://www.youtube.com/watch?v=ZnmtJKFonLk where Jo Kristian Bergum (notable in the search space) agrees with BM25 being a good approach for agentic workflows.
ProblemExplorer 4 hours ago [-]
> Cursor had something like this at some point. They've removed it
Any insight into why would be much appreciated because those insights might hold the key to whether this is a usable, sustainable idea to begin with.
victorbjorklund 3 hours ago [-]
I think a lot of people claim it is because in practice letting the AI just use grep yielded better results.
Enhanciar 4 hours ago [-]
[flagged]
febed 4 hours ago [-]
Does this download an embedding model? If so which one? There is barely any information on how it works.
6 minutes ago [-]
TedHaley 8 hours ago [-]
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!
ProblemExplorer 4 hours ago [-]
> 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
What are the various ways Pensieve is superior to iterative grep? Is it just better "semantic" search instead of literal "grep"?
Cache invalidation is hard - how does Pensieve address it?
Your site says "Pensieve watches your folders, repos and agent sessions and re-indexes what changed. Uncommitted edits count, and every worktree is tracked by branch, so your agents never work from stale context." but you don't define what "stale context" is - if I'm exploring 3 different implmentations of the same concept across 3 different branches, which one is the "stale context"?
Could you take a few minutes to explain the what and the how? Links to writeup to blog posts or files in your repo would be very helpful.
Finally, can I use Pensieve with Paseo? What if I wanted to expose Pensieve's capability to my Paseo setup?
Tallain 5 hours ago [-]
I also built something similar to solve this, but more aimed at inspecting the impact of changes to a concept - think a vertical slice or domain, or even a feature. Often the same thing might be referred to by similar, but slightly different names, or separate pieces of the codebase might not immediately look related when they do share dependencies. So symbols, phrases, and words are attached to concepts for either LLM-based or user-based querying via MCP.
An indexer crawls the codebase and maps slices of code to concepts, then groups related concepts. You can inspect a concept to see things related to it, or ask about the impact of a change and see second-order changes required - things not so easy to see that are related by basic symbol linking (although it does use symbol linking - it heavily relies on Roslyn, since it's all C# focused).
It also returns confidence scores with everything, which adjust based on a dozen or so factors like whether the user defined the concept or the concept was auto-generated during the code crawl. Low confidence score === fall back to grep.
It was a super fun project and ended up being very useful, as much for people as the LLM. But, I'm not convinced it is materially better than grep in some ways and just haven't had the time to really focus on improving it.
eecc 19 minutes ago [-]
interesting, I've been working on something similar myself... do you want to have a chat about it?
dzink 4 hours ago [-]
This is 100% AI generated.
2 hours ago [-]
fenomas 7 hours ago [-]
(vouched - your comment was dead fyi)
Retr0id 5 hours ago [-]
I believe HN now has some built-in detection for AI generated comments, which is probably why it was dead (pangram rates it as 100% AI generated, btw).
If not for the rest of the page I would have assumed this was a joke.
Referencing other sessions is a cool idea tho
No, they say that they have removed it, but they haven't. Cursor claims they retired local indexing in favor of something they call "instant grep," which, according to their own support, doesn't use a local index, and they removed the tool in Cursor settings to rebuild the index.
But Cursor still uses a local index. They have just hidden it as a subfolder in your ".git" folder. "~/.git/cursor".
Their hidden index often goes stale, and I had to nuke that folder every time I changed many files. This isn't new; when they officially had a local index, it was often stale too. I developed a script that ran on a daily schedule, every few hours, to alert me when Cursor's index went stale.
I constantly had to watch for Cursor suddenly not finding documents that clearly existed, and it often worked on outdated content. Disabling instant grep removes the hidden index, btw and problem gone.
Cursor was an interesting case where they were maintaining an index. I think everyone has converged on not doing that, which is where I started, with BM25 with some tweaks on top.
Notable link related to this https://www.youtube.com/watch?v=ZnmtJKFonLk where Jo Kristian Bergum (notable in the search space) agrees with BM25 being a good approach for agentic workflows.
Any insight into why would be much appreciated because those insights might hold the key to whether this is a usable, sustainable idea to begin with.
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!
What are the various ways Pensieve is superior to iterative grep? Is it just better "semantic" search instead of literal "grep"?
Cache invalidation is hard - how does Pensieve address it?
Your site says "Pensieve watches your folders, repos and agent sessions and re-indexes what changed. Uncommitted edits count, and every worktree is tracked by branch, so your agents never work from stale context." but you don't define what "stale context" is - if I'm exploring 3 different implmentations of the same concept across 3 different branches, which one is the "stale context"?
Could you take a few minutes to explain the what and the how? Links to writeup to blog posts or files in your repo would be very helpful.
Finally, can I use Pensieve with Paseo? What if I wanted to expose Pensieve's capability to my Paseo setup?
An indexer crawls the codebase and maps slices of code to concepts, then groups related concepts. You can inspect a concept to see things related to it, or ask about the impact of a change and see second-order changes required - things not so easy to see that are related by basic symbol linking (although it does use symbol linking - it heavily relies on Roslyn, since it's all C# focused).
It also returns confidence scores with everything, which adjust based on a dozen or so factors like whether the user defined the concept or the concept was auto-generated during the code crawl. Low confidence score === fall back to grep.
It was a super fun project and ended up being very useful, as much for people as the LLM. But, I'm not convinced it is materially better than grep in some ways and just haven't had the time to really focus on improving it.