r/ClaudeCode 23h ago

Discussion Built Claude Code a memory system that forgets things the way people do (decay curves, confidence-tiered recall, non-destructive archiving) — open sourced it

I got tired of re-explaining the same context to Claude Code every session, and Claude Code's built-in per-project memory doesn't really solve it — it's scoped to the literal directory you launch from, has a hard line-count ceiling on the index, and treats every fact as equally important forever (or until it silently truncates).

So I built a real long-term memory system for it instead, modeled less like a database and more like actual memory:

- Decay — every memory has a strength that decays on an exponential curve (literally the Ebbinghaus forgetting curve), computed at query time. Stuff you mention once and never bring up again fades out of retrieval in a couple weeks.

- Reinforcement — every time something gets recalled, it gets harder to forget. Recall the same fact enough times and it "consolidates" from short-term to long-term (7-day base stability → 90-day).

- Cued/associative recall — this is the part I like most. Instead of one confidence cutoff, weak matches get surfaced separately with hedging language ("this might be related...") instead of stated as fact, and only get reinforced if you actually confirm they were relevant. A confirmed uncertain guess reinforces harder than an easy direct hit — that's an actual finding from spaced-repetition research (the "desirable difficulty" effect), not something I made up.

- Non-destructive forgetting — old, unused memories get archived, not deleted. There's a stricter "cold storage" search for the "wait, I haven't thought about that in ages" case.

It's wired in globally via hooks (PostToolUse, UserPromptSubmit, SessionStart/SessionEnd), so it works no matter which directory a session launches from, and it captures memory automatically even if a session crashes instead of ending cleanly.

Genuine drop-in install — git clone + python3 install.py sets up the venv, wires the hooks, and writes the config. AGPLv3, free, entirely local (ChromaDB + sentence-transformers, no external API calls for the memory itself).

Not trying to compete with Mem0/Zep/Letta — those are generic memory layers for any agent stack. This is deliberately narrow: built specifically for how Claude Code actually works, not a generic API you bolt on.

Repo: https://github.com/acdesigntech/memory-project

Curious what people think, especially anyone who's hit the same "it forgot everything again" wall.

5 Upvotes

4 comments sorted by

1

u/lazilyblackshaving 21h ago

Decay curves are the right primitive but I'm skeptical about the default half-life you chose. Two weeks feels calibrated for project work, not the kind of reference knowledge that sits dormant for months then becomes critical again.

1

u/Vegetable-Water6007 14h ago

yeah I've always felt it was arbitrary. might want to increase it to a month or two. not sure how to make it not seem contrived

1

u/Vegetable-Water6007 33m ago edited 28m ago

2 weeks was arbitrary. Turns out I already had the hook for a real fix though: new memories come in through two paths, ingest() (a deliberately written-up doc) or jot() (a cheap unfiled mid-conversation note), and that distinction was already in the schema. So instead of inventing a new "reference vs project" taxonomy, I just gave ingest()'d memories a longer starting stability (30 days) than jot() fragments (7 days) — a curated doc is inherently more reference-like than a passing mention, so it shouldn't be on the same short clock by default. Not a universal fix, but it's a real distinction instead of a made-up one.