Como manter o Claude Opus 5.5 no trilho em sessões longas de trabalho

Fala aí, beleza? Sabe aquela sessão que começa afiada, o Claude acerta os três primeiros arquivos de primeira e você já se imagina entregando a feature antes do almoço?

Três horas depois ele refaz uma decisão que já estava fechada, cita um trecho de arquivo que você editou duas vezes desde então e pergunta algo que você respondeu no começo da conversa

A sensação é de queda de qualidade do modelo

Na prática, quase sempre é condução de sessão. O Claude Opus 5.5 é o modelo Opus atual da Anthropic, lançado em 22 de setembro de 2026, e é o padrão do Claude Code nos planos por assinatura. Segundo a comunicação de lançamento, ele trabalha 3,3x mais tempo por prompt, com mais de 40% mais chamadas de modelo por prompt

Ou seja: ele fica MUITO mais tempo dentro da mesma tarefa sozinho

E aí tudo que é tática de condução (onde a decisão mora, quando você fecha etapa, quando recomeça a conversa) passa a pesar mais do que pesava antes 🙂

O que você precisa antes de começar

Nada de PC da Nasa aqui, só o básico no lugar:

• Claude Code instalado e um projeto real aberto (não dá pra treinar condução de sessão longa em projeto de brinquedo, o contexto nunca enche)
• Acesso ao Opus 5.5: ele é o padrão do Claude Code em Pro, Max, Team, Enterprise e contas de API. No plano gratuito não tem acesso
• Permissão de escrita no diretório, porque você vai criar ./CLAUDE.md ou ./.claude/CLAUDE.md

E três coisas que é bom saber de antemão, porque mudam a forma de trabalhar:

Contexto de 1 milhão de tokens e saída máxima de 128 mil tokens. Espaço é bastante, e é justamente por isso que a sessão vira maratona sem você perceber

Pensamento adaptativo sempre ligado. No Opus 5.5 isso não é um botão que você liga, já vem ativo

Effort padrão medium. No Opus 5 o padrão era high, no 5.5 é medium. Segura essa informação, ela volta no passo 5

Passo a passo: conduzindo uma sessão longa sem perder o fio

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

1. Crie a base de memória com /init e refine com /memory

O /init gera um CLAUDE.md inicial no projeto, e o /memory serve pra refinar e organizar essa memória. O arquivo pode ficar em ./CLAUDE.md ou em ./.claude/CLAUDE.md

E aqui vale uma parada pra separar duas coisas que vivem juntas no Claude Code: a memória manual, que é o CLAUDE.md escrito por você, e a memória automática, que são notas que o próprio Claude escreve a partir das suas correções e preferências, guardadas no MEMORY.md

A auto memory vem ligada por padrão, e as primeiras 200 linhas ou 25KB do MEMORY.md, o que vier primeiro, são carregadas no início de cada sessão

O /memory é a porta das duas: é por ali que você refina e organiza o conteúdo, e é por ali que fica o toggle da memória automática (que grava autoMemoryEnabled em ~/.claude/settings.json)

Ou seja: as suas regras de projeto você escreve no CLAUDE.md, as notas que o Claude tira sozinho ficam no MEMORY.md, e o mesmo comando dá acesso aos dois

O que entra ali, segundo a própria documentação de memória: comandos de build e teste, padrões de código, decisões arquiteturais, convenções de nomes e fluxos comuns

/init
/memory

O erro comum deste passo: deixar a decisão só no chat. Você explica no prompt que o projeto usa uma convenção X, o Claude obedece por duas horas, e depois a conversa é resumida. Chat é volátil, arquivo não é

2. Confirme que a memória carregou de verdade

Rode /context e olhe a lista em Memory files. Se o seu arquivo não aparece ali, ele não está valendo, e você vai passar a sessão inteira achando que o Claude leu suas regras

/context

