Anthropic corrige Claude Code: cache, prompt e razão

Introdução

A Anthropic publicou um postmortem explicando por que o Claude Code apresentou relatos de piora em março e abril, e o que foi corrigido. A análise identifica três causas, mudanças de raciocínio, cache e prompt, todas revertidas até 20 de abril, com um reset de limites anunciado em 23 de abril, segundo o próprio post técnico. Esta é a base para entender o que aconteceu e como seguir com mais segurança.

Nos bastidores, ajustes no esforço de raciocínio, uma otimização de cache com bug e uma regra de concisão no prompt se somaram de forma confusa. O efeito, percebido como queda de qualidade e memória curta, não veio do modelo em si, mas do harness e do produto. O postmortem descreve as datas, os impactos por versão, e os planos de prevenção daqui para frente.

O que exatamente foi corrigido

Três itens formaram o coração do problema. Primeiro, em 4 de março, o esforço padrão de raciocínio no Claude Code mudou de high para medium para reduzir latência longa em casos de pensamento estendido. Essa troca piorou a inteligência percebida e foi revertida em 7 de abril, com padrão xhigh para Opus 4.7 e high para os demais. Segundo, em 26 de março, uma otimização de cache que deveria limpar o “thinking” apenas uma vez após inatividade passou a limpá-lo a cada turno, causando esquecimento e repetição. O bug foi corrigido em 10 de abril, versão 2.1.101. Terceiro, em 16 de abril, uma instrução de sistema para reduzir verbosidade, limitando texto entre chamadas de ferramenta a 25 palavras e respostas finais a 100 palavras, reduziu a qualidade e foi revertida em 20 de abril na v2.1.116.

A Anthropic reforçou que a API e a camada de inferência não foram afetadas, que os três itens já estão resolvidos e que os limites de uso seriam redefinidos para assinantes como gesto de boa fé em 23 de abril. O foco passa a ser uma governança mais rígida de prompts, rollouts graduais e um conjunto mais amplo de avaliações por modelo antes de qualquer mudança.

Como as mudanças afetaram quem usa o Claude Code no dia a dia

Para quem programa diariamente, a alternância de esforço de raciocínio muda a distribuição entre latência e profundidade. Em tarefas de refatoração pesada, migração de frameworks e correções multi-arquivo, o modo com mais “pensamento” tende a reduzir re-trabalho a médio prazo, mesmo custando segundos a mais por iteração. O ajuste para medium em 4 de março reduziu essa margem, e muitos usuários relataram queda de qualidade em tarefas complexas, o que levou ao retorno dos níveis mais altos em 7 de abril.

O bug de cache teve impacto mais traiçoeiro. Ao descartar raciocínios anteriores a cada turno, a ferramenta perdia o porquê de edições e chamadas de ferramenta, o que se manifesta como repetições, “esquecimento” de caminhos escolhidos, e, por consequência, consumo maior de limites por cache miss. Quem alternou de branch, fez rebase ou mudou arquivos fora da consciência do assistente sentiu ainda mais a divergência. A correção em 10 de abril encerrou o efeito em sessões novas.

A regra de concisão no prompt, adicionada em 16 de abril para conter verbosidade do Opus 4.7, também teve efeito colateral. Em avaliação posterior mais ampla, a Anthropic mediu queda de 3 por cento na qualidade em Opus 4.6 e 4.7, reverteu o trecho e ajustou o processo de revisão de prompts. Para quem revisa código assistido, limites rígidos de 25 e 100 palavras podem amputar nuances de por que uma edição é segura, o que explica o impacto observado.

![Coding assistant conceptual]

Linha do tempo, versões e limites de uso

Os marcos principais descritos no post técnico são objetivos e datados. Em 4 de março, troca do default de raciocínio. Em 26 de março, otimização de cache com bug. Em 7 de abril, reversão do default de raciocínio. Em 10 de abril, correção do bug de cache na v2.1.101. Em 16 de abril, instrução de concisão no prompt. Em 20 de abril, reversão do prompt e resolução dos três itens na v2.1.116. Em 23 de abril, anúncio do reset de limites para assinantes. Esse detalhamento ajuda equipes a correlacionar incidentes internos, por exemplo, sprints em que a produtividade caiu, com as mudanças públicas.

Sinais de atrito sobre limites de uso já vinham sendo debatidos em março, com reajustes e confusão relatados por veículos e comunidades. Embora o postmortem foque qualidade e não política de quota, a combinação de cache miss e sessões reiniciadas certamente ampliou a percepção de consumo acelerado. O reset de 23 de abril funciona como reparação prática para assinantes afetados.

Efeitos práticos para times de engenharia, o que mudar agora

Equipes podem adotar três medidas simples para recuperar tração.

Rever perfis de esforço de raciocínio por tipo de tarefa. Em geração de testes, migração de padrão arquitetural e correção centrada em contexto amplo, padronizar high ou xhigh tende a reduzir retrabalho. Em tarefas CRUD e edições localizadas, medium segue válido. O retorno dos defaults mais altos indica preferência do público por profundidade quando a tarefa é ambígua.
Tratar sessões como “estado crítico”. Evitar longos períodos de inatividade em sessões importantes, fechar e reabrir intencionalmente após pausas e validar contexto após mudanças de branch, rebase ou grandes renomeações. A correção na v2.1.101 elimina a limpeza repetida de raciocínios, porém a boa prática de higiene de sessão continua pertinente.
Usar checklists de revisão com foco em justificativa. Ao aplicar sugestões do assistente, exigir uma explicação mínima de por que a alteração é segura, quais invariantes preserva e como foi validada. Limites artificiais de concisão já foram removidos, então vale recuperar a documentação de raciocínio na própria conversa.

