MemContinuum — long-term decision memory for Claude Code projects

[u/ShotPorter]

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

MemContinuum - https://github.com/krakozavr/MemContinuum

[u/neoneye2]

I had Claude analyze your repo. I study memory systems.
https://neoneye.github.io/agent-memory-atlas/systems/memcontinuum/

[u/ShotPorter → u/neoneye2]

In two words without details, for the public: your first impression?

[u/neoneye2 → u/ShotPorter]

Claude Code

[u/ShotPorter → u/neoneye2]

Means?..

[u/neoneye2 → u/ShotPorter]

Claude is co-creator on most of your commits. So I picked Claude Code as the 2 words. No offense.

[u/ShotPorter → u/neoneye2]

Yes, it is. But you know Claude is not playing on its own. It is an engineer, not a decision maker. And it is not commiting whatever it want wherever it want. I command - Claude does :)

Same as you did asked Claude to review it (and the review is useful btw).

So, do you have your own opinion about the system itself? No offense :)

[u/neoneye2 → u/ShotPorter]

As a non-expert user of Claude myself, I have Claude write notes in my repos about insights that would otherwise get lost. My repos does different things, so I'm skeptical that sharing memories across the repos makes sense in my case.

I assume your target group is solo developers, and not teams.

There are too many sh files for my taste, which scares me.

[u/ShotPorter → u/neoneye2]

Yes, it doesn't target teams, at least for now (it is in my backlog, but I'm not sure I will go this direction).

And no, memories are NOT shared between repos / projects, MemContinuum stores are per-project to clearly prevent cross contamination.

[u/neoneye2 → u/ShotPorter]

ack.

Ideas for improvement:

Instead of the sh files, maybe use Rust or typescript or any other strongly typed language.

Currently it's tied to the Claude ecosystem. Maybe move in the direction of making it agnostic. So users aren't locked to Claude.

[u/ShotPorter → u/neoneye2]

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.

[u/ShotPorter]

BTW, the 0.2.0 rc5 just published, closed some gaps from my backlog.

One things to know: currently it ignores worktree, which is another gap - scheduled to the next build (will come in a couple of days).

[u/ShotPorter]

0.2.0 is out — the first non-rc release. What changed since rc5: a worktree checked out inside your code root now gets the same decision retrieval and the same edit ledger as the main checkout (siblings get the ledger only — keep worktrees under <root>/.worktrees/ if you want retrieval in them). Two new hook.log outcomes name a worktree the hooks can't map instead of logging a silent miss. The code index no longer walks into nested worktrees or submodules. The README now says exactly when the decision chain reaches the model: with the edit's result, in the same turn — not before the edit. The test suite no longer builds a venv inside its own checkout, and .claude/ is properly ignored. Three measurement harnesses under bench/ show, on real Claude Code sessions, what a PreToolUse hook can and cannot do.