Repository navigation
[FEATURE]: Long-term persistence memory system (/teach, /recall, /learn, /memory) #48497
Closed as duplicate
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Feature hasn't been suggested before
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Add a persistent long-term memory engine backed by SQLite (memory.db) to allow OpenCode to retain user conventions, architectural guidelines, and learned lessons across sessions.
Proposed Capabilities:
/teach <context>: Persist user instructions, architectural preferences, and rules./recall <query>: Retrieve relevant memories via SQLite FTS5 full-text search./learn [content]: Automatically extract or manually save lessons and insights discovered during coding sessions./memory [query]: Explore, search, filter, and inspect saved memories via CLI and TUI dialog.
Benefits:
- Eliminates repeating context, repository guidelines, and coding preferences across new sessions.
- Fast, local, zero-dependency persistence using SQLite WAL mode and FTS5 indexing.
- Accessible conversationally by the agent (tool call), via CLI commands (
opencode memory ...), and via TUI slash commands and dialogs.
Activity
github-actions commentedon Sep 11, 2026
This issue might be a duplicate of existing issues. Please check:
Consider joining the discussion there or clarifying how this proposal differs.
izgorodin commentedon Sep 12, 2026
Looking at #48498 (
204fe56),sourceis stored asteach/learnbut omitted from the rendered recall output; exposing it would at least preserve that provenance. I'd keep "explicit user decision" separate from "inferred lesson" too, since an agent can call either action and the action name alone doesn't establish authority. A useful same-project restart test is: the user explicitly chooses pnpm, a later lesson extracted from an old log says npm, and recall retains the evidence without silently promoting that lesson over the user's rule.Disclosure: I work on Mnemoverse; this comment was drafted with AI assistance.
prethiv commentedon Sep 12, 2026
@izgorodin - I agree that your point makes sense. But think this way that you can always override memory with explicit teachings at any point of time. And while recalling suppose both the chunks retrieved from memory the llm itself would decide which one is valid or /teach with proper information appended at the end of the chunk stating this is proven way.
Using these above as inferences we can override or explicitly let llm knows the right way by putting more context.
prethiv commentedon Sep 12, 2026
I also did a consultation with AI as well:
Here's the recommendation
"Good call on preserving provenance. Exposing the source ([User Rule] vs. [Inferred Lesson]) and timestamp in the rendered /recall block is an easy win with virtually no token overhead. That gives the system prompt a deterministic anchor to instruct the model to prioritize explicit user rules over inferred observations when conflicting chunks are retrieved, while still keeping the SQLite FTS retrieval engine simple and lightweight."
vshulcz commentedon Sep 23, 2026
on keeping an explicit user decision separate from a lesson inferred from an old log: one way is not to infer. deja hands back the session, the date and the line, never a distilled fact — so "the user chose pnpm" and "a note from an old log says npm" come back as two hits with their provenance rather than one merged claim, with the newer one ranked first. your restart test is the right shape; it's precisely the case where a synthesiser silently promotes the lesson over the rule. disclosure: i maintain deja-vu, which works this way because summarising other people's decisions is the part i didn't want to be wrong about.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed proposal, @prethiv! I think this is a duplicate of #20322, which asks for the same thing: native SQLite-backed memory that keeps conventions and lessons across sessions. Your
/teach,/recall,/learnand/memorycommands are a way of using that memory, but the request underneath is the same.Possible duplicates and related issues, ordered by likelihood:
In the meantime, something like this could be built as an OpenCode plugin (a custom memory tool plus commands), so you can use it without changes to core.
The bot will close this issue as a duplicate in 1 day unless you reply explaining how your request differs.
opencodejr commentedon Oct 29, 2026
Closing this as a duplicate of #20322, which asks for the same thing: native persistent memory that keeps conventions and lessons across sessions. No one has replied in the day since it was flagged. The related issues listed above (#8043, #9211, #16077, #43068) are worth a look too. Thanks again for the detailed proposal, @prethiv! If your request is different in a way we missed, reply here and we'll take another look.