A Anthropic publicou um postmortem detalhado de engenharia explicando as seis semanas de queixas sobre a qualidade do Claude Code que correram de março a meados de abril. Três mudanças não-relacionadas na camada de produto foram enviadas entre 4 de março e 16 de abril, cada uma afetando uma fatia diferente do tráfego no seu próprio calendário — é por isso que os usuários relataram sintomas selvagemente diferentes dependendo de quando usavam o Claude Code e em quais funcionalidades se apoiavam. Criticamente, a API e os pesos do modelo subjacente não foram afetados. Os três problemas estão resolvidos a partir do Claude Code v2.1.116 em 20 de abril, e a Anthropic resetou os limites de uso para todos os assinantes. A divulgação honesta é a parte que distingue isso do comunicado típico de "estamos melhorando o produto": datas específicas, commits específicos, números de qualidade específicos, e responsabilidade nomeada do time do Claude Code.

As três mudanças se decompõem limpamente. Primeira, em 4 de março, o esforço de raciocínio padrão foi mudado de high para medium para resolver congelamentos de UI durante períodos longos de raciocínio — a Anthropic reconhece que isso foi "o tradeoff errado" e reverteu em 7 de abril. Todos os modelos agora têm default em high ou xhigh. Segunda, em 26 de março, uma otimização para limpar seções antigas de pensamento de sessões inativas (sessões inativas por 1h+, onde um cache miss completo era inevitável de qualquer jeito) teve um bug que disparava a limpeza em cada turno em vez de só uma vez. O Claude continuava executando mas cada vez mais sem memória de por que escolheu sua abordagem atual. Boris Cherny no Hacker News nomeou o caso extremo: um usuário com 900K tokens em contexto inativo por uma hora enfrentaria um cache miss completo na próxima mensagem, consumindo uma porcentagem significativa dos rate limits — especialmente para usuários Pro. Corrigido em 10 de abril. Terceira, em 16 de abril junto com o Opus 4.7, a Anthropic adicionou um limite de verbosidade ao system prompt instruindo o modelo a "manter o texto entre chamadas de ferramentas a 25 palavras ou menos" e "manter respostas finais a 100 palavras ou menos". Testes internos não acharam regressões. Ablações mais amplas rodadas durante a investigação revelaram uma queda de qualidade de 3% no Opus 4.6 e 4.7. Revertido em 20 de abril. Como meta-achado, a própria ferramenta Code Review da Anthropic foi back-testada contra os PRs ofensivos: Opus 4.7 achou o bug de cache quando recebeu contexto suficiente do repo; Opus 4.6 não.

A crítica da comunidade vale a pena ser pesada ao lado do postmortem. Comentaristas no Hacker News questionaram se a redução de latência era o real motor do pruning de sessão inativa, ou se a redução de custo era o objetivo real com a latência como capa. Vários sinalizaram que publicar benchmarks contra um system prompt mais velho e depois enviar um novo sem divulgação "soa enganoso". A Fortune reportou que usuários se sentiram "gaslightados" pelas negações iniciais da Anthropic. A resposta da Anthropic à Fortune incluiu a linha "compute é uma restrição em toda a indústria" junto com o pitch de partnership de scaling. Dois problemas que o postmortem não aborda também valem a pena ser acompanhados: usuários do Reddit relatam que o Claude Code delega mais frequentemente do que o esperado para o modelo Haiku mais barato — visível só em logging verbose — o que é uma classe de risco de qualidade silenciosa em pipelines automatizados mas óbvia em uso interativo. E pelo menos um usuário do Reddit confirmou independentemente que as instruções de verbosidade ficaram no system prompt depois do revert anunciado em 20 de abril, construindo um script de pre-tool hook que contrariava cinco modos de falha específicos em torno de releitura de fonte pulada e saída confiante-mas-mismatch. O fato de que o workaround construído pelo usuário melhorou a qualidade é em si uma validação do diagnóstico do postmortem de que o limite de verbosidade degrada qualidade.

Para builders rodando Claude Code em produção: os fixes canônicos são v2.1.116. Se você tem workflows CI ou automatizados que rodaram durante março-abril, audite qualquer saída pela impressão digital das três mudanças — especialmente sessões longas inativas (bug de cache) e qualquer saída em torno de 16-20 de abril (prompt de verbosidade). Para builders enviando produtos backed-LLM em geral, a lição de engenharia levantada diretamente: os evals internos falharam em pegar qualquer um dos três problemas porque o pessoal interno usava builds diferentes da release pública, o bug de cache só se manifestava num estado específico (sessões rançosas) não exercitado em eval, e a suite de eval era estreita demais para detectar uma queda de qualidade de 3% em mudanças de system prompt. A remediação declarada pela Anthropic — pessoal interno em builds públicos exatos, suites de eval por modelo mais amplas para toda mudança de system prompt, períodos de imersão e rollouts graduais, versionamento cuidadoso de mudanças de system prompt — é uma baseline industrial razoável. A admissão "compute é uma restrição" também importa: se a Anthropic está fazendo tradeoffs de custo/latência que visivelmente degradam qualidade, a mesma lógica se aplica a todo vendor, e times de procurement de produto deveriam perguntar explicitamente sobre decisões de latência-vs-qualidade em SLAs de vendor.