No último mês, continuaram surgindo relatos de alguns usuários de que a qualidade das respostas do Claude havia piorado. Após investigar, 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 própria API não foi afetada, e a empresa afirmou que todos os problemas foram resolvidos em 20 de abril de 2026 (v2.1.116). Este postmortem detalha 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 visava reduzir tempos de espera tão longos que faziam a UI parecer travada, mas os usuários perceberam piora na qualidade das respostas, e a mudança 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 causada por bug de otimização de cache (26 de março): ao retomar sessões que ficaram inativas por mais de 1 hora, um recurso projetado para limpar o histórico anterior de raciocínio (
thinking) apenas uma vez 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 feito determinadas ações, levando aos casos de "esquecimento", respostas repetidas e escolha anormal de ferramentas relatados pelos usuários. Também houve o efeito colateral de esgotar o limite de uso mais rápido do que o esperado, já que ocorriam repetidoscache miss(quando os dados armazenados não são encontrados). O problema foi corrigido em 10 de abril. - Instrução excessiva de concisão no prompt de sistema (16 de abril): para reduzir a verbosidade das saídas do Opus 4.7, foi adicionado ao prompt de sistema o texto "texto entre chamadas de ferramenta em até 25 palavras, resposta final em até 100 palavras". Nos testes internos, não houve problema, mas foi confirmado que isso afetava negativamente a qualidade real de 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 a faixas diferentes de tráfego, fazendo a situação parecer uma degradação geral e inconsistente de qualidade, o que dificultou identificar cada causa individualmente.
- Havia diferenças entre o ambiente de testes interno e o ambiente real dos usuários. No caso do bug de cache, por exemplo, um experimento separado em andamento internamente e diferenças na forma de exibição da UI tornaram a reprodução do problema difícil.
- A suíte de avaliação existente (
eval suite) não era ampla o suficiente. O impacto da mudança no prompt de sistema só revelou uma queda de 3% no desempenho depois que avaliações mais diversas foram executadas.
Medidas para evitar recorrência
- Tornar obrigatório que funcionários internos usem os builds públicos reais, reduzindo a discrepância em relação aos builds de teste internos.
- Reforçar o controle sobre mudanças no prompt de sistema. Em toda alteração, serão feitas avaliações amplas por modelo, análise individual do impacto de cada linha (
ablation) e rollout gradual com período suficiente de validação (soak period). - Melhorar as ferramentas de Code Review. Com base no fato de que o Opus 4.7 conseguiu encontrar o bug de cache quando recebeu como contexto o repositório de código relacionado inteiro, será ampliado o escopo de repositórios que podem ser consultados durante o code review.
- Criar o canal de comunicação com usuários (@ClaudeDevs) para compartilhar com transparência o contexto por trás das decisões de produto.
Sobre o ponto de que "não houve degradação intencional de qualidade"
- A Anthropic afirma que nunca degradou o modelo de forma intencional 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 de forma combinada para reduzir a qualidade percebida pelos usuários. A empresa também anunciou a redefinição dos limites de uso para 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...