21–30 of 43 posts
There are comparisons and stuff: https://zby.github.io/commonplace/agent-memory-systems/
Deja-vu is here: https://zby.github.io/commonplace/agent-memory-systems/revie...
And the full list: https://zby.github.io/commonplace/agent-memory-systems/revie...
Hi HN. I built deja after watching Claude Code and Codex debug the same problems more than once. The annoying thing was that the answer usually already existed somewhere in my old sessions. My records were stored on the disk for months (~3.3 GB). It wasn't easy to find them manually and the new agent session had no idea what the other agent had already found out. deja indexes the transcripts that Claude Code, Codex,…
> My setup is a laptop and a mac mini without an interface. The agent can work on the mini all night, and in the morning I extract its memory. Then the agent on my laptop will know what the mini tried, what broke, and what eventually worked. If it’s fully automated and then blindly injected into your laptop without any vetting, isn’t that a perfect vector to break that separation?
However, when syncing, only data records are moved not instructions. Nothing is done and known secrets are deleted at the indexing stage even before they leave the source computer. In addition, the context here is your own computers and your terminal's output data, if an attacker can control your agent's transcripts, the source computer has already been completely compromised.
Nevertheless, you make a perfectly reasonable case for strict isolation. I just opened the issue to add an opt-out checkbox where imported sessions are only displayed when manually searched using the CLI/MCP, not when automatically implemented: https://github.com/vshulcz/deja-vu/issues/39
I did an automatic review of over 140 such systems. There are comparisons and stuff: https://zby.github.io/commonplace/agent-memory-systems/ Deja-vu is here: https://zby.github.io/commonplace/agent-memory-systems/revie... And the full list: https://zby.github.io/commonplace/agent-memory-systems/revie...
Hi HN. I built deja after watching Claude Code and Codex debug the same problems more than once. The annoying thing was that the answer usually already existed somewhere in my old sessions. My records were stored on the disk for months (~3.3 GB). It wasn't easy to find them manually and the new agent session had no idea what the other agent had already found out. deja indexes the transcripts that Claude Code, Codex,…
I just wonder how do you filter out signal from noise - does it self correct wrong memories?
I like that this stays local instead of depending on a hosted service. One thing I've noticed while building LLM applications is that memory becomes much more valuable when it's easy to inspect and edit manually. Are you planning to support semantic search later, or is the goal to keep everything deterministic and text-based?
Adding semantic search usually means sending hundreds of megabytes of embedded models and working with non-deterministic results which completely violates the promise of zero dependency within 7-9 ms. In fact, I encounter some uncertainty when expanding substrings (e.g. when requesting the code, the open source code will be displayed).
I won't completely abandon semantic search if there is a really easy and fast way to do it locally, but at the moment deterministic search is the priority. And I completely agree with your first comment, the verbatim approach provides just such a verification opportunity.
I can't even get my agents to properly read the memories they have saved locally let alone remotely.
First, the SessionStart hook aggressively introduces context immediately after loading, completely bypassing the agent's requirements.
Secondly, I'm forcibly changing the behavior by using a fragment of the system query in CLAUDE.md or AGENTS.md. I'm literally just copypaste this block from the README:
Before debugging or re-implementing anything, run deja "" (or the MCP revocation tool) — the agent's past sessions in Claude Code, Codex, and opencode will be indexed locally. Specify what you are reusing.I think everyone's ended up building one of these for themselves. I did too[0]. In the end it's quite easy these days: * I use the bge-en-base CPU embedding model * I put storage behind a simple endpoint that has read,write,update,search semantics * The endpoint just stores markdown in an S3 like structure (bucket-key-value; tree structure is inferred) and vector indexes * The actual persistence is just SQLite Most m…
Similar to https://ctx.rs/ and others, I'm sure. I'd lead with your differentiation. Is it the ssh?
Yes, ctx is the closest cousin here. I actually linked it in my top comment. This causes a very similar itch, but we went a slightly different route regarding some implementation details Secrets: The ctx README mentions saving the text as is and warns about the need to review the output data before publishing. deja explicitly removes known secret templates at the indexing stage (replacing them with tags like [redacte…
> Secrets: The ctx README mentions saving the text as is and warns about the need to review the output data before publishing. deja explicitly removes known secret templates at the indexing stage (replacing them with tags like [redacted:aws-key]).
How is this not security theater? You've presumably already sent the api key to an LLM if it's in your session file. You need to rotate it.
Go-to stack for this in my case is to start off with a MEMORY.md, and then keep a long-running agent session going to observe human-operated tmux sessions, surface/respond to occurrences where there's something significant learned (typically the human operator redirecting away from an agent/LLM decision), then start having it integrate into and read out of DuckDB. The latter becomes dense, easily searchable data for agent skills and commands and, yes, memory and such.