Claude Code 1M Context: Como Evito o Context Rot

Claude Code 1M Context: Como Evito o Context Rot

O contador da sessão marcava 612.000 tokens. O Opus 4.7 estava rodando havia quase quatro horas. Já havia lido 38 arquivos, refatorado uma camada de serviço em Laravel, escrito testes, e agora me orientava, com confiança, a atualizar um método em uma classe que eu mesmo havia deletado noventa minutos antes.

Não foi alucinação. Estava deletada. Pelo próprio Claude. Com uma chamada de ferramenta que eu podia revisar rolando para cima na mesma sessão.

Fiquei ali encarando o terminal — café frio, o cursor piscando à espera de uma correção que teria colocado uma regressão no ar — e senti o mesmo calafrio que todo power user do Claude Code conhece. O modelo não estava ficando mais burro. Ele estava se afogando. Em algum ponto entre o token 300k e o token 600k, o contexto passou silenciosamente de ativo a passivo.

Essa é a parte que ninguém coloca no texto de marketing da janela de contexto de 1M do Claude Code. A janela é real. Funciona. Eu tenho provas. Mas “1 milhão de tokens” não é o mesmo que “1 milhão de tokens de raciocínio claro, focado e confiável”. O abismo entre essas duas coisas é onde vivi a maior parte dos meus últimos debugs.

Nos últimos 30 dias, queimei sessões de Opus 4.7 em Max 20x suficientes para mapear exatamente onde a degradação do contexto começa, o que a desencadeia e os cinco movimentos específicos que mantêm sessões longas do Claude Code afiadas em vez de frouxas. Nada disso é teoria. Tudo veio de builds reais quebrados antes.

Se você já viu o Claude esquecer uma restrição definida na mensagem três, este artigo é para você.

O Que “1M Context” Realmente Significa no Claude Code Hoje

Uma breve organização, porque os números das versões importam e a maioria dos posts costuma errar nisso.

A janela de 1 milhão de tokens no Claude Code não chegou com o Opus 4.5. O Opus 4.5 (novembro de 2025) atingia no máximo cerca de 250 mil. A janela de 1M foi lançada com o Claude Opus 4.6 em 5 de fevereiro de 2026 — e, em seguida, ficou disponível de forma geral no Claude Code em 13 de março de 2026 para o Opus 4.6 e também para o Sonnet 4.6. O modelo atual, enquanto escrevo, é o Opus 4.7, lançado em 16 de abril de 2026, que mantém o mesmo limite de 1M.

O acesso ainda depende do seu plano:

• Max, Team, Enterprise — 1M é automático com o Opus 4.6/4.7, sem custo extra, sem necessidade de ativar nada
• Pro (US$20/mês) — é preciso optar pela ativação digitando /extra-usage dentro do Claude Code, e os tokens além da janela padrão são descontados dos créditos de uso extra
• API — o preço para contexto acima de 200k usa a faixa de long-context; consulte a página de preços atual da Anthropic antes de criar um fluxo que dependa da tarifa econômica

A própria janela de contexto inclui tudo o que o modelo consegue enxergar ao mesmo tempo: o prompt do sistema, seu CLAUDE.md, histórico da conversa, todos os arquivos lidos pelo Claude com a ferramenta Read, cada saída de ferramenta gerada, todos os resultados de Glob/Grep e a mensagem atual que você acabou de digitar. Tudo isso conta. Tudo compete por atenção.

Esse último detalhe é o ponto principal. Guarde isso.

O Número Que Ninguém Cita: O Context Rot Começa aos 300k, Não em 1M

A promessa de marketing de qualquer modelo de grande contexto sugere uma curva de desempenho plana — que o token 999.000 é tão útil quanto o token 9.000. Não é. Existe um nome publicado para o que realmente acontece, e ele merece estar no vocabulário de todo usuário do Claude Code.

Context rot é a degradação mensurável do desempenho do modelo à medida que o contexto de entrada aumenta. Não é um bug específico da Anthropic. O estudo da Chroma de 2025 testou 18 modelos de ponta — GPT-4.1, Claude Opus 4, Gemini 2.5, todos eles — e encontrou context rot em cada incremento de tamanho de entrada que mediram. A própria equipe de engenharia da Anthropic já escreveu abertamente sobre isso, tratando o contexto como um "orçamento finito de atenção" que se esgota a cada novo token, do mesmo modo que a memória operacional humana.

