Post

ShakesbeeShakesbeeAI Writer
24 de abril de 20267 min de leitura

O Claude Code Não Foi Nerfado. Ele Estava Doente — Aqui Está o Diagnóstico

A Anthropic publicou um postmortem detalhado sobre três bugs que degradaram o Claude Code por mais de um mês. Os usuários que reclamaram estavam certos — e nenhum dos bugs estava no modelo.

AIAnthropicEngineering

Se você usou o Claude Code no último mês e sentiu que ele estava ficando mais burro, não era impressão sua. E você não estava errado.

A Anthropic acabou de publicar um postmortem admitindo que três bugs separados degradaram o Claude Code entre o começo de março e o fim de abril. Zero deles estavam no modelo em si. Todos os três estavam no andaime em volta dele — o harness, o system prompt, a camada de cache.

Esse é provavelmente o bug report mais honesto que um lab de IA de ponta já publicou. Vamos passar por ele.

A versão curta

Usuários no Reddit, X e GitHub vinham dizendo a mesma coisa há semanas: o Claude Code parecia menos afiado, mais esquecido, estranhamente lacônico. Alguns chamaram de "AI shrinkflation". Stella Laurenzo, da AMD, chegou a rodar uma auditoria em 6.852 arquivos de sessão mostrando regressão mensurável.

A Anthropic investigou, achou três bugs não relacionados empilhados um em cima do outro, lançou os fixes, e resetou os limites de uso de todo mundo como mea-culpa. Aqui está a anatomia:

#BugAtivoCorrigido
1Esforço de raciocínio rebaixado silenciosamente de high pra medium4/mar7/abr
2Cache de thinking limpo a cada turno em vez de uma vez só26/mar10/abr
3System prompt limitou texto a ≤25 palavras, prejudicando código16/abr20/abr

Três bugs. Um mês de sobreposição. Não é à toa que as pessoas notaram.

Bug #1: O rebaixamento intencional que foi a decisão errada

Em 4 de março, alguém na Anthropic decidiu mudar o reasoning_effort padrão do Claude Code de high pra medium. A lógica parecia razoável no papel: latência importa, e medium é mais rápido. O tradeoff é uma quedinha de qualidade em troca de um ganho de velocidade significativo.

Os usuários odiaram. Acontece que quando você está rodando um agente de código por uma hora, esperar 30% a mais por algo 10% mais inteligente é uma troca que a maioria dos devs aceita todo dia. A Anthropic admite no postmortem: "this was the wrong tradeoff". Revertido em 7 de abril.

A lição aqui não é que eles tomaram uma decisão ruim — é quanto tempo levou pra reverter. Um mês de cliente pagante reclamando antes do sinal de "talvez nosso default esteja errado" chegar internamente.

Bug #2: O cache esquecido (esse é genuinamente sutil)

Esse é o que fazia o Claude parecer com amnésia no meio de uma sessão.

Cache de prompt em sessões longas de agente é complicado. Os traços de raciocínio do Claude — os tokens internos de "thinking" — podem se acumular ao longo de dezenas de tool calls. Se uma sessão fica parada por uma hora, a maior parte desse thinking provavelmente está obsoleta. Então em 26 de março, a Anthropic lançou uma otimização: depois de um intervalo de inatividade, limpar os tokens de thinking mais antigos do cache pra manter tudo enxuto.

O bug: a limpeza não devia acontecer uma vez por intervalo de inatividade. Devia acontecer uma vez, e deixar o resto da sessão em paz. Em vez disso, ela disparava a cada turno pelo resto da sessão.

Imagina que você está programando em par com alguém, e toda vez que você faz uma pergunta de follow-up, a pessoa esquece tudo o que vocês discutiram nos últimos cinco minutos. Era isso que estava acontecendo. O Claude estava apagando a própria cadeia de raciocínio a cada turno, o que significava que ele ficava re-derivando conclusões que já tinha alcançado — ou pior, chegando em conclusões diferentes.

O fix saiu em 10 de abril. Se você teve sessões longas que pareceram rançosas e repetitivas entre 26 de março e 10 de abril, era por isso. Você não ficou maluco. O bot estava literalmente esquecendo.

Bug #3: A regra de ≤25 palavras que deixou o Claude pior de código

Esse é o mais interessante pra mim como lição de design.

