Auto Dream

A Anthropic inseriu um recurso no Claude Code sem nenhum anúncio público. Ele se chama Auto Dream, e resolve a fraqueza central da memória automática: as notas apodrecem conforme se acumulam.

Problema: A memória automática foi um avanço real. Claude começou a manter suas próprias notas de projeto. Mas depois de 20 sessões ou mais, o caderno fica feio. As entradas começam a se contradizer. Datas relativas como "ontem" param de fazer sentido. Dicas de depuração antigas ainda apontam para arquivos que foram deletados em uma refatoração. O que deveria ser uma memória útil vira ruído de fundo que confunde Claude.

Ganho rápido: Veja se o Auto Dream está ativo na sua instalação. Abra qualquer sessão do Claude Code e execute /memory. Procure "Auto-dream: on" no seletor. Se a flag estiver lá, Claude já está organizando seus arquivos de memória entre sessões em segundo plano.

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

Viu o toggle e está ativado? Ótimo. De vez em quando, Claude percorre os arquivos de memória do projeto, descarta o que ficou obsoleto, corrige contradições, e reorganiza o resto. Ainda sem o toggle? Continue lendo. Um acionamento manual ainda funciona.

Por Que Chamar de Dreaming? O Ângulo do Sono REM

O nome não foi escolhido por acidente. A analogia realmente se encaixa.

Seu cérebro absorve input bruto o dia todo e o armazena como memória de curto prazo. O sono REM então passa pelos eventos do dia, mantém as conexões que importaram, descarta o que não importou, e arquiva o resto no armazenamento de longo prazo. Economize no REM e você terá dificuldade em formar memórias duradouras. A informação chega mas nunca é consolidada.

A memória automática faz o papel do cérebro acordado do Claude. Ela anota as coisas enquanto trabalha: padrões de depuração, comandos de build, decisões de arquitetura, seus jeitos. Cada sessão acumula mais entradas. Mas sem uma passagem de limpeza, essas notas ficam bagunçadas da mesma forma que uma memória de curto prazo não consolidada. Contradições antigas persistem. Entradas desatualizadas nunca saem. O sinal se afoga no ruído a cada sessão.

Auto Dream faz o papel do REM. Ele olha o que a memória automática coletou, mantém as partes que ainda valem a pena, limpa qualquer coisa vencida, e reformata o resto em arquivos de tópico organizados com um índice limpo. Sem ele, Claude Code estava basicamente funcionando sem dormir. Notas continuavam se acumulando. A limpeza nunca chegava.

As Quatro Fases de um Ciclo de Dream

Auto Dream percorre uma rotina de quatro fases toda vez que executa. Cada fase tem seu próprio trabalho, e juntas transformam uma pilha dispersa de notas de sessão em conhecimento de projeto organizado.

Fase 1: Orientação

Claude abre o diretório de memória e cataloga o que já está lá. Ele lê MEMORY.md (o índice), olha a lista de arquivos de tópico, e esboça onde as coisas estão no momento.

A pergunta que essa fase responde: "O que eu já sei, e como está arquivado?"

Fase 2: Coletar Sinal

Em seguida, Auto Dream vasculha seus transcritos de sessão (aqueles arquivos JSONL que Claude mantém localmente para cada sessão). Ler cada um do início ao fim está fora de cogitação. Em um projeto com centenas de sessões, isso seria absurdo em tokens e tempo. A passagem é estreita. Ela caça apenas padrões específicos:

• Correções do usuário: Pontos onde você disse ao Claude que ele estava errado ou o direcionou para um novo caminho
• Salvamentos explícitos: Quando você disse "lembre disso" ou "salve na memória"
• Temas recorrentes: Padrões que apareceram em muitas sessões
• Decisões importantes: Decisões de arquitetura, escolhas de ferramentas, mudanças de fluxo de trabalho

Essa passagem estreita é deliberada. Ler 500 transcritos inteiros queimaria tokens por quase nada de novo. Consultas no estilo grep extraem os bits de alto sinal sem o desperdício.