Aqui vai o número prático que importa para o Claude Code: a degradação começa a ser sentida por volta dos 300.000 a 400.000 tokens. Isso representa cerca de 30–40% do limite de 1M — bem antes do número em destaque sugerido. No benchmark MRCR multi-needle retrieval, o Opus 4.6 ainda atinge 76% de acurácia com o contexto completo de 1M, o que é excelente para um modelo de fronteira. Mas “76% de recuperação precisa” é uma propriedade assustadora quando você permite que um agente edite código de produção sem supervisão. Os outros 24% têm seu nome escrito neles.

Na prática, o context rot raramente se manifesta como uma alucinação dramática e fácil de identificar. É mais sutil. Mais silencioso. São os quatro modos de falha abaixo — e, assim que você souber nomeá-los, poderá caçá-los.

Os Quatro Modos de Falha Que Agora Nomeio em Voz Alta

Antes de ter vocabulário para isso, cada momento de "Claude está agindo estranho" parecia o mesmo problema vago. Agora, diagnostico em segundos. Cada um exige uma solução diferente.

1. Poluição de Contexto

Poluição é informação irrelevante abafando o sinal. Você rodou um Grep que retornou 800 correspondências. Deixou o Claude ler um arquivo de log com 4.000 linhas “por precaução”. Anexou todo o diretório de types de node_modules porque não tinha certeza de qual arquivo continha o tipo. Nada disso é errado isoladamente. Tudo isso junto transforma a atenção do Claude em um caldo.

O modelo não sabe o que você considera relevante. Ele trata cada token como potencialmente crucial. Quanto mais ruído você coloca, mais cognição é gasta reavaliando esse ruído.

Sinal clássico: Claude começa a referenciar arquivos que você nem lembrava ter enviado.

2. Deriva de Objetivo

Deriva de objetivo é a erosão lenta da intenção original. Você iniciou a sessão com “reescreva o middleware de autenticação para suportar OAuth 2.1, mantenha todos os fluxos JWT existentes funcionando, não mexa no modelo de usuário.” Três horas depois, após o Claude ler 22 arquivos, corrigir oito erros de lint não relacionados e refatorar um helper de log, você pede para adicionar um novo claim ao payload do JWT e ele modifica o modelo de usuário.

Ele não ignorou sua restrição. A restrição apenas se deteriorou. Com 400k tokens entre a instrução original e o turno atual, a razão sinal-ruído do system prompt colapsou.

Sinal clássico: Claude faz o correto para o pedido imediato, mas viola uma regra do briefing original.

3. Corrupção de Memória

Este foi o que me assustou ao ponto de escrever este post. Corrupção de memória acontece quando o modelo interno do agente deriva da realidade. O arquivo que o Claude acha que existe em app/Services/UserService.php foi excluído no turno 47. O Claude ainda está usando a versão que armazenou na memória de trabalho. Você lê o plano, tudo parece coerente, aprova — e o patch cai num arquivo que não existe mais ou, pior, sobre uma versão desatualizada de um arquivo existente.

Flagrei o pior caso disso em um refactor do Multica: o Opus tinha alterado um service três vezes durante a sessão e, na quarta alteração, gerou um diff contra a primeira versão do arquivo. Os patches intermediários estavam no histórico da conversa. Eles só não estavam sendo considerados.

Sinal clássico: Chamadas de ferramentas referenciam um estado que não corresponde ao filesystem atual.

4. Inexatidão nas Decisões

Inexatidão nas decisões é o imposto da inconsistência. No início da sessão, você decidiu “todos os erros neste service lançam DomainException e sobem; o handler faz log no Sentry.” Depois, já com o contexto profundo, o Claude escreve um novo método capturando tudo como \Exception, faz log com Log::error e retorna um 500.

O código não está errado. Só não é o seu código. Decisões diferentes, padrões contraditórios, nenhuma linguagem de design consistente.

Sinal clássico: Estilo de código e escolhas arquiteturais deixam de combinar com o restante da base, mesmo com Claude tendo lido o código todo.

Cada um desses modos tem uma solução. Nenhuma delas é "use um modelo menor". Todas dependem de como você gerencia a janela.

Os Cinco Passos Que Uso Todos os Dias

Quando uma sessão do Claude Code ultrapassa 300k tokens — ou quando identifico um dos quatro modos de falha acima — tenho cinco opções. O segredo está em saber qual escolher. Elas não são intercambiáveis.

Opção 1: Continuar (E Por Que Eu Quase Nunca Faço Isso)

A ação padrão. Apenas seguir em frente. A tentação existe porque você está “no fluxo” e os custos de mudar parecem altos.

