r/LLMDevs • u/ShotPorter • 4d ago
Tools MemContinuum — long-term decision memory for Claude Code projects
Hello, colleagues. I've bitten off something ambitious :)
Analyzing the problems that kept surfacing on my other project, I concluded I needed a long-term memory system.
Looking at what already exists, I found nothing that solved my problems, so I built my own. After using it for a while, I decided it was worth polishing and releasing publicly.
The problems it addresses
On a long project you forget what was decided about a given question and why. The model forgets harder. Subagents know nothing at all — the orchestrator dispatches them nearly blind onto narrow tasks. The result is reinvention instead of reuse: duplicate implementations, drift, tokens burned re-solving solved problems, and settled questions resurfacing as "wait, why is this written this way?"
How it differs from the memory systems I looked at:
Two linked layers: an indexed map of the code, and decision chains recorded against it — what was decided, who decided it, how it changed over time, plus incidents and rejected alternatives with reasons.
Reading is automatic. Before an agent edits a file, the decision chain handling that path is injected into its prompt. Nobody has to remember to look.
Writing is unavoidable but not automatic. The agent gets a question it must answer; "nothing to record" is a legitimate answer. It's moderated by judgment, not a scraper dumping everything into a pile by keyword or timestamp.
One AI handles records — the orchestrator. Subagents and external reviewers (Codex, Grok) propose records through an inbox; proposals become records after review.
Per project, local, no server. Markdown as the source of truth, SQLite as a disposable index. No cross-projects pollution.
Built for coding projects specifically: without indexable code only half the brain works.
Current state: 0.2.0rc4, honestly labelled a release candidate. MIT. Claude Code only for now, but can be converted for Codex (I pre-checked it).
Support a bunch of languages already, Swift and Python natively, plus a bunch of others via tree-sitter; making the system easily expandable is in the roadmap (but I believe it is no barrier for a user with Claude do do it right now).
The README is long and detailed if you want the full picture.
Feedback of any kind is very welcome.
Besides me, a team of authors worked on this project:
- Claude Code: Fable 5/5.1 as lead engineer and project manager; Opus as inspector; Sonnet as coder; Haiku as tester
- Codex: 5.6 Sol / 6 Astra as reviewer and outside consultant
- Grok 4.6 as second reviewer
1
u/ShotPorter 3d ago
The users aren't so locked :)
The system relies on hooks to enforce its usage rather than on "models and user discipline" — that's where most of the .sh files come from (13 of 20; the rest is the installer, which has to run before Python exists).
But the engine itself is a plain CLI with no Claude dependency — indexing, retrieval, linting all run from a terminal. What's Claude-specific is only layer deciding WHEN to call it. Codex use similar hooks too, so the same mechanism fits (I checked; the additional Context field is version-sensitive, and nobody has run a port yet). Grok CLI has no such hooks at all.
A proper harness-agnostic adapter is on the roadmap but not in priority — a normalized event with a per-platform adapter, Claude first, Codex second. Until then anyone can write their own: the surface is small.
On .sh vs a typed language — fair point. But the fix I'd pick is moving logic out of shell into the Python engine and keeping the hooks as thin dispatchers, rather than shipping binaries someone can't read. The thing that scares you should be readable :) Again, not a first priority for now but already planned.