Memory system - Please Leave here your opinions (if you have any)

[code-yeongyu]

I heard many people wants that memory system- but it's really easy to be redundant from my experiences.

Projects like claude-mem or many others have memory system.

Want to hear your opinions regarding this (implementation, usefulness) if you have any.

Please share here actual great experiences that you had with what project / or the implementation that you think it is good.

[RodrigoLuglio]

Let me tell you my personal story. I built a memory system some time ago, it is a fastAPI python project. It has only a simple few endpoints that can be easily integrated to Claude Code using the hooks feature, I even created an issue some few hours ago to ask you about the available hooks and the possibility to extend to support a few more. If not using hooks, it is also not that complicated to integrate by making some modifications in any cli source code. But that isn't what I came here to talk, but about the memory system itself, how it works and why I like to use it.

The memory system works like this:

• At the end of each session or right before compressing the context, an instance of the currently used cli is launched with a resume session flag and the session id (Almost all current clis have the resume feature...the correct command to launch it can be easily configured in a config file) and a custom system prompt. The agent extracts the session summary and the relevant memories following the interactions in its system prompt. The summary and memories are stored in a sqlite db and a chroma db, both locally in the user's computer.
• Then, when a new session begins in that same project/folder, a very brief last session summary is automatically injected in the start session hook. Then as the user sends each message, the user message is intercepted but the user submit hook, the memory system is queried with the content of the current user message and any relevant memory to the current particular message is automatically injected to the user message. No need for any human or ai intervention or any kind of tool use.

Which and how memories are saved at the end of each session can be easily configured using natural language just by tweaking the custom system prompt that is set to the 'memory curator'.
The memory retrieval operation takes only ~50-200ms, very small imperceptive overhead. This is possible because of the rich set of metadata that the memory curator adds to each memory extracted, the retrieval algorithm uses all the metadata to select the really relevant memories in the context of only the current user message or none if no relevant memories are found. Quality over quantity principle.
The memories are organized by project, and are automatically separated using the projects folder name/path.

In case you want to take a look at the project source code or may even give it a try the repo is: https://github.com/RLabs-Inc/memory

For me, in my humble opinion, it makes a big difference, I'm loving to work using it in my projects. But of course, there are millions of different s workflows, opinions and tastes when come to how to interact with your coding agent.

I just wanted to leave here my 2 cents, as you started this thread a few hours after I asked you about the missing hooks when comparing to Claude Code's.

Thanks a lot for the space and for caring about your users wills and opinions. Keep up the great work you are doing here.

[willis7]

For what it's worth, here's an experiment (pre-pre-alpha) I have been toying with:

https://github.com/willis7/opencode-memento

I wanted to better understand AgentDB, and opencode was a decent vehicle.

It's not published as I'm still also figuring out the OpenCode side of things, but might be helpful in your thinking process.

It doesn't seem to be naturally using it, I have to nudge it, but thats probably an implementation detail rather than the usefulness of AgentDB.

[Razkaroth]

I think that the current agents.md injection system could be leveraged in this way, I made opencode create an agents file for each folder, find references and use keywords that help when other agents run grep. Then, added the instruction to cascade update agents.md files on paths with edits which are found using git when finishing a task and before compaction. It has worked great.

Since /init only generates the top level agents file, i think a /turbo-init command that makes this process automatic would be a nice adition.

[code-yeongyu]

I think that the current agents.md injection system could be leveraged in this way, I made opencode create an agents file for each folder, find references and use keywords that help when other agents run grep. Then, added the instruction to cascade update agents.md files on paths with edits which are found using git when finishing a task and before compaction. It has worked great.

Since /init only generates the top level agents file, i think a /turbo-init command that makes this process automatic would be a nice adition.

@Razkaroth Great take. I personally have this workflow but currently experimenting and comparing with other memory systems.

[adam2am]

Saw a lightweight option (SQLite + hybrid (vector+fts search) 2 days ago – https://github.com/mark-hingston/opencode-elf , inspired by the concept from https://github.com/Spacehunterz/Emergent-Learning-Framework_ELF (for Claude Code). It's really fresh and not tested though

[RodrigoLuglio]

Just to let you all know, I ported the memory system form python to typescript, and I took a time to design a new kind of database, it is super super fast with competitive performance with the 'giants' on the 10-20 K entries scale even for vector search. All the records like session summaries, project snapshots and the memories themselves are stored on markdown files with yaml front matter. The memories now are totally human readable, can be edited using any common text editor and the embeddings are automatically updated when this occurs. The performance got a nice upgrade overall. The installation process is easier too, just install the memory package globally using bun and run bun install to integrate with Claude Code via hooks, if there is interest and in case all the required hooks are exposed we can also include in the cli to install to oh my open code too with a simple command.

In case you want to check it out the typescript version of the memory system that uses the new fsDB with markdown files persistence just take a look at the instructions in the repo. It is really simple, including the package installation it is just 3 commands.

memory-ts

[LegendEvent]

why not using supermemory plugin? https://github.com/supermemoryai/opencode-supermemory

we could also include acontext for SOP's so the AI is learning from errors and user input: https://github.com/memodb-io/Acontext

[Straffern]

Something like https://github.com/joelhooks/swarm-tools/tree/main/packages/opencode-swarm-plugin#evaluation-pipeline
and https://github.com/joelhooks/swarm-tools/tree/main/packages/opencode-swarm-plugin#semantic-memory-persistent-learning might be neat.
Good thing is that it is fully local.

[agiulucom42-del]

What works well in practice is treating memory as a decision and constraint ledger, not a conversation log.Good Luck bro

[TomLucidor]

Something tangential, or maybe related... BMAD and other swarm-like systems probably need memory too. BMAD is not Claude Code exclusive nowadays, so I kinda want to see how OpenCode might adapt it. https://github.com/bmad-code-org/BMAD-METHOD

[saxenauts]

I keep my own system in untracked docs that I keep reminding it, I wish there was a better way. But there are:

1. my verbatim notes read only
2. architecture design
3. progress tracker and log,
4. decision log.

I find these 4 important, especially progress tracker and decision logs.

I would like for it to be my default system somehow, and like this have a system so that sisyphus can align with this by itself. I would assume everyone has their own system, so its easy to just use files and a reminder.

[rnwolfe]

a potential thing to look into is https://github.com/steveyegge/beads

I like this because it is tracked and just don't via cli tooling. I've lazily tried to use it with OMO, but they don't seem to get along nicely without some tweaks I have yet to attempt.

But I've had good experience with it personally before use of OMO.

Perhaps some insights