Fase 3: Consolidação

Esse é o evento principal. Claude incorpora novas informações em arquivos de tópico existentes e faz a manutenção crítica:

• Datas relativas são reescritas como datas absolutas. "Ontem decidimos usar Redis" vira "Em 2026-03-15 decidimos usar Redis." Isso evita confusão de timing conforme as memórias envelhecem.
• Fatos contraditórios são deletados. Mudou de Express para Fastify há três semanas? A entrada antiga "API usa Express" desaparece.
• Memórias obsoletas são removidas. Notas de depuração apontando para um arquivo que foi apagado em uma refatoração não servem para nada. Fora.
• Entradas sobrepostas são mescladas. Três sessões que sinalizaram a mesma peculiaridade de comando de build se condensam em uma única nota limpa.

Fase 4: Podar e Indexar

A última fase foca no MEMORY.md. Esse arquivo é mantido abaixo de 200 linhas porque 200 é o limite para o que é carregado na inicialização. A Fase 4 atualiza MEMORY.md para que espelhe o estado atual dos arquivos de tópico:

• Remove links para arquivos de tópico que não existem mais
• Adiciona ponteiros para novos arquivos de tópico criados durante a consolidação
• Corrige qualquer discrepância entre o índice e o que os arquivos realmente dizem
• Reordena entradas por relevância e atualidade

Arquivos de tópico que não precisaram de edições na consolidação são deixados em paz. Auto Dream não reescreve o mundo em cada execução. As mudanças são cirúrgicas.

O System Prompt Completo

Aqui está o system prompt real que alimenta o Auto Dream. Isso é o que Claude recebe quando um ciclo de dream começa:

# 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.

Alguns detalhes desse prompt merecem destaque. Ele diz explicitamente ao Claude para fazer grep de forma estreita e ficar longe de leituras completas de transcritos. Ele mantém MEMORY.md no teto de 200 linhas. E diz ao Claude para corrigir contradições no arquivo de origem, e não apenas apontá-las. O prompt tem opiniões fortes sobre como a memória deve ser, o que explica por que o resultado sai consistentemente organizado.

Quando um Ciclo de Dream Começa

Duas coisas precisam ser verdadeiras ao mesmo tempo para que a consolidação execute:

1. Pelo menos 24 horas se passaram desde a consolidação anterior
2. Mais de 5 sessões aconteceram desde a consolidação anterior

Ambas as condições são obrigatórias. Uma sessão maratona de dois dias não vai acionar o Auto Dream (o contador de sessões é muito baixo). Dez sessões rápidas em duas horas também não vão acioná-lo (tempo insuficiente). A dupla condição evita que projetos silenciosos acionem limpezas inúteis e garante que os ativos se mantenham organizados.

Para ter uma noção de escala: em uma execução observada, Auto Dream processou 913 sessões de memória em aproximadamente 8 a 9 minutos. Não é de graça, mas o trabalho acontece em segundo plano, então você nunca sente o custo.

Garantias de Segurança

Auto Dream roda dentro de guardrails reais. É difícil cometer acidentes.

O código do projeto fica apenas para leitura. Dentro de um ciclo de dream, Claude só pode escrever em arquivos de memória. Código-fonte, configuração, testes, e o resto dos seus arquivos de projeto estão fora dos limites. O processo de dream fica isolado no diretório de memória.

Um arquivo de lock bloqueia sobreposições. Tem duas instâncias do Claude Code abertas no mesmo projeto? Apenas uma pode rodar Auto Dream por vez. Um arquivo de lock impede que duas execuções de consolidação se conflitem, o que de outra forma causaria conflitos de merge nos arquivos de memória.

Roda em segundo plano. Auto Dream não bloqueia sua sessão nem faz você esperar. Você continua trabalhando no Claude Code enquanto ele roda. A consolidação acontece no seu próprio processo.

Acionando um Dream Manualmente

Esperar pelo acionamento automático é opcional. Se você sabe que a memória precisa de limpeza (digamos, logo após uma grande refatoração), você pode forçar uma consolidação.

