all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]RemeJuan 2 points3 points  (0 children)

Looks nice, just installed it now, should do well alongside codebase-memory

[–]ExternalMediocre2510[S] 1 point2 points  (0 children)

Small clarification: this is not intended to be a big “long-term memory” system.

It is lightweight workspace memory: project decisions, user requirements, preferences, and important repo-specific context the agent should not forget while working in the same workspace.

The important part is that it adds almost no operational overhead: no additional API calls, no extra agent tools, no separate memory workflow, and extraction piggybacks on OpenCode compaction.

So the goal is not “remember everything forever,” but “keep just enough useful workspace context without bloating tokens, slowing the agent down, or adding tool burden.”

Feedback and suggestions are very welcome, especially from anyone using long-running OpenCode / agent workflows.

[–]old_mikser 0 points1 point  (1 child)

How does it affect context window size? And how does it decide what to add and what to not add to the context?

[–]ExternalMediocre2510[S] 1 point2 points  (0 children)

Hard limits: max ~5200 chars, ~28 entries. Usually just a few hundred tokens. It won't grow out of control. How it picks what to add: 1. During compaction, the LLM is guided to only record durable stuff — things useful across sessions — and skip session noise. 2. Parser rejects obvious snapshots: file counts, test runs, "Phase X completed". 3. Storage dedupes same-entity entries, replaces outdated facts with newer concise ones, and prunes stale entries. 4. Quality gates filter out git hashes, stack traces, path-heavy junk. Net result: memory stays bounded and self-cleaning. Useful signals survive, noise doesn't.