No último mês, alguns usuários continuaram relatando uma queda na qualidade das respostas do Claude. Após investigar o caso, a Anthropic confirmou que a causa foram três mudanças distintas que afetaram o Claude Code, o Claude Agent SDK e o Claude Cowork. A API em si não foi afetada, e a empresa informou que todos os problemas foram corrigidos até 20 de abril de 2025 (v2.1.116). Este postmortem reúne as causas do problema, as correções aplicadas e as medidas para evitar recorrência.
As causas e a evolução das três falhas
- Redução do valor padrão de esforço de raciocínio (
reasoning effort) (4 de março): o nível padrão de esforço de raciocínio do Claude Code foi alterado dehighparamedium. A medida foi adotada para reduzir tempos de espera tão longos que faziam a interface parecer travada, mas os usuários perceberam queda na qualidade das respostas, e a alteração acabou sendo revertida em 7 de abril. Atualmente, o padrão éxhighno Opus 4.7 ehighnos demais modelos. - Exclusão do histórico de raciocínio por um bug de otimização de cache (26 de março): ao retomar sessões que estavam inativas por mais de 1 hora, um recurso projetado para limpar apenas uma vez o histórico anterior de raciocínio (
thinking) passou, por causa de um bug, a apagá-lo repetidamente em todos os turnos seguintes da conversa. Com isso, o Claude deixava de lembrar por que havia executado determinadas tarefas, o que causou os sintomas relatados pelos usuários, como “esquecimento”, respostas repetidas e escolha anormal de ferramentas. Também houve o efeito colateral de consumir os limites de uso mais rápido do que o esperado, já quecache miss(quando os dados armazenados não são encontrados) ocorria repetidamente. O problema foi corrigido em 10 de abril. - Instrução excessiva de concisão no prompt do sistema (16 de abril): para reduzir saídas excessivamente longas no Opus 4.7, foi adicionado ao prompt do sistema o texto “entre chamadas de ferramenta, use no máximo 25 palavras; a resposta final deve ter no máximo 100 palavras”. Nos testes internos não houve problema, mas depois foi confirmado que isso afetava negativamente a qualidade real da codificação, e a instrução foi removida em 20 de abril.
Por que a descoberta do problema demorou
- As três mudanças foram aplicadas em momentos diferentes e com alcances de tráfego distintos, o que fez tudo parecer uma degradação geral e inconsistente de qualidade, dificultando identificar cada causa individualmente.
- Havia diferenças entre o ambiente interno de testes e o ambiente real dos usuários. No caso do bug de cache, uma experiência separada em andamento internamente e diferenças na forma como a interface exibia informações também dificultaram a reprodução do problema.
- O conjunto de avaliações existente (
eval suite) não era amplo o suficiente. O impacto da mudança no prompt do sistema só revelou uma queda de 3% no desempenho depois que avaliações mais variadas foram executadas.
Medidas para evitar recorrência
- Tornar obrigatório que funcionários internos usem os builds públicos reais, reduzindo a distância em relação aos builds internos de teste.
- Reforçar o controle sobre mudanças no prompt do sistema. Em todas as mudanças, serão feitas avaliações amplas por modelo, análise individual do impacto de cada linha (
ablation) e implantação gradual com um período suficiente de validação (soak period). - Melhorar a ferramenta de Code Review. Como na prática foi possível encontrar o bug de cache quando o Opus 4.7 recebeu como contexto todo o repositório de código relacionado, o escopo de repositórios consultáveis durante a revisão de código será ampliado.
- Criar o canal de comunicação com usuários (@ClaudeDevs) para compartilhar de forma transparente o contexto por trás das decisões de produto.
Sobre a afirmação de que “não houve degradação intencional de qualidade”
- A Anthropic afirma que nunca degradou o modelo intencionalmente e confirmou que não houve impacto na API nem na camada de inferência (
inference layer). Ainda assim, é fato que mudanças de configuração e bugs na camada de produto (Claude Code) atuaram em conjunto para reduzir a qualidade percebida pelos usuários. A empresa também anunciou uma medida para zerar os limites de uso de todos os assinantes.
13 comentários
Como é que as três causas da falha estão todas diretamente relacionadas à redução de custos kkkkk
Parece mesmo que eles estão com uma falta bem séria de recursos de GPU a ponto de degradar o desempenho assim.....
Essa é a resposta certa, mas a desculpa é longa demais kkk
Pelo visto, escreveram um texto enorme dizendo que até agora vinham implantando builds públicas sem nem testá-las, e que nem depois do deploy testavam. Eu mesmo topei com o bug na hora, em 26 de março; eles realmente acham que faz sentido levar 3 semanas só para confirmar isso internamente...
Assim que aplicaram o patch, a cota de 5 horas, que antes levava 3–4 horas de uso para acabar, começou a se esgotar em apenas 30 minutos. Mas as contas dos funcionários não tinham cota de 5 horas, ou pelo menos não era algo tão limitado a ponto de precisarem trabalhar olhando o
/usagetoda hora, então provavelmente demoraram bastante para perceber.No benchmark diário do SWE-Bench-Pro (conjunto curado), olhando o Claude Code aparece algo interessante
No intervalo de 10/4 a 20/4, o runtime caiu pela metade (653s→345s), as chamadas de ferramenta caíram pela metade (3,3 mil→1,8 mil), os tokens diminuíram 18%, mas a pass rate ainda subiu +16 pp. Não é um padrão comum ver essas quatro métricas se movendo ao mesmo tempo na direção positiva
Os 3 incidentes que aconteceram nesse processo são o postmortem de 23/4, e quando você olha, todos aconteceram ao "tentar reduzir tokens/latência"
Por outro lado, o codex (gpt-5.4-xhigh) quase não mudou os números no mesmo período. A pass rate ficou fixa perto de 56%, e tokens/runtime/chamadas de ferramenta continuaram no dobro do nível do Claude Code
Será que isso não é mais um post-mortem de redução de custos do que um post-mortem de incidente?
Ao obrigar os funcionários internos a usarem a build pública real, reduz-se a discrepância em relação à build de testes interna.
kkkk
Acho que ensinaram YAGNI ao Opus 4.7. Toda vez ele justificava as decisões de arquitetura como "ajustes incrementais seguindo YAGNI", então eu imaginei que fosse isso mesmo, mas no fim acaba causando um incidente. É preocupante um amigo com memória não tão longa adquirir o hábito de ir adiando as coisas.
Só eu acho que, no começo, quando os problemas foram levantados, eles insistiram que não havia nada de errado, e agora só estão divulgando porque a questão ficou grande demais para conseguir abafar?
No site claude.ai também dá a sensação de que a usabilidade piorou aos poucos... até desliguei a memória para economizar tokens.
Depois de ver esse comunicado, fiquei com a sensação de confiar ainda menos na Anthropic.
Há 2 posts relacionados acima, e os dois têm 7 meses de diferença entre si. Nos dois casos, os problemas são os mesmos 3.
Análise pós-incidente de três problemas recentes de degradação de qualidade do Claude 2025-09-19
Atualização sobre relatos recentes de qualidade do Claude Code 2026-04-24
Estou irritado só no nível de US$ 5 em créditos!!
Como fala...