o problema
A Anthropic serve o Claude pela API própria, pelo Amazon Bedrock e pelo Vertex AI da Google, rodando em três plataformas de hardware diferentes: AWS Trainium, GPUs NVIDIA e TPUs do Google. Cada plataforma exige otimizações próprias, mas o padrão declarado é de equivalência: a resposta não deveria depender de qual chip atendeu a requisição. Isso significa que qualquer mudança de infraestrutura precisa ser validada em todas as combinações de plataforma e configuração — e que uma mudança aparentemente inócua pode alterar a saída do modelo.
Em agosto de 2025, usuários começaram a relatar respostas piores. No começo, os relatos eram indistinguíveis da variação normal de feedback: alguns usuários reclamavam, outros não viam nada de errado, e as reclamações não apontavam para um sintoma único. Só no fim de agosto, com a frequência subindo, uma investigação foi aberta. Ela encontrou três bugs separados, com janelas de tempo sobrepostas, sintomas distintos e taxas de incidência diferentes por plataforma. Esse é o cenário em que um postmortem vira necessário: não dava para responder “está tudo bem” nem para apontar uma causa.
a ideia
O texto faz duas coisas. A primeira é negar de forma direta a hipótese que circulava: a empresa afirma que nunca reduz a qualidade do modelo por demanda, horário do dia ou carga de servidor, e que a degradação veio dos bugs de infraestrutura e de mais nada. A segunda é abrir datas, percentuais e mecanismo, incluindo um mergulho num bug de compilador — nível de detalhe que a Anthropic diz não compartilhar normalmente.
O fio que amarra os três bugs é o mesmo: pontos onde a infraestrutura toca a distribuição de probabilidade do próximo token, ou o caminho da requisição até o servidor certo. Nenhum deles é um problema de treino ou de pesos.
como funciona
O primeiro bug é de roteamento. Em 5 de agosto, algumas requisições ao Sonnet 4 passaram a ser mandadas para servidores configurados para a janela de 1M de tokens, afetando cerca de 0,8% delas. Em 29 de agosto, uma mudança rotineira de load balancing aumentou o volume de requisições de contexto curto indo para esses servidores; na pior hora, em 31 de agosto, 16% das requisições ao Sonnet 4 foram afetadas, e cerca de 30% dos usuários de Claude Code no período tiveram pelo menos uma mensagem no servidor errado. No Bedrock, o pico foi de 0,18%; no Vertex, menos de 0,0004%. Como o roteamento é sticky, quem caiu no pool errado tendia a continuar nele. A correção saiu em 4 de setembro e terminou de ser distribuída em 18 de setembro no Bedrock.
O segundo é corrupção de saída. Em 25 de agosto, uma má configuração nos servidores TPU da API introduziu um erro na geração: uma otimização de runtime às vezes atribuía alta probabilidade a tokens que quase nunca deveriam aparecer naquele contexto — caracteres tailandeses ou chineses no meio de uma resposta em inglês, erros óbvios de sintaxe em código. Atingiu Opus 4.1 e Opus 4 entre 25 e 28 de agosto, e Sonnet 4 até 2 de setembro. Rollback em 2 de setembro, mais testes de detecção de caracteres inesperados no pipeline de deploy.
O terceiro é o mais interessante. O caminho de sampling é aproximadamente este:
probs = softmax(logits) # bf16
cands = approx_top_k(probs) # otimização de performance
cands = top_p(cands, 0.99) # ou 0,999
token = sample(cands)As probabilidades saem em bf16, mas o processador vetorial da TPU é nativo em fp32, e o XLA converte parte das operações para fp32 sob a flag xla_allow_excess_precision, ligada por padrão. Operações que deveriam concordar sobre qual é o token mais provável rodavam em precisões diferentes e discordavam — e o token mais provável sumia. Em dezembro de 2024 isso apareceu com temperature zero e ganhou um workaround. Em 26 de agosto de 2025, uma reescrita do sampling removeu o workaround, por acreditar que a causa raiz estava resolvida. Só que o workaround também mascarava um bug latente no approx_top_k do compilador XLA:TPU, que devolvia resultados completamente errados para certos batch sizes e configurações. O comportamento mudava conforme operações vizinhas e conforme ferramentas de debug estavam ligadas; o mesmo prompt falhava numa requisição e funcionava na seguinte; em CPU, o reprodutor dava certo. O bug foi confirmado no Haiku 3.5 e é considerado provável em parte do Sonnet 4 e do Opus 3.
o que isso custou
A correção definitiva foi trocar o top-k aproximado pelo exato e padronizar mais operações em fp32. A justificativa é explícita: qualidade não se negocia, e a perda de eficiência foi aceita. O texto ainda avisa que o top-k correto muda levemente quais tokens entram perto do limiar de top-p, e que alguns usuários podem precisar re-tunar esse parâmetro — ou seja, o conserto não é neutro para quem tinha configuração fina.
A detecção falhou por razões que a própria Anthropic lista. Os benchmarks não capturaram a degradação, em parte porque o Claude se recupera bem de um erro isolado: o modelo escondia o defeito da infraestrutura. Os controles internos de privacidade limitam o acesso de engenheiros a interações não reportadas como feedback, o que protege o usuário e ao mesmo tempo impede reproduzir o caso. Cada bug produzia sintoma diferente em plataforma diferente, e o resultado parecia degradação aleatória. E o pico de reclamações em 29 de agosto não foi ligado de imediato à mudança de load balancing daquele dia. O Sonnet 4 chegou a ter o terceiro bug revertido sem que a equipe conseguisse reproduzi-lo — por precaução.
onde isso aparece hoje
As mudanças anunciadas são todas de observabilidade: avaliações mais sensíveis, capazes de separar implementação boa de implementação quebrada; avaliações rodando continuamente em produção, e não só em ambiente de teste; e ferramentas de debug que permitam trabalhar sobre feedback da comunidade sem abrir mão da privacidade. Os testes de detecção de caracteres inesperados já entraram no processo de deploy.
O bug do compilador foi levado ao time de XLA:TPU com um reprodutor mínimo, e a correção do compilador é tratada como trabalho em paralelo ao fix próprio. Do lado do usuário, o pedido é operacional: /bug no Claude Code, thumbs down nos apps, e avaliações de terceiros por e-mail — o texto trata relatos com exemplos concretos como sinal que efetivamente ajudou a isolar as três falhas.