Como funciona o carregamento? Os arquivos CLAUDE.md e CLAUDE.local.md que estão na hierarquia acima do diretório de trabalho são carregados na inicialização. Os de subpastas carregam sob demanda, quando o Claude lê arquivos daquelas pastas

O erro comum deste passo: escrever a regra dentro de uma subpasta e esperar que ela valha desde o primeiro prompt. Ela só entra quando o Claude toca naquela pasta

3. Registre a decisão no momento em que ela é tomada

Esse é o hábito que separa sessão longa produtiva de sessão longa frustrante

Quando a compactação acontece, pedidos do usuário e trechos de código importantes são preservados, mas instruções detalhadas do início da conversa podem ser perdidas no resumo

Já o CLAUDE.md da raiz do projeto sobrevive: o Claude Code relê o arquivo do disco e reinjeta na sessão

Sacou a assimetria? Decisão no chat é candidata a sumir, decisão no arquivo volta sozinha

O erro comum deste passo: deixar o registro pro fim do dia. Aí você já não lembra se a escolha foi "repository sempre retorna entidade" ou "repository pode retornar DTO", e a decisão nasce errada no arquivo

4. Avance por progresso incremental e feche cada etapa com resumo verificável

A documentação de prompting orienta que o Claude mantém orientação em sessões estendidas focando em progresso incremental, avançando em poucas coisas por vez em vez de tentar tudo de uma vez

Então não é "implemente o módulo de pagamentos", é uma fatia por vez, com fechamento

E fechamento, aqui, significa uma coisa bem concreta: ao final da etapa você pede a lista de arquivos tocados e os comandos de teste que foram rodados, e confere no repositório. Se ele diz que alterou três arquivos, o git status tem que concordar

git status
git diff --stat

Não existe formato oficial de "resumo de handoff" documentado pela Anthropic, então trate isso como rotina sua, não como receita da casa. A parte que importa é a verificação, não o template

O erro comum deste passo: aceitar o resumo como se fosse log. Resumo é relato, git diff é fato

5. Ajuste o esforço quando a natureza da etapa muda

Lembra do effort padrão medium que eu pedi pra você segurar lá nos pré-requisitos? Chegou a hora dele. No Opus 5 o padrão era high, no 5.5 é medium, então etapa que pede mais cabeça não vem turbinada de fábrica, quem ajusta é você

O comando /effort muda o nível de esforço no meio da sessão. E tem um detalhe bom no Opus 5.5: essa troca preserva o cache (com chave de API ou assinatura)

/effort
/model

O /model troca de modelo mid-session. E existe a configuração opusplan, que usa Opus durante o plan mode e Sonnet durante a execução

É um desenho que faz sentido: pensar arquitetura é um trabalho, aplicar vinte arquivos seguindo o plano é outro

O erro comum deste passo: rodar a sessão inteira no mesmo ajuste e culpar o modelo quando a etapa pedia outra coisa

6. Vigie a ocupação do contexto e calibre a compactação

O /context mostra o que está ocupando espaço na janela de contexto. Vale olhar de tempo em tempo, não só quando o negócio já travou

A compactação automática acontece quando você se aproxima do limite: primeiro o Claude Code limpa saídas de ferramentas mais antigas, depois resume a conversa se ainda for necessário

E você tem controle sobre isso em três níveis:

/compact focus on the API changes
/autocompact 500k

No CLAUDE.md você pode adicionar uma seção Compact Instructions pra dizer o que deve ser preservado. O /compact aceita um foco, como no exemplo acima. E o /autocompact com uma contagem de tokens define o quanto o contexto pode encher antes da compactação automática

Pra scripts e ambientes de nuvem existe a variável de ambiente CLAUDE_CODE_AUTO_COMPACT_WINDOW

Tome cuidado com a precedência: ela ganha de comando, flag e setting. Se ela estiver definida, o /autocompact passa a apenas reportar o override, e você fica achando que configurou algo que não configurou

