My Claude Code memory only remembered one week

Where Claude Code memory runs out

Claude Code keeps auto memory per project in ~/.claude/projects/<project>/memory/. There's one index, MEMORY.md, plus a topic file per subject. The index is the only part that loads into every session. The topic files Claude opens when it needs them, if the index tells it they exist.

The rule is short. The first 200 lines or the first 25KB, whichever comes first. YAML frontmatter and HTML comments don't count. Everything after the cut is simply not there.

Why bytes and not lines? My entries got long. The median entry was 198 bytes, 85 of 179 were over 200, and the longest was 626. At that size you hit 25KB around line 120, long before line 200.

New entries go on top, so the oldest ones fall off the bottom without any noise. The session I measured this in opened with a warning: "63 of 182 lines were cut off, starting at line 120". My own count said the same. That warning goes to Claude, though, not to me.

Check your own MEMORY.md

Paste your index or pick the file. The checker uses the documented rule: 200 lines or 25,000 bytes, frontmatter and HTML comments stripped. It tells you which limit you hit first, where the cut falls and which entries Claude never sees.

Rather count all your projects at once? This prints size, lines, number of topic files and how many topic files no index mentions. It reads only, it changes nothing.

for f in ~/.claude/projects/*/memory/MEMORY.md; do d=$(dirname "$f"); n=0; o=0; for t in "$d"/*.md; do b=$(basename "$t"); [ "$b" = MEMORY.md ] && continue; n=$((n+1)); grep -qF "$b" "$d"/MEMORY*.md || o=$((o+1)); done; printf '%6s bytes %4s lines %5s topic files %5s unlinked  %s\n' "$(wc -c <"$f")" "$(wc -l <"$f")" "$n" "$o" "$d"; done

On my box it found 1,024 topic files in that one project, and 201 that neither my index nor my archive mentions. Those notes exist. No session will ever be told they do.

Why didn't Claude Code stop the index from growing?

It tries. Since version 2.1.210, a write that leaves MEMORY.md over a limit still succeeds, but Claude gets an error back telling it to rewrite the index. The example in the docs asks for under 140 lines. Before that version the file was cut on the next load without any signal.

My index sat at 155 percent anyway. I can't tell you exactly why from the outside. What I can see is how it gets written: dozens of sessions a day on this box, all sharing one index, and each one can add a line when something seems worth remembering.

That part is on me. The warning says it plainly: one line per entry, under about 200 characters. Half my entries ignored that and became small reports, with commit hashes, order numbers and next steps. Each one was useful. Together they pushed a week of notes off the end.

Is dreaming the fix for Claude Code memory?

Not today, and Anthropic doesn't claim it is. Dreaming, in Anthropic's post, means letting Claude go back over old session transcripts later to merge notes, fix wrong ones and build a better map of what it knows. The product version is called Dreams. It runs in Claude Managed Agents, it's a research preview behind its own beta header, and it writes a new memory store next to the old one instead of overwriting it.

The Claude Code memory docs don't mention dreaming. There, Claude keeps the index short during the session itself. Anthropic's post says so directly: the top layer that loads every session has to stay small, and much of dreaming's work there is keeping it that way.

The strongest example in the post is a correction. Claude played Pokémon, wrote down the wrong side of a mountain for a landmark, and walked off the same one-way ledge three times. A dreaming pass checked the note against the transcript, fixed it, and the next run went straight back into the cave. That's the part a size checker can't do. Mine only tells you what Claude can't see. It doesn't tell you what Claude believes that isn't true.

Fewer notes won in Anthropic's own tests

The Pokémon comparison is the one everyone quoted on X. Claude Sonnet 3.7 wrote 413 memory files across 225 folders and earned one badge. Claude Fable 5 kept nine files in two folders plus one global.md and earned four. Sonnet 3.7 kept saving things the game already showed on screen, like money and position, so its notes kept going out of date.

I'm careful with that comparison. A Pokémon run isn't a codebase, and my 1,024 topic files aren't the problem, because topic files only load on demand. The index is. Still, the table of contents of my memory was almost as big as everything Fable 5 needed to beat four gyms.

One more result changes how I write memory rules. When Anthropic told Opus 5 and Opus 4.7 to "record only failures", both lost much of the gain memory gave them. Telling the model what memory is for worked better than telling it what to write. My "under 200 characters" rule is a format rule, not a content rule, so it survives that finding. A rule like "always log the commit hash" probably doesn't.

"Fancy name for garbage collection" is half right

I read the replies about an hour after the post, when there were around 200. Skipping the ads, the tone was split between people who liked the idea and people rolling their eyes at the name. "Fancy name for garbage collection" got 15 likes. Another called it "organizing *.md files and their contents with extra steps". A third worried about paying for it: "does it dream on tokens i'm paying for". That's one hour of one thread, not a poll.

For a single MEMORY.md, the critics are right. Keeping an index under 25KB is housekeeping, and a five-line script does it. Where they're wrong is the Mt. Moon note. Checking whether a note is still true needs the transcript and a model reading it, and no garbage collector does that.

The reply I agree with most came from Elliott Smith: "I want Claude to remember why we rejected an approach before it suggests it again." That's exactly the kind of entry that ends up at the bottom of a long index.

My index before and after tonight

I didn't delete anything. I moved the oldest entries into the archive file, put the pointer to that archive on line 2 instead of line 182, and set a working limit of 17.5KB. That's 70 percent of 25KB, the same ratio as the "under 140 lines" Claude Code asks for in its own error.

Honest status: 27 entries are still too long, and the newest ones are the longest. The fix for that is the rule itself, not another trim. One thing worth doing before your next session: run the checker, and if anything important lives at the bottom of your index, a pointer or a rule, move it to the top.

Dreams is still a research preview in Managed Agents, with nothing like it in the Claude Code docs yet. Until that changes, the index is your job. The next weekly count will show whether 17.5KB survives a week with dozens of sessions writing to it.