MemMolt vs opencode-mem
Structured long-term memory over MCP: an enforced bucket-thread-memo hierarchy in one SQLite file, hybrid FTS5 + vector search fused with RRF, local embeddings. — versus — OpenCode plugin giving coding agents persistent cross-session memory — local SQLite + vector search, automatic memory capture, user-profile learning, and a web UI. Nothing leaves your machine.
Local SQLite+vector agent memory either way: opencode-mem auto-captures per-session for OpenCode; MemMolt is deliberate, structured recall for any MCP client.
| MemMolt | opencode-mem | |
|---|---|---|
| Stars | 4 | 1.1k |
| Forks | 0 | 113 |
| Language | JavaScript | TypeScript |
| License | MIT | — |
| Last activity | 3 months ago | 6 days ago |
| Topics | memory | memory, coding |
| Curated connections | 2 | 3 |
MemMolt — the curator's take
The anti-sprawl memory play: a forced 3-level hierarchy the agent can't turn into a jungle, with ~10ms hybrid search from a single SQLite file and zero cloud calls. Young and tiny (4 stars) — the schema idea is worth studying even if you don't adopt it. Skip if you want auto-capture; this is deliberate, curated memory.
opencode-mem — the curator's take
For OpenCode users tired of re-explaining their architecture every session: auto-capture summarizes each prompt's work via a background structured-output call that reuses your existing opencode provider auth, memories inject into the first chat message, and the `.opencode-mem-project` marker file solves multi-repo workspaces properly (directory-driven identity, not env vars). A real web UI at :4747 for browsing what it learned. NOT for Claude Code — this is OpenCode-specific; pro-workflow and claude-reflect are the equivalents on that side. Auto-capture needs a provider that speaks structured output, and the default local embedding model downloads on first use. Inspired by opencode-supermemory, but local-first.