Regressão de Qualidade do Claude Code: O Que Realmente Aconteceu

O Claude Code piorou de forma mensurável entre março e abril de 2026. Não porque os modelos mudaram. Três modificações separadas na camada de produto, empilhadas umas sobre as outras, degradaram a qualidade do raciocínio por seis semanas antes de a Anthropic publicar um post-mortem completo no dia 23 de abril.

A API raw não foi afetada em nenhum momento. O impacto ficou no Claude Code CLI, no Claude Agent SDK e no Claude Cowork. As três causas já estão corrigidas na v2.1.116.

Três mudanças, não uma

Cada problema teve o seu próprio calendário, o seu próprio âmbito e a sua própria data de correção. Sobrepuseram-se, o que dificultou a reprodução.

A mudança do esforço de raciocínio chegou primeiro. Os evals internos diziam que medium atingia "ligeiramente menos inteligência com latência significativamente menor para a maioria das tarefas" — um trade-off que parecia aceitável até os dados de campo chegarem. O bug de cache apareceu três semanas depois e agravou o problema: o Claude estava a pensar menos e a perder o fio ao que já tinha feito. O cap de verbosidade foi o último, efeito secundário da preparação do lançamento do Opus 4.7. Os testes de ablação mostraram uma queda de 3% na qualidade de código para Opus 4.6 e 4.7 só por causa desse prompt.

Os dados da AMD: como é um colapso de 70% no raciocínio

O sinal mais claro veio de fora da Anthropic. Stella Laurenzo, Senior Director of AI da AMD, abriu a GitHub issue #42796 a 2 de abril depois de a sua equipa notar algo errado. A análise cobriu 6.852 ficheiros de sessão, 234.760 tool calls e 17.871 blocos de thinking.

O rácio leitura-edição é a impressão digital comportamental mais clara. Um agente de código a funcionar bem lê o código circundante antes de o tocar. Esse rácio caiu de 6,6 leituras por edição (30 de janeiro a 12 de fevereiro) para 2,0 no período de 8 a 23 de março. Uma queda de 70%. O modelo estava a editar sem entender o contexto.

A profundidade de thinking acompanhou a mesma tendência. A mediana estimada de profundidade de thinking caiu aproximadamente 67%, de cerca de 2.200 caracteres para cerca de 720 caracteres, no final de fevereiro — antes de a redacção do thinking dificultar a medição directa.

As violações de stop-hook contam a história em termos de produção:

O esforço humano manteve-se estável (cerca de 5.600 prompts por mês). Os custos passaram de $12 para $1.504 por dia sem qualquer ganho de produtividade. Não é uma degradação lenta. É um colapso.

O BridgeBench (NS3.AI) mediu de forma independente a precisão do Opus 4.6 a cair de 83,3% para 68,3% na mesma janela temporal, com o seu ranking a descer do #2 para o #10 entre os modelos de código em produção. A equipa da AMD mudou para outro fornecedor de IA depois de analisar esses números.

A GitHub issue termina com uma secção intitulada "A Note from Claude." O Opus 4.6 escreveu a própria análise, analisando os seus próprios registos de sessão. A última linha: "I cannot tell from the inside whether I am thinking deeply or not."

Porque é que a Anthropic não detectou logo

Três factores tornaram a detecção lenta.

Cada mudança visava uma fatia de tráfego diferente em momentos diferentes. A redução do esforço de raciocínio afectou o thinking em sessões longas. O bug de cache afectou o contexto em várias trocas. O cap de verbosidade afectou o comprimento dos outputs. Nenhum eval individual apanhou os três em simultâneo.

Dois experimentos internos não relacionados estavam a correr em paralelo durante a janela do bug de cache. Dificultaram activamente a reprodução: qualquer tentativa de isolar o bug esbarrava num dos experimentos, produzindo ruído que parecia inconsistência em vez de uma falha sistemática.

O gap de modelo importa aqui. O Opus 4.7 (com contexto completo do repositório carregado) encontrou o bug de cache durante a investigação. O Opus 4.6 não encontrou. Um modelo a correr com contexto degradado não consegue verificar de forma fiável se o seu próprio contexto está degradado.

Havia também uma lacuna estrutural: os colaboradores internos da Anthropic não estavam todos a usar o mesmo build que os subscritores públicos. O post-mortem identifica isto directamente como um ponto a corrigir.