Se você ainda está na dúvida entre esticar a conversa ou começar de novo, esse papo de continuar com /compact ou zerar com /clear merece uma leitura à parte

O erro comum deste passo: descobrir a compactação só depois que ela aconteceu

7. Recomece no momento certo

Recomeçar não é desistir, é higiene

/clear
/rewind
claude --continue
claude --resume
/branch

O /clear reseta a conversa para contexto vazio, mantendo a memória do projeto, e a conversa anterior continua salva em disco. Ou seja: você não perde nada, só para de arrastar peso morto

O /rewind (ou Esc duas vezes com o campo de entrada vazio) abre o menu de rewind, com quatro opções: restaurar código e conversa, só a conversa, só o código, ou resumir a partir daquele ponto

Pra retomar, claude --continue abre a mais recente do diretório e claude --resume deixa você escolher da lista ou passar o ID. Dentro de uma sessão em execução existe o /resume

E se você quer testar um caminho sem sujar o histórico, --fork-session ou /branch copiam o histórico para um novo ID e deixam o original intacto

O erro comum deste passo: insistir na mesma conversa por apego, porque "ele já sabe o contexto". Depois de duas compactações, o que ele sabe é o resumo do resumo

Como detectar que o Claude passou a responder com base em suposição antiga

Aqui está a parte que quase ninguém treina: perceber o desvio ANTES de gastar meia hora corrigindo código errado

A resposta curta é essa: o Claude está trabalhando com suposição antiga quando o que ele descreve não bate mais com o que está no disco, ou quando ele reabre uma discussão que vocês já fecharam

Na prática isso aparece em quatro sinais bem repetidos, cada um com uma causa diferente e uma saída diferente

Se liga nos quatro:

Ele cita um arquivo com conteúdo que já mudou

Sintoma: o Claude descreve uma função que não existe mais naquele formato, ou sugere um ajuste que você já fez

Causa: a leitura que ele tem na conversa é antiga. E logo após a compactação, o Claude Code relê até cinco dos arquivos lidos ou editados na sessão, escolhendo os modificados mais recentemente. Se o arquivo em questão não estava nesse grupo, ele ficou com a versão velha na cabeça

Solução: peça releitura explícita do arquivo antes de continuar. Custa um prompt, economiza um desastre

Como prevenir: sempre que você editar um arquivo por fora (na mão, no editor, via outra ferramenta), avise na sessão

Uma decisão já descartada volta a aparecer

Sintoma: aquela abordagem que vocês discutiram e recusaram na primeira hora reaparece como sugestão

Causa: a instrução detalhada do começo se perdeu no resumo. A documentação é explícita: instruções detalhadas do início da conversa podem ser perdidas na compactação

Solução: escreva a decisão no CLAUDE.md (que é relido do disco) e use a seção Compact Instructions pra proteger o que não pode sumir

Como prevenir: decisão arquitetural nunca mora só no chat. Nunca 🙂

A resposta fica genérica, ou repetitiva, perto do limite

Sintoma: respostas longas que não avançam, repetição do que já foi dito, menos precisão nos arquivos

Causa: contexto ocupado por saídas de ferramentas antigas, logs gigantes, resultados de busca que já não servem pra nada

Solução: rode /context pra ver quem está comendo o espaço, e depois /clear (se a tarefa virou outra) ou /compact com foco (se você precisa continuar de onde estava)

Como prevenir: olhar o /context no meio da sessão, não no fim

Ele insiste num comportamento que você já corrigiu

Sintoma: você corrige a mesma coisa pela terceira vez, em sessões diferentes, e ele volta a fazer

Causa: pode ser a memória automática. Ela vem ligada por padrão e são notas que o Claude escreve a partir das suas correções e preferências. As primeiras 200 linhas ou 25KB do MEMORY.md, o que vier primeiro, são carregadas no início de cada sessão. Se alguma nota ali capturou uma preferência sua de forma torta, ela volta toda santa sessão

