Auto Dream

Anthropic pushed a feature into Claude Code without any public announcement. It goes by Auto Dream, and it tackles the core weakness of auto memory: notes rot as they pile up.

Problem: Auto memory was a real step forward. Claude started keeping its own project notes. After 20 or more sessions though, the notebook gets ugly. Entries start disagreeing with each other. Relative dates like "yesterday" stop meaning anything. Old debugging tips still point at files that were deleted in a refactor. What should be helpful memory turns into background noise that throws Claude off.

Quick Win: See if Auto Dream is live on your install. Open any Claude Code session and run /memory. Scan the selector for "Auto-dream: on". If the flag is there, Claude is already tidying up your memory files between sessions in the background.

# Check your current memory state
/memory
 
# Look for:
# Auto-dream: on

See the toggle and it's flipped on? You're good. Every so often, Claude walks through the project's memory files, throws out what has gone stale, fixes contradictions, and reshuffles the rest. No toggle yet? Read on. A manual trigger still works.

Why Call It Dreaming? The REM Sleep Angle

The name was not picked by accident. The analogy actually lines up.

Your brain soaks up raw input all day and parks it as short-term memory. REM sleep then runs through the day's events, holds onto the connections that mattered, drops what didn't, and files the rest into long-term storage. Skimp on REM and you struggle to form lasting memories. Information arrives but never gets consolidated.

Auto memory plays the role of Claude's waking brain. It jots things down while it works: debugging patterns, build commands, architecture calls, your quirks. Each session piles on more entries. With no cleanup pass though, those notes grow messy the same way an un-consolidated short-term memory does. Old contradictions hang around. Outdated entries never leave. Signal gets drowned in noise a little more every session.

Auto Dream plays the REM role. It looks at what auto memory has gathered, keeps the parts still worth keeping, clears out anything past its expiration, and reshapes the rest into tidy topic files with a clean index. Without it, Claude Code was basically running on no sleep. Notes kept stacking up. The cleanup never came.

The Four Phases of a Dream Cycle

Auto Dream walks through a four-phase routine every time it runs. Each phase has its own job, and together they turn a scattered pile of session notes into organized project knowledge.

Phase 1: Orientation

Claude opens the memory directory and catalogs what is already there. It reads MEMORY.md (the index), looks at the list of topic files, and sketches out where things currently stand.

The question this phase answers: "What do I already know, and how is it filed?"

Phase 2: Gather Signal

Next, Auto Dream digs through your session transcripts (those JSONL files Claude keeps locally for every session). Reading each one front to back is off the table. On a project with hundreds of sessions, that would be absurd on tokens and time. The pass is narrow. It hunts for specific patterns only:

• User corrections: Points where you told Claude it was wrong or pushed it in a new direction
• Explicit saves: When you said "remember this" or "save to memory"
• Recurring themes: Patterns that turned up across many sessions
• Important decisions: Architecture calls, tool choices, workflow changes

That narrow pass is deliberate. Reading 500 transcripts end to end would burn tokens for almost nothing new. Tight grep-style queries pull out the high-signal bits without the waste.

Phase 3: Consolidation

This is the main event. Claude folds new information into existing topic files and handles the critical upkeep:

• Relative dates get rewritten as absolute dates. "Yesterday we decided to use Redis" turns into "On 2026-03-15 we decided to use Redis." That stops timing from getting confused as memories age.
• Contradicted facts get deleted. Switched from Express to Fastify three weeks ago? The old "API uses Express" entry disappears.
• Stale memories get pruned. Debugging notes pointing at a file that was wiped in a refactor serve no purpose. Out they go.
• Overlapping entries get merged. Three sessions that all flagged the same build command quirk collapse down to one clean note.

Phase 4: Prune and Index

The last phase focuses on MEMORY.md. That file is held under 200 lines because 200 is the cutoff for what gets loaded at startup. Phase 4 updates MEMORY.md so it mirrors the current state of the topic files:

• Drops links to topic files that no longer exist
• Adds pointers to new topic files created during consolidation
• Clears up any gap between the index and what the files actually say
• Reorders entries by relevance and freshness

Topic files that didn't need edits in consolidation are left alone. Auto Dream does not rewrite the world on every run. The changes are surgical.

The Full System Prompt

Here's the actual system prompt that powers Auto Dream. This is what Claude receives when a dream cycle kicks off:

# Dream: Memory Consolidation
 
You are performing a dream - a reflective pass over your memory files.
Synthesize what you've learned recently into durable, well-organized
memories so that future sessions can orient quickly.
 
Memory directory: `~/.claude/projects/<project>/memory/`
This directory already exists - write to it directly with the Write tool
(do not run mkdir or check for its existence).
 
Session transcripts: `~/.claude/projects/<project>/`
(large JSONL files - grep narrowly, don't read whole files)
 
## Phase 1 - Orient
 
- `ls` the memory directory to see what already exists
- Read `MEMORY.md` to understand the current index
- Skim existing topic files so you improve them rather than creating
  duplicates
- If `logs/` or `sessions/` subdirectories exist (assistant-mode layout),
  review recent entries there
 
## Phase 2 - Gather recent signal
 
Look for new information worth persisting. Sources in rough priority order:
 
1. **Daily logs** (`logs/YYYY/MM/YYYY-MM-DD.md`) if present - these are
   the append-only stream
2. **Existing memories that drifted** - facts that contradict something
   you see in the codebase now
3. **Transcript search** - if you need specific context (e.g., "what was
   the error message from yesterday's build failure?"), grep the JSONL
   transcripts for narrow terms:
   `grep -rn "<narrow term>" <project-transcripts>/ --include="*.jsonl"
| tail -50`
 
Don't exhaustively read transcripts. Look only for things you already
suspect matter.
 
## Phase 3 - Consolidate
 
For each thing worth remembering, write or update a memory file at the
top level of the memory directory. Use the memory file format and type
conventions from your system prompt's auto-memory section - it's the
source of truth for what to save, how to structure it, and what NOT
to save.
 
Focus on:
 
- Merging new signal into existing topic files rather than creating
  near-duplicates
- Converting relative dates ("yesterday", "last week") to absolute dates
  so they remain interpretable after time passes
- Deleting contradicted facts - if today's investigation disproves an old
  memory, fix it at the source
 
## Phase 4 - Prune and index
 
Update `MEMORY.md` so it stays under 200 lines. It's an **index**, not a
dump - link to memory files with one-line descriptions. Never write memory
content directly into it.
 
- Remove pointers to memories that are now stale, wrong, or superseded
- Demote verbose entries: keep the gist in the index, move the detail into
  the topic file
- Add pointers to newly important memories
- Resolve contradictions - if two files disagree, fix the wrong one
 
---
 
Return a brief summary of what you consolidated, updated, or pruned. If
nothing changed (memories are already tight), say so.

A few details from this prompt are worth flagging. It tells Claude flat out to grep narrowly and stay away from full transcript reads. It holds MEMORY.md to the 200-line ceiling. And it tells Claude to fix contradictions at the source file rather than just calling them out. The prompt has strong opinions about how memory should look, which is why the output comes out consistently neat.

When a Dream Cycle Kicks Off

Two things must be true at the same time for consolidation to run:

1. At least 24 hours have gone by since the previous consolidation
2. More than 5 sessions have happened since the previous consolidation

Both gates are required. One marathon session across two days will not fire Auto Dream (the session count is too low). Ten fast sessions inside two hours will not fire it either (not enough time has passed). The double gate keeps quiet projects from triggering useless cleanup runs and makes sure active ones stay tidy.

For a sense of scale: in one observed run, Auto Dream worked through 913 sessions of memory in roughly 8 to 9 minutes. Not free, but the work happens in the background so you never feel the cost.

Safety Guarantees

Auto Dream runs inside real guardrails. Accidents are hard to make.

Project code stays read-only. Inside a dream cycle, Claude can only write to memory files. Source code, configuration, tests, and the rest of your project files are off limits. The dream process is boxed into the memory directory.

A lock file blocks overlap. Have two Claude Code instances open on the same project? Only one can run Auto Dream at a time. A lock file stops two consolidation runs from fighting each other, which would otherwise cause merge conflicts in the memory files.

Runs in the background. Auto Dream does not block your session or make you wait. You keep working in Claude Code while it runs. The consolidation happens in its own process.

Triggering a Dream Manually

Waiting for the automatic trigger is optional. If you know memory needs cleanup (say, right after a big refactor), you can force a consolidation yourself.

The /dream command exists but has not reached every account yet. While you wait for it, just tell Claude what you want:

"dream"
"auto dream"
"consolidate my memory files"

Claude picks up on the intent and walks through the same four-phase flow. Useful after big changes to the project, when fresh memory matters and waiting for the next automatic cycle is too slow.

Before and After: A Real Consolidation

Here is what a typical memory directory can look like on either side of a dream cycle.

Before (Messy, 30+ Sessions of Accumulation)

~/.claude/projects/<project>/memory/
├── MEMORY.md              # 280 lines, over the 200-line limit
├── debugging.md           # Contains 3 contradictory entries about API errors
├── api-conventions.md     # References Express (switched to Fastify 2 weeks ago)
├── random-notes.md        # Mix of stale and current info
├── build-commands.md      # "Yesterday" used 6 times with no dates
└── user-preferences.md    # Duplicates entries from MEMORY.md

After (Consolidated)

~/.claude/projects/<project>/memory/
├── MEMORY.md              # 142 lines, clean index with links to topic files
├── debugging.md           # Deduplicated, only current solutions
├── api-conventions.md     # Updated to reflect Fastify migration
├── build-commands.md      # All dates absolute, no duplicates
└── user-preferences.md    # Merged with relevant MEMORY.md entries

The random-notes.md file is gone. Its content either got folded into relevant topic files or pruned for being stale. MEMORY.md shrank from 280 lines down to 142, back under the 200-line startup threshold. Contradictions are resolved. Dates are absolute.

Auto Memory vs Auto Dream: Two Layers of One System

These two features work together, not against each other. Picture them as the collection layer and the upkeep layer of a single memory setup.

Auto memory with nothing cleaning up afterward is like a note-taker who never flips back through the notebook. The reverse holds too: without anything writing new notes, a dream cycle has nothing to work on. You want both running.

Four Memory Systems: The Complete Picture

With this new layer, Claude Code has four distinct memory mechanisms. Here is how the full set fits together, building on the table from the auto memory deep-dive:

The strongest setup runs all four. CLAUDE.md carries the rules you own and control. Auto memory captures what Claude picks up on the job. Session memory carries conversation threads across restarts. And the dream cycle keeps that accumulated knowledge current, accurate, and organized.

Practical Tips

Let the automation handle most projects. The default gates (24h plus 5 sessions) fit active development well. No babysitting required.

Force a dream right after a big refactor. Renamed half your codebase? Swapped frameworks? Reshaped your API? Trigger a manual cycle. Old entries will confuse more than they help until they get reconciled.

Glance at the output every so often. After a dream cycle finishes, skim MEMORY.md. Auto Dream is good, but it's not flawless. A consolidation choice might rub you the wrong way. The files are plain markdown. Edit them however you want.

Pair it with good context hygiene. A dream cycle keeps your memory files clean, but the active session context is still yours to manage. Cleaner files mean Claude loads less garbage at startup, which leaves you more room for real work in the context window.

Next Steps

• Get CLAUDE.md in place first if you haven't already. A dream cycle consolidates auto memory, but CLAUDE.md remains the highest-priority source of truth.
• Read up on auto memory to see exactly what Claude is capturing during sessions, which is the raw material Auto Dream works on.
• Check out session memory for conversation-level continuity between work sessions.
• Look at context engineering to see how all these memory systems add up to a deliberate context strategy.
• Watch the Claude Code changelog for memory system updates, including when Auto Dream rolls out on your plan tier.
• New to Claude Code? Follow the installation guide to get set up on macOS, Windows, or Linux before touching memory configuration.

Auto Dream is the piece that turns Claude's memory from a growing stack of notes into a live, maintained knowledge base. Auto memory gathers the raw material. Auto Dream shapes it into something Claude can actually use. The net effect is a Claude that not only remembers more over time, but remembers better.