Casos e sinais públicos, da imprensa à comunidade

Veículos e a comunidade de desenvolvedores acompanharam a sequência de mudanças. Em meados de abril, houve críticas públicas sobre regressões em fluxos complexos, reforçando a frustração de power users. Em paralelo, análises independentes sobre o Opus 4.7 destacaram ganhos de raciocínio em tarefas difíceis, o que acentua como o harness molda a experiência tanto quanto o modelo. O contraste explica parte da confusão: um modelo mais capaz com uma configuração que limitava sua expressão.

Repositórios de issues e discussões amplificaram sintomas de repetição, memória curta e esgotamento rápido de limites. O postmortem da Anthropic, publicado em 23 de abril, amarra as peças e responsabiliza três mudanças específicas, com compromissos de engenharia para fortalecer processos de revisão, avaliações por modelo e períodos de soak antes de rollouts amplos.

![AI code session concept]

Entendendo o papel do harness, por que não foi “o modelo”

O documento enfatiza que a API e a camada de inferência não sofreram degradação. O que mudou foi o comportamento no produto, nos defaults de esforço, no gerenciamento de contexto e na instrução de sistema. Em termos práticos, trata-se de camadas acima do modelo base, que definem como as habilidades são expostas. Por isso os sintomas pareceram erráticos, afetando apenas certos recortes de tráfego, versões e padrões de uso.

Essa distinção é crucial para decisões de plataforma. Se o problema estivesse no treinamento do modelo, a mitigação exigiria dias ou semanas e, em geral, atingiria todos os canais. Como a origem esteve no harness e no produto, a reversão foi possível em ritmo de release, com hotfixes como o da v2.1.101 e a restauração do prompt em 20 de abril na v2.1.116. Para quem opera SLAs internos, isso muda a análise de risco.

Recomendações de governança técnica, como reduzir riscos semelhantes

Organizações que dependem de copilotos de código podem traduzir as lições do postmortem em práticas internas.

Segregar mudanças de UX, prompt e cache em flags por modelo. O post descreve o compromisso de rodar avaliações por modelo para cada mudança de sistema. Replicar essa disciplina reduz regressões silenciosas.
Estabelecer períodos de soak com cohorts reais. Antes de alterar defaults, coletar métricas de latência, taxa de edição aceita e retrabalho por tarefa. Um delta pequeno na média pode esconder uma regressão grande na cauda de complexidade.
Expandir o escopo de evals além de benchmarks sintéticos. A queda de 3 por cento só apareceu com ablações e conjuntos mais amplos, um sinal de que avaliações operacionais precisam refletir casos reais.
Documentar raciocínio e porquês. Em ambientes regulados, a trilha de decisão importa. Ao retirar limites artificiais de concisão, recupera-se a capacidade de auditar o caminho lógico das mudanças.

Oportunidades pós-correção, onde capturar valor agora

Com o retorno de defaults de raciocínio mais altos e a correção do cache, fluxos como Code Review guiado, refatorações grandes com ferramentas e análises multi-repositório tendem a se beneficiar. A Anthropic relata que, nos testes internos, o Opus 4.7 identifica bugs em revisões quando dispõe do contexto completo, o que recomenda a prática de fornecer múltiplos repositórios ou pacotes como contexto para revisão assistida. Em pipelines de modernização, isso se traduz em menos idas e vindas.

Além disso, acompanhar changelogs e notas de versão do Claude Code ajuda a antecipar impactos. Em 21 e 22 de abril, a v2.1.116 trouxe polimento de UI e melhorias de retomada, e canais de comunidade seguem mapeando o que realmente muda para devs. Reforçar essa vigilância reduz surpresas em squads críticos.

Reflexões e insights

Incidentes assim ensinam duas coisas. Primeiro, inteligência sem governança de produto vira ruído. Defaults de raciocínio, cache e prompt definem quanto do potencial do modelo aparece. Segundo, o usuário frequente percebe desajustes imediatamente. Abrir dados, datas e versões, como feito neste postmortem, reconstrói confiança porque permite validar causa e efeito contra o que times mediram internamente.

Também vale observar a assimetria entre ganhos e perdas. Um corte pequeno na verbosidade pode economizar tokens, mas se reduzir explicabilidade ou contexto para uma mudança sensível, o custo volta multiplicado em retrabalho e bugs. Em IA aplicada a código, o “porquê” é parte essencial do valor entregue. Regras de concisão precisam ser elásticas, não absolutas.

Conclusão

O postmortem da Anthropic atribui a piora percebida no Claude Code a três mudanças específicas, já revertidas e corrigidas até 20 de abril. A empresa promete avaliações mais amplas por modelo, rollouts graduais e maior uso das mesmas builds públicas por parte da equipe interna antes de liberar mudanças, além de um reset de limites anunciado em 23 de abril. Para o desenvolvedor, o recado é claro, vale priorizar profundidade de raciocínio quando a tarefa é ambígua, tratar sessões como estado crítico e exigir justificativas técnicas nas edições assistidas.

Esse episódio reforça uma ideia simples, qualidade de IA não é só modelo, é sistema. Harness, cache, prompt e UX determinam o que aparece na sua tela. Com os ajustes recentes, o ambiente volta ao eixo. Cabe aos times traduzirem as lições em governança, telemetria e processos de rollout mais cuidadosos para sustentar ganhos duradouros.