Solução: revise pelo /memory. Se quiser desligar, o próprio /memory tem o toggle, que grava autoMemoryEnabled em ~/.claude/settings.json

Como prevenir: tratar a memória automática como código: lê, revisa, ajusta

O que a prática mostra na rotina do Claude Code

Aqui eu falo por mim, e só do que testei

Quando gravei o vídeo sobre o Opus 4.7 eu passei algumas horas com ele dentro do Claude Code pra formar uma primeira impressão. Pedi, num único prompt, um clone do Trello com UI moderna e animações

O visual ficou bonito

Agora, algumas interações não funcionaram direito e a tela dava reload toda vez que uma tarefa era concluída. Em um momento do teste a interface girou e o trabalho foi perdido

Mesmo assim eu achei legal pra ter sido feito com um prompt só

E é exatamente aí que o assunto deste post entra. Prompt único é diversão, não é trabalho. O resultado que mais me interessou nos testes foi um blog com autenticação (visualização de posts, troca de tema, login de admin, criação de post em markdown e publicação), também num prompt só, e aquilo saiu bem

Mas eu também fiz uma dashboard pra avaliar UI, e fui honesto na hora de avaliar: é um tipo de projeto muito padronizado, então não dá pra saber se o resultado bom veio de mérito do modelo ou de dados de treinamento repetidos

Ou seja: quanto mais específico e mais longo o trabalho, menos você pode contar com sorte e mais você depende de condução

Minha opinião sobre o 4.7 foi de um modelo honesto e competente, mas nada revolucionário, algo como um "Opus 4.6.1". E pesando custo, qualidade e sessões mais longas de trabalho, eu disse que hoje escolheria o Codex pra vibe coding, embora com alguns prompts extras eu ache que o Opus chegue a resultados parecidos

Repara na frase: com alguns prompts extras

É isso que o CLAUDE.md faz de graça e em todas as sessões

Sigo usando o Opus no dia a dia, porque já pago uma assinatura que cobre 5x mais uso e isso resolve as minhas necessidades

No vídeo acima eu mostro o teste rodando dentro do Claude Code, onde a coisa quebra e onde ela entrega. Vale ver justamente pra calibrar expectativa de prompt único contra trabalho de sessão longa

Quando recomeçar a conversa e quando continuar a mesma sessão

A pergunta prática é sempre essa: continuo aqui ou começo do zero?

Detalhando os dois que mais geram dúvida:

Virada de tarefa no mesmo projeto. Terminou o módulo de autenticação e vai começar o de relatórios? /clear. Não existe motivo pra arrastar duzentas mensagens sobre JWT pra dentro de uma conversa sobre agregação de dados

Voltar no dia seguinte. O --continue pega a mais recente do diretório e o --resume deixa escolher da lista ou passar o ID. Se você também quer saber como retomar de onde parou quando a coisa cai no meio da tarefa, tem post separado sobre isso

E o --fork-session é subestimado. Quer testar "e se a gente usasse fila em vez de cron?" sem contaminar a conversa boa? Bifurca, testa, descarta o galho se não prestar

Colocando em prática hoje

Qualidade no fim de uma sessão longa não é sorte, é rotina

O Opus 5.5 trabalha mais tempo por prompt, tem 1 milhão de tokens de contexto e 128 mil de saída máxima. Isso significa que ele aguenta mais trabalho sozinho, e significa também que o custo de uma decisão mal registrada demora mais pra aparecer

O próximo passo é pequeno e dá pra fazer agora:

1. Rode /init no projeto que você está mexendo
2. Escreva as três primeiras decisões arquiteturais no CLAUDE.md, com uma linha cada
3. Rode /context e confirme que o arquivo aparece em Memory files

Pronto, você acabou de tirar as suas regras de um lugar volátil e colocar num lugar que é relido do disco

Na próxima maratona você vai sentir a diferença 😀

Até o próximo post!