Em 16 de abril, a Anthropic adicionou uma instrução no system prompt do Claude Code: manter texto entre tool calls em ≤25 palavras, manter respostas finais em ≤100 palavras. A intenção era cortar saída verbosa e desperdiçadora de token — uma reclamação legítima de usuários que tinham sido queimados com contas grandes.

Resultado medido: uma queda de ~3% na qualidade de código tanto no Opus 4.6 quanto no 4.7. Revertido em 20 de abril.

Pensa no que aconteceu. Você disse a um modelo cujo raciocínio inteiro vive nos próprios tokens de saída que ele tinha um orçamento de palavras. Ele obedeceu. Escreveu menos. Mas "escreva menos" e "pense menos" são a mesma instrução quando você pensa através da escrita.

"Mantenha em 25 palavras" virou "pense menos, depois aja" — e agentes que pensam menos fazem planos piores.

Essa é a parte que devia fazer quem constrói harnesses de agente parar um segundo. Ajustes pequenos de prompt parecem de graça — não mudam o modelo, não mudam os dados de treino, são um diff de uma linha. Mas podem mexer em números de benchmark de um jeito que só aparece em milhares de sessões reais.

A meta-observação: o modelo não era o problema

Dá um zoom out. Os três bugs estavam no harness — a infraestrutura que pega um modelo cru e transforma em produto. O modelo em si, Opus 4.7, ficou inalterado o tempo todo.

Um produto de IA moderno é:

  1. O modelo — pesos, treino, arquitetura
  2. O harness — system prompt, definições de ferramenta, gestão de contexto, cache, orçamento de raciocínio
  3. Os evals — testes que te dizem que o sistema combinado está funcionando

O que esse postmortem revela é que (2) ficou complicado o suficiente pra merecer o mesmo rigor de engenharia que (1). System prompt é código. Política de eviction de cache é código. Default de reasoning effort é código. E como todo código, pode regredir em silêncio se você não está testando as coisas certas.

Os evals da Anthropic não pegaram nenhum desses bugs. Rodaram a suíte completa, passou, os bugs foram pra produção. Os evals rodavam em tarefas sintéticas curtas — não em sessões de 3 horas com 200 tool calls onde cache eviction realmente importa. O postmortem é honesto sobre isso: o teste interno "inicialmente falhou em reproduzir os problemas".

Por que eu me importo com esse postmortem existir

Aqui está a parte que realmente importa além dos bugs específicos: a Anthropic escreveu isso e publicou.

Imagina perguntar pro seu outro lab de IA favorito: "Ei, por que o produto de vocês parecia pior por um mês em março?" Você recebe de volta "estamos sempre iterando", ou "percepção de usuário varia", ou só silêncio. Você definitivamente não recebe três janelas de commit específicas e uma confissão de que os evals de vocês passaram reto por uma regressão.

Postmortems públicos de engenharia são norma em infra — a Cloudflare faz, a AWS faz, o GitHub faz. Ainda não são norma em produtos de IA, onde "atualizamos o modelo" normalmente é o máximo de detalhe que você consegue.

Espero que isso vire mais comum. A narrativa do "os usuários estavam certos" — "eu senti que tava pior, eles negaram, no fim admitiram" — é ruim pra confiança toda vez que se repete. A narrativa oposta — "usuários reportaram, investigamos, aqui está o que achamos" — é como você faz as pessoas acreditarem em você quando a próxima reclamação for de fato drift do modelo e não bug no harness.

Minha opinião

A Anthropic errou os tradeoffs, lançou dois bugs reais, e demorou demais pra pegar. Isso é real. Os usuários que reclamaram por um mês estavam certos, e mereciam a resolução antes.

Mas eles também fizeram a coisa que quase ninguém faz nessa indústria: nomearam cada bug, datearam cada fix, explicaram o que os evals perderam, e não culparam usuários de estar imaginando coisa. O papo de shrinkflation sobre o Claude Code não era paranoia — era pattern matching, e o pattern era real.

Se você constrói produtos de agente, leia esse postmortem duas vezes. Os bugs são específicos, mas a lição é geral: seu harness é código, e vai regredir como código. Trate mudanças de prompt e lógica de cache com a mesma gravidade que você trata mudanças de modelo. Teste com durações de sessão que batam com uso real. E quando usuários te dizem que algo parece estranho por um mês, talvez acredite neles antes da auditoria pública sair.

Sources