Claude Code 9h sem /clear: contexto apodreceu 3h

Rodei o Claude Code de manhã até a noite sem apertar /clear uma vez. Nove horas numa sessão só, misturando refatoração, teste e revisão de PR. Quando anoiteceu, o agente estava um funcionário diferente.

A janela ainda tinha espaço. Restavam uns 40% de tokens no medidor. O modelo era o mesmo. A máquina era a mesma. Mas os erros começaram no meio da tarde, e foi aí que caiu a ficha: o contexto estava apodrecendo antes da janela encher.

Este texto é o postmortem dessa jornada. Cinco sintomas concretos com o horário em que apareceram, e três correções que uso hoje pra segurar o esquecimento antes dele começar.

Por que a hora 3 dói mais que a hora 8

Você espera problema quando a janela lota. Faz sentido: 200 mil tokens virou muita coisa, algo tem que ceder. O que ninguém te avisa é que o desempenho começa a cair muito antes disso.

A pesquisa da Chroma sobre context rot mediu 18 modelos de fronteira e mostrou que a qualidade da saída degrada progressivamente à medida que o input cresce. Todos os modelos. Sem exceção. E o degrado começa em faixas bem abaixo do limite anunciado: por volta dos 50 mil tokens já dá pra ver.

Ou seja, “cabe” e “funciona” são duas perguntas diferentes. Eu tinha passado anos respondendo só a primeira.

Os 5 sintomas, com o horário em que apareceram

Anotei o log das mensagens durante o dia. Reli à noite. Os sintomas vieram nesta ordem.

Sintoma 1 — hora 2h50: releitura do mesmo arquivo, terceira vez. O agente abriu src/routes/auth.ts três vezes na mesma sessão. Duas releituras eram justificáveis (mudei o arquivo entre elas). A terceira não. Ele simplesmente esqueceu o que já tinha lido. Token consumido: umas 4 mil por releitura. Multiplique pelo resto do dia.

Sintoma 2 — hora 3h20: violação silenciosa do CLAUDE.md. Meu CLAUDE.md diz “testes com vitest, não jest”. Na hora 3h20 ele começou a escrever describe('...', () => { it(...) }) com import de @jest/globals. Quando eu apontei, ele pediu desculpa e reescreveu. Duas horas antes, ele mesmo tinha aberto o CLAUDE.md e citado a regra.

Sintoma 3 — hora 4h10: reversão de decisão fechada. De manhã, decidimos remover uma função parseDate legada. Nome removido, referências removidas, teste removido. Na hora 4h10 ele voltou com “por precaução, deixei um wrapper compatível”. Wrapper que reintroduzia a função inteira. Ele não tinha lembrança da conversa de manhã, mas o wrapper “fazia sentido no contexto atual”.

Sintoma 4 — hora 5h45: fixação numa pista velha. Debug de um bug de autenticação. Eu já tinha dito às 14h que a suspeita da política CORS estava errada. Às 15h45 ele voltou pra CORS por conta própria. Foi preciso repetir o descarte três vezes.

Sintoma 5 — hora 7h30: tom trocado. Do nada, no meio de um patch técnico, respostas com listas de bullet point ornamentadas, títulos com emoji, aquele estilo “artigo de LinkedIn”. Como se um outro agente tivesse assumido o teclado. Não assumiu. Era o mesmo agente, com o contexto tão embaralhado que ele já não sabia em qual “modo” estava.

Nenhum sintoma é catastrófico sozinho. Junte os cinco e o dia rendeu 40% menos do que rende com sessões curtas.

O padrão por trás dos 5

Isso não é um agente ruim. É um padrão previsível. O clássico Lost in the Middle de Liu et al., 2023 já tinha mostrado: quando o contexto cresce, o modelo dá mais peso ao início e ao fim, e o miolo vira barulho. Minhas decisões de manhã, na hora 5 da tarde, estavam exatamente no miolo.

Combinei isso com a taxonomia de falhas do meu livro sobre context engineering. Os cinco sintomas mapeiam nesses eixos:

