Memory features get judged on the wrong axis. Everyone asks whether Claude Code can remember things across sessions; almost nobody asks what happens to those memories after month three. I can answer the second question from my own files, because I've run auto-memory on this Laravel platform's repo continuously for months — a MEMORY.md index pointing at roughly twenty topic files covering everything from an SEO recovery to a production cron outage. The verdict: accumulation without consolidation isn't memory, it's hoarding. Which is exactly the problem /dream exists to solve, and why I spent two weeks running it deliberately across my active projects instead of letting it fire in the background.
The Decay Pattern I Can Show You From My Own Files
Here's what memory rot actually looks like, from a real entry in my own project memory. I ran a long multi-session content-rewrite pipeline on this site. Each session appended its findings to the same memory entry. By the end, that entry contained two different "next batch" pointers left by different sessions, plus a gotcha paragraph that appeared twice in slightly different wording, because a later session re-learned a lesson an earlier session had already recorded and appended it instead of reconciling.
No single session did anything wrong. Each one wrote down true things. But truth has a timestamp, and appended truths from different weeks eventually contradict each other. A fresh session reading that entry has no way to know which "next batch" is current — the same way it can't know whether "we use Sanctum" from an old session survived the session where you ripped Sanctum out.
The tell, before you ever open the files, is hedging. When Claude starts answering questions it used to answer flatly with "you might want X or Y depending on your setup," that's not the model getting cautious. That's the model finding two conflicting entries in its own notes and refusing to bet. I wrote about the layers where this stuff lives in Claude Code's six levels of memory; /dream is the maintenance pass for the auto-memory layer specifically.
What /dream Actually Does
You can trigger consolidation manually by typing /dream, or let it fire automatically. The automatic trigger is dual-gated: more than 24 hours since the last consolidation and at least five sessions of new activity. Both gates must open. A burst of ten sessions in one afternoon won't trigger it; neither will one idle project aging past 24 hours. That calibration is smarter than it looks — light projects don't burn cycles on cleanup they don't need, and I confirmed on a small documentation project that dream mostly leaves already-clean memory alone.
The run itself is a four-phase pass, and having watched it work over my real files, the phases matter more than the branding:
Orient. The consolidation agent reads the memory directory and maps what exists — the index, the topic files, which ones have bloated. In my case the map is MEMORY.md plus topic files like the SEO-recovery log and the server-credentials reference. Nothing is modified yet.
Gather signal. It scans recent session transcripts (the JSONL files Claude Code already keeps) for high-value events: moments you corrected it, decisions you committed to, patterns that recurred across sessions, and anything you explicitly asked it to remember. Corrections are the gold in this pass. Every "no, we stopped using that" is a place where the memory's model of the project was wrong and a human said so.
Consolidate. Relative dates become absolute dates. Contradictions get resolved toward the most recent truth. Duplicates merge into one entry. This is the phase that would fix my double "next batch" pointer: two session-stamped claims, keep the later one, done. The absolute-date conversion is quietly the most valuable operation in the whole feature. My healthiest memory entries are the ones that read like changelog lines — "RESOLVED Jun 11," "DEPLOYED 2026-07-17" — and the ones that caused problems always said "recently" or "yesterday." Which yesterday? Nobody knows, including the model that wrote it.
Prune and index. MEMORY.md gets rebuilt as a lean index under 200 lines — the practical threshold for what loads at session start, so anything past it is invisible anyway. Stale debugging notes and superseded decisions get removed, not archived.
The Part That Requires an Opinion: Deletion
Superseded entries are deleted. I think that's the right default, and it's the part most people will be nervous about. A stale architecture note in memory is worse than no note, because a confident wrong answer costs more than a question. But it collides with something I actually do: my memory files double as a project log. Entries record what shipped, what's pending, what broke in June. A consolidation pass optimizing for "current state of the world" and a human using memory as "history of the work" want different things from the same files.
Two habits reconcile them. First, the memory directory lives in version control on my machine, so a dream cycle is a diff I can read, and I do read it — the same way I'd review a refactor. The one time a cycle prunes a note you still needed, you re-add it in thirty seconds, and you learn to write notes that survive: status markers and absolute dates up front, narrative second. Second, anything that's genuinely a log goes into its own dated entry rather than being appended to a living one. Dream keeps the status line and drops the story, which is correct behavior — as long as the story wasn't the only place a fact lived. My longer-term archive of decisions lives outside auto-memory entirely, in the second-brain setup I've written about, with Obsidian as the durable layer. Auto-memory is working memory; it should be allowed to forget.
What Two Weeks of Deliberate Cycles Changed
Running dream on a schedule rather than waiting for the automatic trigger did three observable things across my projects.
The hedging dropped. On topics covered by memory, answers went back to being committed and specific, because the conflicting entries that caused the hedging were gone. This was the single clearest quality change, and it showed up within the first cycle on my biggest repo.
Context got cheaper. A lean 200-line index loads instead of a sprawl of accumulated notes, which means less of the context window burns on stale project trivia before the session even starts. If you're already fighting context limits — and on long sessions you are — memory bloat is a tax you're paying on every single session. It compounds with everything else I do for token and context hygiene.
The memory became legible to me, not just to Claude. This one I didn't expect. A consolidated index is a genuinely useful project dashboard for the human too: current state, absolute dates, open items. Before consolidation, my files were write-only — Claude wrote them, nobody could comfortably read them.
The honest limits: dream resolves contradictions toward recency, and recency is usually but not always right. If you corrected a correction and then reverted, the surviving entry is whatever came last, which may be the wrong end of your own flip-flopping. It also can't distinguish "this debugging note is stale" from "this debugging note is for a bug that recurs every quarter." Both look resolved. Both get pruned. The diff review catches these, and on light projects — under roughly twenty sessions — there's little enough decay that the whole exercise is optional.
Should You Bother Triggering It Manually?
If you're under fifteen sessions on a project, no. The automatic gates will do the right thing, and dream on a clean project is a no-op with extra steps. If you're deep into a long-running repo and you've noticed hedging, stale package references, or suggestions that contradict decisions you made weeks ago, run /dream today and read the diff. The before/after on a genuinely decayed memory is not subtle.
And if you've never looked at your memory files at all, start there. Open MEMORY.md. If you find relative dates, duplicate lessons, or two versions of the same decision, you're not looking at a broken feature — you're looking at what any append-only knowledge store becomes without a consolidation pass. Brains solved this with sleep. Claude Code solved it with dream. The joke writes itself, but the mechanism is legitimately the same: keep what got confirmed, date what got decided, drop what got superseded.
Memory design — what belongs in a project file, what gets dated, what gets pruned on sight — is one of the hands-on units in the courses at my AI School. The systematic version costs less than rediscovering it from a decayed MEMORY.md six months in.
