Live data from Hacker News

Open-source memory for coding agents, synced over SSH

github.com

11–20 of 43 posts

Re: Open-source memory for coding agents, synced over SSH

#11
Does memory for AI agents basically mean -

- Save everything to disk. Index it or store in vectorDB. - Search the storage for similarity based on the new prompt - include any finding with the new prompt as system/user prompt (or if you find the exact answer skip the llm call)

?

Or is there more to it ?

Re: Open-source memory for coding agents, synced over SSH

#12
post #11

Does memory for AI agents basically mean - - Save everything to disk. Index it or store in vectorDB. - Search the storage for similarity based on the new prompt - include any finding with the new prompt as system/user prompt (or if you find the exact answer skip the llm call) ? Or is there more to it ?

Different implementation details have different way to rank or “forget” or supersede facts but that’s pretty much it

Re: Open-source memory for coding agents, synced over SSH

#13
post #2

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?

Re: Open-source memory for coding agents, synced over SSH

#14
post #3

Similar to https://ctx.rs/ and others, I'm sure. I'd lead with your differentiation. Is it the ssh?

Maybe somebody can enlighten me... this page for ctx says the program saves all "decisions, constraints, intent, rejected approaches, bug investigations, refactors, file paths, commands, patches, and notes from previous agents."

What am I missing if I instead just instruct the agent to create a handful of files called something like HISTORY.md and tell it to log summarized versions of all of these things inside the project repo whenever something is changed or evaluated? (Which is very close to what I currently do.)

Re: Open-source memory for coding agents, synced over SSH

#15
post #2

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?

Re: Open-source memory for coding agents, synced over SSH

#16
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 modern models are pretty good at handling this. Our home agents (voice and text) use this to store information and I also have skills for claude code and codex to do that as well. Overall, works quite well.

I still use MEMORY.md for the home agents to keep short-term memory, and use the KB for long-term memory. You do need a self-reflection/consolidation/dream step in order to periodically consolidate and groom the KB but that's also just another job.

The whole setup is pretty trivial and what anyone would come up with from scratch and it's surprising that it works but it does. I'm a pretty good documenter so it helps. In some future perhaps a vision model could see all the things I'm doing and remember, but for now I just tell it and it's pretty good about everything I want.

0: https://wiki.roshangeorge.dev/w/Blog/2026-07-01/The_Everythi...

Re: Open-source memory for coding agents, synced over SSH

#17
post #14
post #3

Similar to https://ctx.rs/ and others, I'm sure. I'd lead with your differentiation. Is it the ssh?

Maybe somebody can enlighten me... this page for ctx says the program saves all "decisions, constraints, intent, rejected approaches, bug investigations, refactors, file paths, commands, patches, and notes from previous agents." What am I missing if I instead just instruct the agent to create a handful of files called something like HISTORY.md and tell it to log summarized versions of all of these things inside the p…

It deterministically pulls the full session log so you don't need to tell an LLM to do it, plus it doesn't pollute your repo with such files.

Re: Open-source memory for coding agents, synced over SSH

#18
post #17
post #14

Earlier quoted context omitted.

Maybe somebody can enlighten me... this page for ctx says the program saves all "decisions, constraints, intent, rejected approaches, bug investigations, refactors, file paths, commands, patches, and notes from previous agents." What am I missing if I instead just instruct the agent to create a handful of files called something like HISTORY.md and tell it to log summarized versions of all of these things inside the p…

It deterministically pulls the full session log so you don't need to tell an LLM to do it, plus it doesn't pollute your repo with such files.

> doesn't pollute your repo with such files.

An orphan branch solves that issue.

Re: Open-source memory for coding agents, synced over SSH

#20
post #16

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…

> I'm a pretty good documenter so it helps.

I wasn't but now, doing a lot of work inside a harness that is logging everything and can easily create docs from that, I'm finally persisting a lot of knowledge.

Post reply on HN