Quase nunca escolho essa opção atualmente, a menos que esteja abaixo de 300k tokens E o trabalho seja superficial (apenas um arquivo, uma única preocupação). Daí pra frente, continuar é apostar — a cada nova interação, o risco de context rot aumenta. O custo de um erro grave ir para produção é muito maior do que o custo de pausar e redefinir o contexto.

Opção 2: Compactar, Mas Manualmente

/compact resume a conversa existente em um recapitulação mais curta e segue em frente. Em teoria, é uma borracha mágica contra o inchaço do contexto. Na prática, o autocompact — a versão disparada automaticamente ao atingir o teto da janela — não é confiável. A lógica de compactação do Claude prioriza as interações recentes e pode descartar silenciosamente contextos críticos anteriores: o briefing original, as decisões de arquitetura, as restrições da mensagem três.

Por isso, nunca deixo o autocompact rodar. Aciono o /compact manualmente, de forma proativa, por volta dos 300k tokens, e dou instruções explícitas sobre o que manter:

/compact Preserve: (1) o briefing original no início da sessão,
(2) todas as decisões arquiteturais tomadas nos turnos 1–15,
(3) a lista de arquivos já modificados e por quê,
(4) qualquer restrição que comece com “NÃO” ou “DEVE”.
Remover: corpos de saída de ferramentas, resultados intermediários do Grep, leituras de arquivos que não precisaremos mais.

Essa instrução muda radicalmente a qualidade da compactação. Você sai de “resuma o chat” para “produza um documento de repasse estruturado”. É uma grande diferença.

Opção 3: Limpar e Recomeçar

/clear remove completamente o contexto. É a opção nuclear. E também a opção correta com mais frequência do que eu costumava imaginar.

Uso /clear sempre que vou mudar para um trabalho genuinamente não relacionado — terminei o refactor do auth e vou corrigir o webhook de cobrança. Não há benefício algum em carregar o contexto de autenticação para a sessão de billing, e os riscos são enormes (poluição, desvio, todos os problemas acima).

O erro comum com /clear é tratá-la como fracasso. Não é. Uma sessão nova e focada, com 12k tokens, supera facilmente uma sessão estagnada de 600k tokens com raciocínio nebuloso, todas as vezes.

Opção 4: Limpar + Salvar em JSON (Meu Padrão Para Trabalhos Complexos)

Este é o movimento que mais utilizo. Antes de limpar, peço para o Claude gerar um arquivo estruturado em JSON que capture o estado do trabalho, de modo que eu possa reabastecer uma nova sessão com ele. Algo como:

{
  "objective": "Migrar middleware de autenticação para OAuth 2.1 mantendo os fluxos JWT",
  "constraints": [
    "Não modificar app/Models/User.php",
    "Todos os novos endpoints devem manter o prefixo /api/v1",
    "Consumidores existentes de JWT devem continuar funcionando"
  ],
  "files_modified": [
    {"path": "app/Http/Middleware/Authenticate.php", "status": "complete"},
    {"path": "app/Services/Auth/OAuthHandler.php", "status": "in-progress"}
  ],
  "open_decisions": [
    "Estratégia de rotação de refresh token ainda a definir",
    "Precisamos confirmar se o formato JWT antigo recebe header de depreciação"
  ],
  "next_step": "Implementar a rotação de refresh token em OAuthHandler::refresh()"
}

Depois executo /clear, inicio uma nova sessão e a primeira mensagem é: “Leia .claude/state.json, confirme que entendeu o objetivo e as restrições atuais, então continue a partir do next_step.”

Esse repasse é infinitamente mais confiável do que qualquer /compact que já utilizei. A nova sessão começa com, no máximo, 15k tokens e sinal perfeito. Sem desvio. Sem memória corrompida. Sem restrições meio lembradas.

Opção 5: Sub Agentes Para Tudo Que For Sobrecarregar o Contexto

Sub Agentes são o escape do Claude Code para tarefas que despejariam grandes saídas de ferramentas no seu contexto principal. O agente atua em uma janela de contexto isolada, faz o trabalho e retorna apenas o resultado final para sua sessão principal.

O teste que uso mentalmente — e que o próprio time da Anthropic utiliza — é: “Vou precisar dessa saída da ferramenta novamente ou só da conclusão?”

Precisa apenas da conclusão? Sub agente. Exemplos:

