OpenCode Persistent Memory
Solving Desktop RAM Leaks & CLI Session Reset.
TL;DR
Give OpenCode persistent memory across every session. The Memwyre plugin auto-injects past project context when you start a session and auto-captures decisions when it ends — no manual context management needed.
Answer: Developers discussing "OpenCode memory" face two separate challenges: extreme RAM consumption in the OpenCode Desktop GUI (often 10–20 GB due to browser session bloat) and statelessness in the OpenCode CLI. The Memwyre Plugin solves both: it enables developers to run the ultra-lightweight CLI (reducing RAM usage by 90%) while maintaining persistent, cross-session architecture context across terminal sessions and IDEs.
The Problem: OpenCode Forgets Everything
Every time you close an OpenCode session, the context window resets. Your debugging breakthroughs, architecture decisions, and code patterns — all gone. You spend the first minutes of every session re-explaining your project.
OpenCode doesn't ship with built-in persistent memory. If you use OpenCode and Claude Code and Cursor, each tool maintains its own isolated silo.
The OpenCode Memory Dilemma: Desktop RAM vs CLI Persistence
When engineers search for "OpenCode memory", they typically struggle with one of two distinct bottlenecks:
1. Desktop App RAM Leaks (10–20 GB Footprint)
The OpenCode Desktop GUI renders all active and past chat sessions inside an Electron/Chromium runtime. Over hours of coding, in-memory DOM nodes and token buffers accumulate, causing memory consumption to balloon into tens of gigabytes and freeze your system.
2. CLI Terminal Statelessness
Developers seeking to avoid GUI bloat switch to the OpenCode CLI, which is lightweight and fast. However, the CLI resets completely after each run. All knowledge of architectural decisions, database models, and bug fixes vanishes as soon as the terminal closes.
The Solution: Memwyre bridges the gap. By connecting the lightweight OpenCode CLI to Memwyre's remote cloud vault, you get instant persistent context on session launch with zero local memory leak overhead.
Four Approaches to OpenCode Memory
| Feature | Manual Context Files | Mem0 / Supermemory (Vector / Web RAG) | MCP Memory Server | Memwyre Plugin |
|---|---|---|---|---|
| Automation | Manual edits | Predictive (LLM decides) | Predictive (LLM decides) | Deterministic (create/start → idle/end) |
| Storage | Flat files | Local SQLite + ChromaDB | Varies | Cloud vault + entity graph |
| Setup | Manual file creation | Hours (SDK & API Key Config) | JSON config + key | npm install @memwyre/opencode-plugin |
| Cross-Session | ❌ No persistence | ✅ Via API / Web extension | ✅ Via tool calls | ✅ Auto-injected on startup |
| Cross-Tool | ❌ OpenCode only | ❌ Custom pipelines / Chrome extension | ✅ Any MCP client | ✅ Shared vault (Claude Code, Cursor, VS Code) |
| License | N/A | Apache-2.0 / MIT | Varies | Apache-2.0 |
| Best For | Static rules | API developers & Web bookmarking | Real-time tool access | Hands-free cross-tool memory |
These approaches are complementary, not exclusive. Use manual files for static rules and Memwyre for dynamic OpenCode session memory — they work together.
Memwyre vs. Mem0 & Supermemory for OpenCode
Developers looking for long-term memory in OpenCode often evaluate general-purpose memory systems like Mem0 (API-first memory SDK) or Supermemory (web bookmarking & second brain engine). While both offer vector storage capabilities, neither includes a native plugin built for OpenCode's internal architecture.
Why OpenCode developers prefer Memwyre:
- Native OpenCode SQLite Integration: Memwyre's plugin reads session transcripts directly from OpenCode's local database (`~/.local/share/opencode/opencode.db`) using native `node:sqlite`. It requires zero custom API integration code.
- Automatic Lifecycle Hooks: Hooks into OpenCode's `create`/`start` events to inject past architectural context and `idle`/`end` events to capture newly learned facts seamlessly.
- LoCoMo-10 Benchmark Scores: Memwyre's two-stage cross-encoder engine achieves 70.5% overall accuracy on the LoCoMo-10 benchmark vs. 43.7% for standard vector RAG systems. (Compare features on our Memwyre vs. Mem0 and Memwyre vs. Supermemory pages.)
How Cross-Tool Sync Actually Works
- OpenCode (plugin): hooks into session lifecycle. On start → retrieval API. On end → POST transcript.
- Claude Code / Cursor / VS Code (MCP) / Claude Desktop / OpenClaw: connect via MCP or their respective plugins to same vault.
- Same API key = same vault.
How the Memwyre OpenCode Plugin Works
① Session Start — Context Injection
When you start an OpenCode session (create/start/init events), the plugin calls the Memwyre retrieval engine for past memories matching the current project and injects them into the session prompt.
<memwyre-context>
## Past Memories for my-project
- Database uses PostgreSQL 15 with pgvector
- Auth flow: JWT + refresh tokens in httpOnly cookies
- Fixed: race condition in worker queue (use Redis lock)
</memwyre-context>② Session End — Session Capture
When the session goes idle or ends, the plugin reads the session transcript — from the client API, event payload, or directly from OpenCode's local SQLite database at ~/.local/share/opencode/opencode.db. Sends it to Memwyre's background worker for extraction. Uses deduplication tracking to prevent double-captures.
Troubleshooting & Edge Cases
- Misclassified memory: view/edit/delete via dashboard or API
- Stale facts: Ebbinghaus decay auto-deprioritizes
- Deduplication: capturedSessions Set prevents duplicate captures
- SQLite fallback: if the client API doesn't provide messages, the plugin reads directly from OpenCode's local database
Install in 60 Seconds
Choose between automated CLI setup or direct npm package configuration:
Option A: Interactive CLI Installer (Recommended)
npx -y install-memwyre --opencodeAutomatically detects your OpenCode config directory, logs you in via browser, and writes the plugin configuration.
Option B: Manual Plugin Setup
- 1. Install the npm package:
npm install @memwyre/opencode-plugin - 2. Register in OpenCode config (
opencode.config.jsor.opencode/plugins/memwyre.js):import { MemwyrePlugin } from '@memwyre/opencode-plugin'; export default { plugins: [MemwyrePlugin] }; - 3. Export your API key:
export MEMWYRE_API_KEY="bv_sk_your_api_key_here"
What OpenCode Remembers With Memwyre
- 🧠 Architecture Decisions
- 🐛 Debugging Solutions
- 🔗 Entity Relationships
- ✂️ Dynamic Pruning
Benchmark: Why Retrieval Quality Matters
We evaluated Memwyre's retrieval engine against a flat vector RAG baseline on the LoCoMo-10 benchmark (Snap Research, ACL 2024):
| Category | Flat Vector RAG | Memwyre Engine | Improvement |
|---|---|---|---|
| Multi-Hop | 24.0% | 45.0% | +87.5% |
| Overall | 43.7% | 70.5% | +61% |
| Context Tokens | ~26,000 | ~3,000 | −81% |
View the full LoCoMo-10 benchmark results →
Real-World Workflow: Iterative Feature Development
Scenario: building a payment integration over multiple sessions. Session 1 establishes the Stripe webhook architecture. Session 2 implements the subscription billing logic. Session 3 adds the retry/idempotency layer. Without memory, Session 3 doesn't know about the webhook signing secret rotation decision from Session 1. With Memwyre, all sessions share context.
Token Costs, Noise, & Security
Noise Filtration
Not every CLI error needs to be remembered. Memwyre's backend uses a specialized extraction model that differentiates between ephemeral noise and structural knowledge. Only the structural knowledge is saved to your vector vault, keeping your persistent memory highly relevant and dense.
Token Efficiency
By summarizing and deduplicating past sessions, the plugin injects a concise <memwyre-context> block that rarely exceeds 1,500 tokens. Compared to manually pasting in megabytes of old transcript logs, this targeted injection saves API costs while providing superior context.
Enterprise Security
Your code is yours. The Memwyre extraction engine uses zero-retention policies—meaning your transcripts are processed in memory and immediately discarded. For enterprise environments with strict compliance requirements, the entire Memwyre backend can be self-hosted behind your firewall.
License & Requirements
- Apache-2.0
- Node.js 18+, any OS
- Self-hosting: Docker deployment
- No special profile requirements (unlike OpenClaw)
Why Not Just Use Manual Context?
Manual files are good for static rules, but limited by maintenance, flat storage, and tool-locking. They don't update automatically as your architecture evolves.
