Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open-source memory for coding agents, synced over SSH

github.com

Post reply on HN
Print view View original

31–40 of 43 posts

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

#31

Post by arjie »

noctuid wrote: post #28
arjie wrote: 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…

It's not easy, that's why they all suck.

What did you find wasn't working well? Perhaps I have insufficient content for it to start failing. Works quite well in Claude Code / Codex / Custom Harness with DSV4F.

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

#32

Post by killix »

vshulcz wrote: post #27
hparadiz wrote: post #19

I can't even get my agents to properly read the memories they have saved locally let alone remotely.

That's why I ended up creating two forced paths for this. 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 " "…

[flagged]

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

#33

Post by bityard »

esafak wrote: post #17
bityard wrote: 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.

If I want that information to be available to other people/agents who use the repo, they are not really polluting the repo? Am I doing vibecoding wrong?

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

#34

Post by latchattack »

imhoguy wrote: post #15
vshulcz wrote: 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?

I agree that similarity search can't surface reliable project judgment alone. How do you know what was true, what was rejected, and what's obsolete since changes in the project? I am actually building Open-Latch for this reason. It leverages project decisions, facts, lifecycle state, reconciliation, enforcing cited evidence and a judgement gate before coding agents act.

GitHub: https://github.com/open-latch/latch

I felt the same annoyance as OP mentioned, but focused on agents violating project judgement and direction. Obviously we are optimizing for some different things than deja: deja uses no-LLMs and exact verbatim transcript retrieval.

Latch uses LLMs, ranking, etc, to emphasize strong judgment, correction, and enforcement over dynamic project flow.

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

#35

Post by zby »

serf wrote: post #24
zby wrote: post #21

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...

I think 'enforcement' is wholly outside the ballpark of a memory system.

If I remember well, the starting point was that memory is only useful if it changes the system behaviour. There are many ideas of automatic 'tips' or 'rules' that are injected into the prompts so that the agent acts accordingly to some retained lesson. But there are many failure modes for this. But maybe I'll need to revise the phrasing on that page and in instructions.

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

#37

Post by vshulcz »

koolba wrote: post #13
vshulcz wrote: 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?

[dead]

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

#39

Post by cbcoutinho »

I have developed an open-source memory system for agents accessible over MCP, which makes it possible to access it via any coding agent locally (claude-code) or via mobile (Claude AI, Mistral AI, etc).

The primary storage mechanism is .md files stored as Notes in Nextcloud; however, since Nextcloud supports a rich ecosystem of apps such as documents, rss feeds, calendar, etc, your knowledge base can grow with you. All content can optionally be indexed and available via semantic search - powered by a Qdrant vectordb.

The biggest cost drivers of a system like this is the memory required to host the vectordb - I'm really curious how others are optimizing their knowledge base. Thanks OP for doing to work in summarizing these tools!

If you're interested either the MCP server or Nextcloud App frontend, please check out:

https://github.com/cbcoutinho/nextcloud-mcp-server

https://apps.nextcloud.com/apps/astrolabe

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

#40

Post by esafak »

bityard wrote: post #33
esafak wrote: post #17

Earlier quoted context omitted.

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.

If I want that information to be available to other people/agents who use the repo, they are not really polluting the repo? Am I doing vibecoding wrong?

There are ways to make it available without checking them in as usual. I don't want a folder with session files for every single commit, personally; I want them to be associated with the commit as metadata, so I use `git notes`.
Post reply on HN