• releitura do mesmo arquivo = Context Distraction (o agente perde foco no que já processou)
• violação silenciosa do CLAUDE.md = Context Poisoning (regra do topo diluída pelo volume no meio)
• reversão de decisão = Context Clash (duas decisões contraditórias coexistem)
• fixação na pista velha = Context Confusion (mistura de tópicos empurra pra hipótese descartada)
• tom trocado = colapso da persona por sobrecarga de exemplos misturados

Se você já leu o agente-ia-24-horas-incidentes-seguranca que publiquei aqui, o padrão é o mesmo: quanto mais tempo o agente roda sem intervenção, mais frágil fica a camada de contexto que dita o comportamento dele. Só que segurança é o incidente óbvio. O apodrecimento de contexto é o incidente que passa despercebido porque cada sintoma parece “só um errinho”.

As 3 correções que estão funcionando

Testei várias combinações nas semanas seguintes. Ficaram estas três, na ordem em que aplico.

Correção 1: /clear disciplinar a cada troca de tarefa. Regra dura: mudou o objetivo (de refatorar pra testar, de testar pra revisar PR), aperta /clear. Não importa se sobra 60% de janela. O contexto anterior polui a próxima tarefa mais do que ajuda. Nas primeiras semanas achei que ia perder tempo re-explicando. Não perdi. O CLAUDE.md carrega o essencial em 30 segundos, e o resto é a nova tarefa em si.

Correção 2: compact-ops como ponte quando /clear não cabe. Existe o caso em que a tarefa é longa e você não quer perder o rastro. Aí uso o skill /compact-ops (do meu setup público) pra salvar o estado antes de rodar /compact do próprio Claude Code. O compact nativo comprime, mas comprime sem saber o que você considera não-negociável. O compact-ops grava o “o que decidimos, o que descartamos, o que ainda é pra fazer” num arquivo persistente, e a próxima sessão pega isso na entrada. Dá pra parar às 18h e retomar de manhã sem começar do zero.

Correção 3: sub-agente pra trabalho de escopo fixo. Coisa como “roda o linter em todos os arquivos alterados e me traz os erros” não precisa da minha sessão principal. Delego pro sub-agente com prompt curto, saída definida, sem histórico. Ele fecha, devolve a resposta, e minha janela principal fica intacta. Isso derrubou uns 20% do consumo de tokens da sessão principal.

A ordem importa. Se você entrar direto na correção 2 sem fazer a 1 virar hábito, vai comprimir contexto sujo. Se pular a 3, sua janela vai continuar acumulando lixo operacional que nem precisava estar lá.

O que eu ainda erro

Duas coisas eu ainda erro toda semana.

Primeira: subestimo o custo de “só mais uma tarefinha nessa sessão”. Quatro tarefinhas depois, estou na hora 4 do dia sem ter apertado /clear uma vez. A vontade de não recomeçar é maior que a evidência de que recomeçar é mais barato.

Segunda: às vezes uso /compact do próprio Claude Code por preguiça, sem o compact-ops na frente. Comprime, sim. Mas quando volto à sessão duas horas depois, aquela decisão de manhã virou uma frase vaga que eu não confio mais. Prefiro /clear cru a /compact cego.

Se você reconhece qualquer um dos 5 sintomas na sua rotina, o problema quase certamente não é a capacidade do modelo. É o tempo que a janela ficou aberta. E isso, diferente de trocar de modelo, custa zero pra consertar. Só custa a disciplina de fechar antes de precisar.

Ligo aqui dois textos que dialogam com este. O relato das 24 horas de agente autônomo mostra o lado segurança dessa mesma degradação. O relato de 4 falhas em 6 semanas de spec-driven development com Claude Code mostra como o padrão aparece quando você tenta espremer mais autonomia pra dentro da sessão.

Aprofundei este padrão e a taxonomia completa no meu livro context-engineering-pt, mas o essencial pra parar de perder o dia inteiro é o que está aqui em cima.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews