Auto Memory and Auto Dream: how Claude Code learns and consolidates its memory

If you’ve been using Claude Code with Auto Memory enabled for a while, you’ve probably noticed that after several sessions, Claude’s notes about your project start accumulating contradictions. Entries saying “yesterday we decided to use Redis” without specifying which day “yesterday” was. Debugging notes referencing files that no longer exist. Three different entries about the same build quirk. What started as a useful notebook becomes noise.

Anthropic has just released Auto Dream, a feature that does exactly what its name suggests: it consolidates Claude Code’s memory the way the human brain consolidates memories during REM sleep.

I found excellent guides on claudefa.st that explain both Auto Memory and Auto Dream in detail. After trying them out, here’s what I’ve learned.

First, let’s understand Auto Memory

To appreciate what Auto Dream does, you need to understand the system it works on. Auto Memory is the mechanism that allows Claude Code to take its own notes about your project. It’s not the CLAUDE.md file you write with instructions — it’s a separate notebook where Claude jots down what it learns while working with you.

Each project gets its own memory directory at ~/.claude/projects/<project>/memory/, with a main MEMORY.md file acting as an index and topic files for detailed notes. What Claude records includes:

• Project patterns: build commands, test conventions, code style preferences
• Debugging insights: solutions to tricky problems, common error causes
• Architecture notes: key files, module relationships, important abstractions
• Your preferences: communication style, workflow habits, tool choices

You can explicitly save knowledge by telling Claude things like “remember that we use pnpm, not npm” or “note that the API tests require a local Redis instance.” Claude writes it to the appropriate file immediately.

The important part: only the first 200 lines of MEMORY.md are loaded at session startup. This means that when the file grows beyond that threshold, Claude loses access to notes below the cutoff. And that’s where the problem Auto Dream solves begins.

Configuring Auto Memory

Auto Memory is enabled by default. You can manage it in several ways:

• Per session: run /memory and use the toggle
• Globally: add "autoMemoryEnabled": false to ~/.claude/settings.json
• Per project: same field in the project’s .claude/settings.json
• Environment variable: CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 (overrides everything else, useful for CI/CD)

The problem: Auto Memory without maintenance degrades

Here’s the key point. Auto Memory is brilliant as a concept, but after 20-30 sessions, note quality starts degrading. I’ve seen this in my own projects:

• Contradictory entries coexisting (“we use Express” alongside newer notes about Fastify)
• Relative dates like “yesterday” or “last week” that lose all meaning over time
• Debugging solutions referencing files you’ve already deleted or renamed
• Three or four entries saying essentially the same thing about the same topic
• MEMORY.md exceeding 200 lines, meaning older notes don’t even load

The notebook that should help Claude remember becomes noise that confuses it. It’s like having a pile of sticky notes you never review: helpful at first, but clutter over time.

Auto Dream: REM sleep for AI

Auto Dream is the answer to that degradation problem.

The REM sleep metaphor is quite accurate

During the day, the brain absorbs raw information and stores it as short-term memories. During REM sleep, it reprocesses those memories: strengthening what’s important, discarding what’s irrelevant, and organizing everything into long-term memory. Without enough REM sleep, information arrives but never consolidates.

Auto Memory is the brain during the day: it captures notes while you work. Auto Dream is the REM sleep cycle: it reviews everything accumulated, reinforces what’s relevant, removes what’s outdated, and reorganizes the result into clean, indexed files.

The four phases of the process

Auto Dream executes a four-phase process that I find elegantly designed:

Phase 1: Orientation

Claude reads the memory directory and takes stock. It opens MEMORY.md (the index file), scans topic files, and builds a mental map of the current state. It’s the equivalent of waking up and remembering where you left things.

Phase 2: Gather signal

Here’s the interesting part. Auto Dream searches through previous session transcripts (JSONL files stored locally), but doesn’t read them in full. It performs targeted searches for specific things:

• User corrections (moments where you said “no, that’s wrong”)
• Explicit saves (“remember this”)
• Recurring themes (patterns appearing across multiple sessions)
• Important decisions (architecture choices, tool changes)