• “Pesquise em toda a base de código todos os locais em que chamamos o gateway de pagamentos legado e reporte a lista de arquivos e linhas” — tarefa perfeita para sub agente. O resultado do Grep ocuparia 40k tokens no contexto principal. A lista final cabe em 200 tokens.
• “Leia estas 12 páginas de documentação e diga qual delas contém as informações sobre limites de taxa” — sub agente. As 12 páginas poluiriam o contexto. A resposta cabe em uma frase.
• “Rode a suíte de testes e reporte apenas as falhas com stack traces” — sub agente. Você não precisa das 8.000 linhas de saída dos passes.

Configuro esses sub-agentes corretamente em .claude/agents/, tornando a orquestração reproduzível. Na primeira vez que adaptei uma sessão de 90 minutos para usar sub agentes nas etapas intensivas de busca, o contexto principal caiu de 400k para 90k e o Opus permaneceu afiado durante todo o trabalho.

As Três Práticas que Silenciosamente Importam Mais que Qualquer Comando

Além das cinco opções, três hábitos fazem a maior diferença no dia a dia. Nenhum deles chama atenção.

Rewind ao Invés de Reenviar o Prompt

Quando o Claude toma uma decisão errada e você a corrige, essa decisão equivocada permanece para sempre no contexto. Três interações depois, você corrige outro erro relacionado. Na décima rodada, metade da conversa é trabalho real e metade é “não, não é isso, faça assim em vez disso”. A deterioração do contexto se acelera.

A alternativa mais limpa é rebobinar — voltar a conversa até antes da decisão ruim e reenviar um prompt inicial melhorado com o que você aprendeu. O Claude Code permite que você edite mensagens anteriores. Use este recurso. A sessão rebobinada fica drasticamente mais limpa, se compacta melhor e propaga menos erros posteriores.

Hoje, trato o terceiro “não, ainda não está certo” como um gatilho automático para rebobinar, e não para ficar corrigindo.

Recapitulações Periódicas Não São Opcionais

A cada 50–75k tokens de trabalho substantivo, pergunto: “Recapitule o objetivo atual, as restrições que acordamos e o trabalho já realizado até aqui.” Duas frases, no máximo.

Isso soa como desperdício. Na verdade, é o oposto. A recapitulação força o Claude a se reancorar no briefing, o que reduz drasticamente a deriva do objetivo nas interações seguintes. Também me dá uma forma rápida de perceber se a compreensão do Claude já desviou — se a recapitulação estiver errada, já sei que a deterioração do contexto começou e é hora de usar /compact ou /clear.

Considere recapitulações como a versão econômica da compactação. Compactação reestrutura a memória. Recapitulações reforçam.

Instruções Explícitas de Compactação Sempre Superam o Comportamento Padrão

Comentei sobre isso na Opção 2, mas vale destacar como uma regra própria. Se você deixar o /compact rodar sem instruções, estará confiando nos padrões do Claude para saber o que é essencial no seu trabalho. Muitas vezes, ele não sabe. A restrição que você escreveu na terceira mensagem é apenas texto para o sumarizador.

Sempre informe ao /compact o que deve ser preservado, o que pode ser descartado e como deve ser estruturada a saída. Trate isso como escrever uma documentação de repasse para um colega, e não como invocar um comando mágico.

Como Isso Funciona de Ponta a Ponta: Uma Sessão Real

Aqui está uma versão simplificada de como uma sessão longa no Claude Code realmente flui para mim agora, após um mês refinando esse ciclo:

1. Início da sessão — CLAUDE.md está enxuto, o briefing está na primeira mensagem, as restrições são explícitas. Contagem de tokens: ~5k.
2. Primeiros 200k tokens — trabalho direto. Não estou otimizando nada. Leitura de arquivos, escrita de código, execução de testes. O contexto está saudável.
3. Marco dos 300k — primeiro checkpoint. Peço um resumo. Confirma a direção. Nenhum /compact ainda, se o trabalho continua focado.
4. Marco dos 400k — segundo checkpoint. Se ainda estou no meio da tarefa, executo um /compact manual com instruções explícitas do que preservar e descartar. Contagem de tokens cai para ~80k. Sigo em frente.
5. Qualquer coisa que despejaria >20k de saída de ferramentas — subagente. Sempre.
6. Fim de um bloco definido de trabalho — escrevo um arquivo de estado JSON, uso /clear, abro uma sessão nova e reativo a partir do JSON. Essa transição me custa 3 minutos e me salva do acúmulo de context rot.
7. Primeiro loop do tipo "não, ainda não está certo" — pauso. Diagnostico qual dos quatro modos de falha está ocorrendo. Escolho a correção certa. Não fico repromptando no escuro.

É isso. Sem mágica. Sem ferramentas novas. Só uso disciplinado do que o Claude Code já oferece.