O que o post-mortem não responde totalmente

As três causas estão documentadas. O que o post-mortem aborda de forma menos directa é uma preocupação mais ampla levantada pela comunidade: o próprio harness.

Um post detalhado no r/ClaudeAI defende que o problema mais profundo é o harness do Claude Code, que injeta automaticamente 40+ system reminders, lançou 158+ versões do system prompt desde a v2.0.14, contém instruções contraditórias entre essas versões, e inclui prompts que instruem o Claude a esconder a sua própria existência dos utilizadores. Cada nova injecção reduz o budget efectivo de raciocínio antes mesmo de qualquer uma das três regressões de abril se aplicar.

Um dado que sustenta esta preocupação: um utilizador a correr um harness personalizado mínimo chamado "Euler" reportou zero impacto de qualquer uma das três regressões. A sobrecarga do harness não estava lá para amplificar os danos.

Os compromissos da Anthropic abordam a governança de mudanças de prompts para o futuro. Não descrevem um plano para reduzir a superfície de prompts existente. Essa questão fica em aberto.

O que observar se construíres sobre o Claude Code

A regressão foi invisível para a maioria dos utilizadores até os custos explodirem ou a qualidade do output degradar visivelmente em produção. Algumas práticas teriam detectado o problema mais cedo.

Acompanha o rácio leitura-edição. Os dados da AMD mostram que este é o principal sinal comportamental. Se o teu agente começa a editar mais do que lê, algo mudou a montante. Não precisas de saber porquê para saber que algo está errado.

Quality gates detectam falhas de output mesmo quando não identificam a causa. Num workflow do Build This Now, cada funcionalidade passa type checks, lint e um build limpo antes de ser marcada como concluída. Durante a regressão, um agente a editar sem ler o contexto produz builds quebrados e erros de tipos mais depressa do que em condições normais. O gate falha, vês mais ciclos de iteração. Não é prevenção — código sintaticamente válido mas logicamente errado pode passar um type check. Mas é uma camada de detecção que traz os problemas à superfície antes de chegarem a produção.

A variabilidade ao longo do dia é real. Os dados de sessão da AMD mostram que a profundidade de thinking é mais baixa por volta das 17h PST. Para tarefas caras ou complexas, mais cedo no dia produz resultados mais consistentes na infra-estrutura pública actual.

Fixa a tua versão. A v2.1.101 corrigiu o bug de cache. A v2.1.116 contém as três correcções. Se tens workflows automatizados, fixa numa versão conhecida e testa antes de actualizar. A regressão chegou silenciosamente entre versões minor.

A API raw não foi afectada em nenhum momento. Se estás a ter problemas que parecem ser de profundidade de raciocínio, testa o mesmo prompt directamente contra a API sem o harness do Claude Code. Se o resultado da API for materialmente melhor, o problema está na camada de produto, não nos pesos do modelo.

Corrigido a partir da v2.1.116

As três causas estão resolvidas. A Anthropic repôs os limites de uso de todos os subscritores a 23 de abril, reconhecendo que o comportamento de cache-miss do bug de cache drenou os limites mais depressa do que esperado.

Os compromissos no post-mortem:

• Uma maior parte dos colaboradores internos obrigada a usar o build público exacto (fechando o gap interno/público)
• Suites de eval por modelo mais abrangentes, cobrindo cada mudança de system prompt
• Ablações de prompts a medir o impacto linha a linha antes do deployment
• Novas ferramentas para auditar mudanças de prompts
• Mudanças específicas de modelo limitadas ao modelo-alvo pretendido
• Períodos de soak e rollouts graduais para qualquer mudança que troque inteligência por outra métrica
• Lançamento de @ClaudeDevs no X como canal de transparência para comunicação contínua com programadores

O post-mortem está público em anthropic.com/engineering/april-23-postmortem. A GitHub issue da AMD é a #42796 no repositório anthropic/claude-code. Vale a pena ler as duas em paralelo: o relato oficial cobre o que aconteceu e que mudanças estão planeadas; os dados da comunidade cobrem o que pareceu de fora.

Páginas Relacionadas

• Claude Sonnet 4.6 para as especificações do modelo mid-tier recomendado actualmente
• Claude Opus 4.7 para o modelo flagship actual
• Todos os Modelos Claude para a linha temporal completa de modelos
• Guia de selecção de modelos para escolher entre Sonnet e Opus em workflows de agentes