This selectivity is deliberate. Reading 500 full transcripts would burn tokens with diminishing returns.

Phase 3: Consolidation

The core phase, where the heavy lifting happens:

• Converts relative dates to absolute dates. “Yesterday we decided to use Redis” becomes “On 2026-03-15 we decided to use Redis.” This prevents the temporal confusion that builds up over time.
• Deletes contradicted facts. If you switched from Express to Fastify three weeks ago, old Express entries disappear.
• Cleans up stale memories. Debugging notes about deleted files serve no purpose.
• Merges duplicate entries. If three sessions noted the same build quirk, they consolidate into one clean entry.

Phase 4: Prune and index

The final phase focuses on keeping MEMORY.md under 200 lines (the startup loading threshold). It removes pointers to non-existent files, adds links to newly important memories, and resolves contradictions between the index and file contents.

What I like is that files requiring no changes are left untouched. Auto Dream is surgical, not a full rewrite on every run.

When it triggers

Two conditions must be met simultaneously:

1. 24 hours have passed since the last consolidation
2. More than 5 sessions have occurred since the last consolidation

Both conditions must be true. A single long two-day session won’t trigger it (too few sessions). Ten quick sessions in two hours won’t trigger it either (too little time). This dual gate prevents unnecessary runs on low-activity projects while ensuring regular cleanup on active ones.

One observed case consolidated memory from 913 sessions in roughly 8-9 minutes. Substantial, but it runs in the background without blocking your work.

Safety guarantees

Three aspects that give me peace of mind:

• Write access limited to memory. During dream cycles, Claude can only write to memory files. It never touches source code, configuration, tests, or project files.
• Lock file for concurrency. If you have two Claude Code instances open on the same project, only one can run Auto Dream.
• Background execution. You can keep working while consolidation runs.

The complete picture: four memory systems

With Auto Dream, Claude Code now has four distinct memory mechanisms working together:

The strongest setup uses all four. CLAUDE.md provides authoritative rules you control. Auto Memory captures what Claude learns while working. Session Memory maintains conversation continuity. Auto Dream keeps accumulated knowledge clean and current.

Practical tips

Let it run automatically for most projects. The default trigger conditions (24h + 5 sessions) work well for active development.

Force a dream after major refactors. If you renamed half your codebase, migrated frameworks, or changed your API structure, trigger a manual cycle by saying “dream” or “consolidate my memory files” in Claude Code. Old entries will cause more confusion than clarity until consolidated.

Review the output occasionally. After a dream cycle runs, skim your MEMORY.md. Auto Dream is good but not perfect. The files are plain markdown — edit them freely if you spot something off.

Before and after

To see the real difference, here’s an example of memory state before and after consolidation:

Before (30+ sessions without consolidation):

~/.claude/projects/<project>/memory/
├── MEMORY.md              # 280 lines (exceeds the 200-line limit)
├── debugging.md           # 3 contradictory API error entries
├── api-conventions.md     # References Express (migrated to Fastify 2 weeks ago)
├── random-notes.md        # Mix of stale and current information
├── build-commands.md      # "Yesterday" used 6 times without actual dates
└── user-preferences.md    # Duplicates entries from MEMORY.md

After (consolidated):

~/.claude/projects/<project>/memory/
├── MEMORY.md              # 142 lines, clean index with topic file links
├── 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 contents were either merged into topic files or pruned as stale. MEMORY.md dropped from 280 to 142 lines, restoring it below the 200-line startup threshold.

My take

Auto Memory on its own was already a significant step forward. Having Claude take notes about your project, learn your work patterns, and remember solutions to past problems changed the experience meaningfully. But it had a structural flaw: nobody was doing cleanup.

Auto Dream closes that loop. It’s the difference between taking notes and studying them. Between writing a journal and reviewing it. Auto Memory captures raw information; Auto Dream transforms it into useful, current knowledge.

After weeks of intensive use, my memory files had become a dumping ground of contradictory notes and stale references. Having Claude clean up after itself, surgically and without touching my code, is exactly the kind of feature that makes a difference in day-to-day work. The combination of both systems turns Claude Code into an assistant that doesn’t just remember more over time, but remembers better.