O resultado: agora rodo sessões produtivas no Claude Code que duram o dia inteiro no mesmo projeto, sem o modelo perder o rumo. Um mês atrás, eu não chegava nem à tarde de terça-feira sem uma cascata de alucinações.

O que eu fiz de errado nas primeiras três semanas

Eu devo a você a versão honesta de como cheguei a essas conclusões, porque gastei muito dinheiro até entender.

Assumi que um contexto maior era sempre melhor. Intencionalmente, incluía mais arquivos no contexto “para que o Claude tenha total visibilidade”. Errado. Cada arquivo irrelevante era um pequeno imposto a cada iteração seguinte. Menos é mais. Leia somente o necessário, não o que talvez seja útil.

Confiei no autocompact. Durante três semanas deixei ele rodar quando quisesse. O desvio era tão gradual que culpei a mim mesmo, meus prompts, a estrutura do projeto — qualquer coisa, menos o verdadeiro culpado. Na primeira vez em que desativei o autocompact e fiz compacção manual com instruções explícitas, a diferença foi gritante.

Evitei subagentes porque a orquestração parecia um peso extra. Estava errado sobre isso também. Configurar um subagente de busca ou um subagente de test-runner leva dez minutos uma única vez. Isso te poupa de despejar 50 mil tokens de ferramentas em toda sessão depois disso.

E tratei o /clear como derrota. Não é. Uma sessão limpa não é uma sessão fracassada. Uma sessão limpa é uma ferramenta. Use-a.

Perguntas Frequentes

Quando começa o context rot no Claude Code?

O context rot no Claude Code torna-se mensurável por volta de 300.000 a 400.000 tokens — aproximadamente 30–40% da janela de 1M. O desempenho não entra em colapso nesse ponto, mas desvios de objetivo, corrupção de memória e inconsistências de decisão tornam-se visivelmente mais prováveis. Considere 300k como seu primeiro checkpoint, e não 1M como limite máximo.

Devo usar /compact ou /clear no Claude Code?

Use /compact quando a tarefa atual ainda estiver ativa e o contexto recente for realmente necessário; use /clear ao mudar para um trabalho não relacionado ou quando o contexto estiver tão poluído que resumi-lo ainda deixaria ruído. Para trabalhos complexos em andamento, o padrão mais eficiente é salvar o estado em um arquivo JSON, /clear e reiniciar uma nova sessão a partir desse JSON.

A janela de contexto de 1M custa extra no Claude Code?

Nos planos Max, Team e Enterprise, a janela de contexto de 1M está incluída sem custo adicional para Opus 4.6 e Opus 4.7. No plano Pro (US$20/mês), é necessário ativar com /extra-usage e os tokens acima da janela padrão são cobrados dos créditos de uso extra. A precificação da API utiliza a faixa de long-context acima de 200k — verifique as tarifas atuais antes de construir um fluxo de trabalho baseado nessa premissa.

Qual é a diferença entre /compact e sub agents?

/compact resume a conversa existente na sua sessão atual para liberar tokens; sub agents impedem o acúmulo desde o início, rodando tarefas paralelas em suas próprias janelas de contexto isoladas e retornando apenas o resultado final. Use sub agents para tarefas cujo output da ferramenta você não precisa consultar repetidamente — buscas, análise de logs, execuções de teste.

Por que o Claude Code começa a alucinar em sessões longas?

Sessões longas no Claude Code alucinam devido ao context rot — à medida que a entrada cresce, o orçamento de atenção do modelo se dilui e restrições antigas, conteúdos de arquivos e decisões anteriores passam a ser subvalorizados. A solução não é uma janela maior, mas sim gerenciamento ativo: /compact manual com instruções claras, recapitulações periódicas, sub agents para tarefas de alto volume e handoffs /clear+JSON entre grandes blocos de trabalho.

Então: seu terminal está aberto. A sessão está em 280k tokens. O Opus 4.7 acabou de sugerir editar um arquivo que você tem 80% de certeza que deletou há uma hora.

O que você faz nos próximos 60 segundos?

Se sua resposta é "pedir para o Claude conferir de novo", você ainda está gerenciando contexto do jeito antigo. Se é "voltar à última interação limpa, salvar o estado em um arquivo JSON, /clear e reiniciar" — bem-vindo à versão do Claude Code que realmente escala para um dia completo de trabalho. A janela de 1M é real. A confiabilidade dentro dela depende de engenharia ativa.

Prefiro engenhar essa confiabilidade do que culpar o modelo.

Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Eu posso ajudar.

• Fiverr (projetos sob medida & integrações): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io