O comando /dream existe mas ainda não chegou a todas as contas. Enquanto você espera, basta dizer ao Claude o que você quer:

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

Claude entende a intenção e percorre o mesmo fluxo de quatro fases. Útil após grandes mudanças no projeto, quando uma memória atualizada importa e esperar pelo próximo ciclo automático é lento demais.

Antes e Depois: Uma Consolidação Real

Aqui está como um diretório de memória típico pode se parecer nos dois lados de um ciclo de dream.

Antes (Bagunçado, 30+ Sessões Acumuladas)

~/.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

Depois (Consolidado)

~/.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

O arquivo random-notes.md sumiu. Seu conteúdo foi incorporado em arquivos de tópico relevantes ou removido por estar obsoleto. MEMORY.md encolheu de 280 linhas para 142, voltando abaixo do limiar de inicialização de 200 linhas. Contradições estão resolvidas. Datas são absolutas.

Auto Memory vs Auto Dream: Duas Camadas de Um Sistema

Esses dois recursos trabalham juntos, não em oposição. Pense neles como a camada de coleta e a camada de manutenção de uma única configuração de memória.

Memória automática sem nada limpando depois é como um anotador que nunca folheia o caderno de volta. O inverso também vale: sem nada escrevendo novas notas, um ciclo de dream não tem nada para trabalhar. Você quer os dois rodando.

Quatro Sistemas de Memória: O Quadro Completo

Com essa nova camada, Claude Code tem quatro mecanismos de memória distintos. Veja como o conjunto completo se encaixa, complementando a tabela do deep-dive de memória automática:

A configuração mais forte roda as quatro. CLAUDE.md carrega as regras que você controla. Memória automática captura o que Claude aprende no trabalho. Memória de sessão carrega threads de conversa entre reinicializações. E o ciclo de dream mantém esse conhecimento acumulado atual, preciso e organizado.

Dicas Práticas

Deixe a automação cuidar da maioria dos projetos. Os gates padrão (24h mais 5 sessões) se encaixam bem no desenvolvimento ativo. Sem necessidade de babysitting.

Force um dream logo após uma grande refatoração. Renomeou metade do seu codebase? Trocou de framework? Reformulou sua API? Acione um ciclo manual. Entradas antigas vão confundir mais do que ajudar até serem reconciliadas.

Dê uma olhada no resultado de vez em quando. Depois que um ciclo de dream termina, relance o MEMORY.md. Auto Dream é bom, mas não é perfeito. Uma escolha de consolidação pode te incomodar. Os arquivos são markdown simples. Edite como quiser.

Combine com boa higiene de contexto. Um ciclo de dream mantém seus arquivos de memória limpos, mas o contexto de sessão ativa ainda é seu para gerenciar. Arquivos mais limpos significam que Claude carrega menos lixo na inicialização, o que deixa mais espaço para trabalho real na janela de contexto.

Próximos Passos

• Coloque o CLAUDE.md em ordem primeiro se ainda não fez isso. Um ciclo de dream consolida a memória automática, mas CLAUDE.md permanece a fonte de verdade de maior prioridade.
• Leia sobre memória automática para ver exatamente o que Claude está capturando durante as sessões, que é a matéria-prima com que Auto Dream trabalha.
• Confira a memória de sessão para continuidade em nível de conversa entre sessões de trabalho.
• Veja context engineering para entender como todos esses sistemas de memória somam a uma estratégia deliberada de contexto.
• Acompanhe o changelog do Claude Code para atualizações do sistema de memória, incluindo quando Auto Dream chegar ao seu nível de plano.
• Novo no Claude Code? Siga o guia de instalação para configurar no macOS, Windows ou Linux antes de mexer na configuração de memória.

Auto Dream é a peça que transforma a memória do Claude de uma pilha crescente de notas em uma base de conhecimento viva e mantida. Memória automática coleta a matéria-prima. Auto Dream molda isso em algo que Claude pode realmente usar. O efeito líquido é um Claude que não só lembra mais com o tempo, mas lembra melhor.