Atualização sobre o relatório recente da qualidade do Claude Code

• A queda percebida na qualidade do Claude ao longo do último mês veio de três mudanças diferentes em Claude Code, Claude Agent SDK e Claude Cowork, e a API não foi afetada
• Depois de reduzir a intensidade de raciocínio padrão para medium, a latência e os limites de uso diminuíram, mas surgiu a sensação de que o Claude Code tinha ficado menos inteligente, então o padrão foi revertido em 7 de abril
• Um bug de otimização de cache implantado em 26 de março criou um estado em que o histórico de raciocínio era apagado a cada turno em sessões que ultrapassavam o limite de inatividade, levando a esquecimentos, repetições, escolhas estranhas de ferramentas e consumo mais rápido dos usage limits
• Uma linha no prompt de sistema introduzida junto com o Opus 4.7 em 16 de abril era uma restrição para reduzir a verbosidade da saída, mas em uma avaliação mais ampla derrubou o desempenho de alguns modelos em 3%, e foi revertida em 20 de abril
• Os três problemas já foram corrigidos e refletidos na v2.1.116, lançada em 20 de abril, e a redução da diferença entre builds internos e públicos, maior controle sobre prompts de sistema, avaliações mais amplas e rollout gradual foram definidos como pontos centrais para evitar recorrência

---

Escopo da queda recente de qualidade e status da recuperação

• A queda percebida na qualidade do Claude por alguns usuários ao longo do último mês veio de três mudanças separadas em Claude Code, Claude Agent SDK e Claude Cowork, e a API não foi afetada
• Os três problemas já foram resolvidos e refletidos na v2.1.116, lançada em 20 de abril
• Como cada mudança afetou cronogramas diferentes e faixas de tráfego diferentes, no conjunto isso pareceu uma degradação ampla, porém inconsistente, de desempenho
• As investigações sobre os relatos começaram no início de março, mas no começo foi difícil distingui-los da variação normal no feedback dos usuários, e o mesmo problema também não foi reproduzido de imediato no uso interno e nas avaliações
• Em 23 de abril, os usage limits de todos os assinantes foram zerados

Mudança na intensidade de raciocínio padrão do Claude Code

• Em fevereiro, quando o Opus 4.6 foi lançado no Claude Code, a intensidade de raciocínio padrão foi definida como high
• Logo depois, no modo high, passaram a ocorrer de forma intermitente tempos de pensamento excessivamente longos, fazendo a interface parecer travada, e para alguns usuários a latência e o uso de tokens ficaram excessivos
• O nível de effort do Claude Code é usado como um meio de decidir entre fazê-lo pensar por mais tempo ou priorizar menor latência e menor consumo dos limites de uso
  • Na camada de produto, um ponto padrão da curva de cálculo no momento do teste é escolhido e enviado à Messages API como parâmetro de effort
  • Outras opções são oferecidas por /effort
• Em avaliações e testes internos, medium produziu, na maioria das tarefas, inteligência um pouco menor e latência muito menor
  • medium também sofria menos com problemas de latência extrema na cauda
  • E era mais vantajoso para maximizar os usage limits dos usuários
• Com base nesses resultados, o effort padrão foi alterado para medium, e os motivos também foram comunicados em uma caixa de diálogo no produto
• Logo após a implantação, os usuários começaram a sentir que o Claude Code estava menos inteligente
  • Foram feitas várias mudanças de design para destacar melhor a configuração de effort atual, como aviso ao iniciar, seletor de effort embutido e restauração do ultrathink
  • Mesmo assim, a maioria dos usuários continuou no padrão medium
• Com feedback adicional de clientes, essa decisão foi revertida em 7 de abril
  • Agora, para todos os usuários, o padrão no Opus 4.7 é xhigh
  • E em todos os outros modelos o padrão aplicado é high
• Essa mudança afetou o Sonnet 4.6 e o Opus 4.6

Otimização de cache que descartava o histórico de raciocínio anterior

• Quando o Claude raciocina sobre uma tarefa, esse histórico de raciocínio permanece no histórico da conversa, permitindo continuar consultando, a cada turno seguinte, os motivos de edições anteriores e chamadas de ferramentas
• Em 26 de março, foi implantada uma mudança para aumentar a eficiência desse recurso
  • A Anthropic usa prompt caching para tornar chamadas consecutivas de API mais baratas e mais rápidas
  • O Claude grava tokens de entrada no cache durante uma requisição de API, e depois de certo período de inatividade esse prompt é removido do cache para abrir espaço para outros prompts
  • O aproveitamento do cache é gerenciado com cuidado, e a abordagem relacionada está resumida em approach
• Em termos de projeto, se uma sessão ficasse inativa por mais de uma hora, a ideia era limpar uma vez os blocos de thinking anteriores para reduzir o custo de retomar a sessão
  • Essa requisição inevitavelmente daria cache miss, então a intenção era cortar da requisição mensagens desnecessárias e reduzir a quantidade de tokens uncached enviados à API
  • Depois disso, o sistema foi projetado para voltar a enviar o histórico completo de raciocínio
  • Para isso, usava o cabeçalho de API clear_thinking_20251015 e keep:1
• Na implementação real havia um bug: o histórico de thinking deveria ser apagado só uma vez, mas continuava sendo apagado a cada turno até o fim da sessão
• Depois que uma sessão ultrapassava uma vez o limite de inatividade, todas as requisições seguintes daquele processo passavam para a API descartando os blocos anteriores de raciocínio e mantendo apenas o mais recente
• O problema piorava de forma cumulativa
  • Se o Claude enviasse mensagens de acompanhamento no meio do uso de ferramentas, isso por si só virava um novo turno sob a flag quebrada
  • Como resultado, até o raciocínio do turno atual podia ser descartado
• O Claude continuava executando, mas cada vez mais sem memória do motivo pelo qual escolheu aquele comportamento
  • Para o usuário, isso aparecia como esquecimento, repetição e escolhas estranhas de ferramentas
• Como os blocos de thinking continuavam sumindo nas requisições seguintes, essas requisições também acabavam em cache miss
  • Relatos separados de que os usage limits estavam se esgotando mais rápido do que o esperado são atribuídos a esse fenômeno
• Havia ainda dois experimentos não relacionados por trás da dificuldade inicial de reproduzir o problema
  • Um experimento interno no servidor, relacionado a enfileiramento de mensagens
  • E uma mudança separada na forma de exibir thinking, que acabou mascarando esse bug na maioria das sessões de CLI
• Esse bug estava no ponto de encontro entre o gerenciamento de contexto do Claude Code, a API da Anthropic e o thinking estendido
  • Ele passou por revisão de código feita por várias pessoas e por revisão de código automatizada
  • Por testes unitários e testes end-to-end
  • E até por validação automatizada e dogfooding
• Como esse problema só ocorria no caso extremo de sessões antigas e era difícil de reproduzir, levou mais de uma semana para encontrar e confirmar a causa raiz
• Durante a investigação, os pull requests que causaram o problema foram submetidos a backtest com o Code Review no Opus 4.7
  • Quando o repositório de código necessário para reunir todo o contexto foi fornecido junto, o Opus 4.7 encontrou o bug
  • O Opus 4.6 não encontrou
• Para evitar a repetição do mesmo problema, está sendo introduzido no code review o suporte para incluir repositórios adicionais como contexto
• Esse bug foi corrigido na v2.1.101 em 10 de abril
• Essa mudança afetou o Sonnet 4.6 e o Opus 4.6

Mudança no prompt de sistema que tentava reduzir a verbosidade

• O modelo mais recente, Claude Opus 4.7, tem a característica de produzir saídas muito verbosas em comparação com modelos anteriores
  • Essa característica também foi abordada no anúncio de lançamento, e mais detalhes podem ser vistos em wrote about
• Essa verbosidade o torna mais inteligente em problemas difíceis, mas também aumenta a quantidade de tokens de saída
• Desde algumas semanas antes do lançamento do Opus 4.7, o Claude Code vinha sendo ajustado para o novo modelo
  • Cada modelo se comporta de forma um pouco diferente, então antes do lançamento o harness e o produto são otimizados por modelo
• Para reduzir a verbosidade, foram usados em conjunto treinamento do modelo, prompting e melhorias de UX de thinking dentro do produto
• Entre essas mudanças, uma linha adicionada ao prompt de sistema teve impacto excessivo na inteligência do Claude Code
  • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
• Como não apareceu regressão em semanas de testes internos e nos conjuntos de avaliação executados, essa mudança foi considerada confiável e implantada em 16 de abril junto com o Opus 4.7
• Depois, no processo de investigação, foi realizada uma ablation usando um conjunto mais amplo de avaliações para isolar e verificar o impacto de cada linha do prompt de sistema
• Em uma dessas avaliações, foi confirmada uma queda de 3% tanto no Opus 4.6 quanto no 4.7
• Esse prompt foi revertido imediatamente como parte da release de 20 de abril
• Essa mudança afetou o Sonnet 4.6, Opus 4.6 e Opus 4.7

Mudanças daqui para frente

• Para evitar problemas semelhantes, mais pessoas da equipe interna passarão a usar exatamente o mesmo Claude Code do build público
  • A medida busca reduzir a diferença entre a versão interna usada para testar novos recursos e o build público real
• A ferramenta interna de Code Review será aprimorada, e essa versão melhorada também será disponibilizada aos clientes
• Mudanças em prompts de sistema passarão a ter procedimentos de controle mais rigorosos
  • Para toda mudança em prompt de sistema do Claude Code, serão feitas avaliações amplas por modelo
  • Também continuarão as ablations para entender o impacto de cada linha
  • E estão sendo construídas novas ferramentas para facilitar revisão e auditoria de mudanças de prompt
• Será adicionada ao CLAUDE.md uma orientação para que mudanças específicas de modelo se apliquem apenas àquele modelo
• Toda mudança que possa conflitar com inteligência passará a incluir soak period, conjuntos de avaliação mais amplos e rollout gradual, para detectar problemas mais rapidamente
• Foi criada a conta @ClaudeDevs no X para explicar com mais detalhes as decisões de produto e seu contexto, e as mesmas atualizações também serão compartilhadas em uma thread centralizada no GitHub
• Informações enviadas pelo comando /feedback ou por exemplos específicos e reproduzíveis online ajudaram a identificar e corrigir os problemas
• A zeragem dos usage limits de todos os assinantes também foi aplicada novamente nesse dia

[GN⁺]

Comentários do Hacker News

• A explicação de que, em sessões ociosas por mais de 1 hora, removeram o thinking antigo para reduzir a latência não me convence muito
  Eu costumo deixar uma sessão parada por horas ou até dias e depois continuar usando com o contexto inteiro preservado, então esse recurso era essencial para mim
  Até dá para entender em parte terem reduzido o nível padrão de thinking, mas essa parte de o prompt do sistema continuar mudando parece algo em que eu precisaria entender para poder escolher intencionalmente o ciclo de refresh

  • No Claude Code, se há N mensagens numa conversa, normalmente N-1 mensagens entram no prompt cache, exceto a mais recente
    O problema é que, se a sessão ficar idle por mais de 1 hora, quando o prompt é enviado de novo as N mensagens acabam dando cache miss
    Esse corner case aumentava demais o custo de tokens para o usuário e, em casos extremos, se o contexto tivesse 900k tokens, ao voltar era preciso gravar mais de 900k tokens de novo no cache, o que consumia bastante o rate limit especialmente para usuários Pro
    Então tentaram educar os usuários em lugares como o X, colocaram várias dicas no produto recomendando usar /clear ao voltar para conversas antigas e também testaram omitir resultados antigos de tools, mensagens antigas e partes do thinking depois de um período idle; entre essas opções, remover o thinking teve o melhor desempenho
    No processo de lançar isso, entrou sem querer o bug mencionado no blog, e disseram que responderiam mais perguntas se houvesse
  • Surpreende ver uma empresa avaliada em centenas de bilhões de dólares tomar uma decisão dessas
    Ou realmente acreditaram que valia mais reduzir a latência de sessões idle mesmo sacrificando a qualidade da saída, ou então o objetivo real era reduzir custos e o blog usou latência como justificativa plausível
    Teria sido muito mais natural apenas mostrar de forma mais clara um indicador de carregamento enquanto o contexto fosse recarregado
  • Isso é bem chocante
    Antes eu usava o CC como se fosse um colega: deixava ele pensando um pouco sobre um problema, atualizava o plano, refletia no banho e depois voltava com novos conselhos, e considerava que pelo menos um dia inteiro era uma conversa estática
    Mas, se o limite é 1 hora, é curto demais e me faz repensar se continuo pagando o plano da Anthropic
  • A explicação de remover tokens após 1 hora parece ainda mais suspeita porque esse tempo coincide exatamente com o limite de cache deles
    Parece mais provável que tenha sido uma mudança para reduzir muito os custos do que uma coincidência
  • Isso também deve interagir da pior forma possível com o reset de uso baseado em tempo
    Se muita gente deixa a sessão descansar depois de bater o limite e volta depois, isso não é exceção; está bem perto de ser o padrão de uso

• É meio surpreendente ver tanta pancada assim
  O texto em si era relativamente claro e honesto e soava plausível o bastante
  A piora de desempenho foi real e irritante, mas ao mesmo tempo também expôs a falta de transparência do que exatamente acontece por trás e a estrutura arbitrária de cobrança por tokens
  Para quem já trabalhou diretamente com APIs de LLM, era óbvio que retomar uma conversa deixada de lado por muito tempo geraria custo extra e latência, mas no TUI isso realmente poderia ser comunicado de forma mais visível

  • As pessoas estão irritadas porque durante meses disseram publicamente que não havia problema nenhum
    Por isso, mesmo agora com a explicação, a reação continua negativa

• Acho que parte da percepção de queda de qualidade pode não ser o modelo realmente pior, mas sim a não determinismo
  Algumas semanas atrás pedi ao Claude para criar um app pessoal de produtividade, descrevi em um texto longo o comportamento que eu queria e pedi que escrevesse um plano de implementação; o primeiro resultado foi excelente, exceto por uma parte ambígua
  Depois de corrigir essa ambiguidade, tentei de novo do zero em um novo chat sem mandar revisar o plano anterior; a configuração do modelo era a mesma, mas o resultado foi muito pior, e as duas tentativas seguintes também falharam; só na quarta tentativa voltou ao nível da primeira
  Então fiquei com a impressão de que simplesmente pedir de novo a mesma tarefa às vezes pode ser uma forma de conseguir uma saída melhor, embora isso possa ficar caro bem rápido quando se paga com os próprios tokens

  • Eu vejo algo parecido
    Existe um padrão em que parece que o modelo piora periodicamente, mas talvez na prática só demore mais para bater fundo nas próprias limitações
    E, depois que você passa por uma saída ruim por azar, é só isso que você começa a enxergar dali em diante
  • Dá até a impressão de que vamos acabar fazendo como em geração de imagem: pedir 50 versões do mesmo prompt e deixar um humano escolher manualmente a melhor
    Para a Anthropic, esse padrão de uso também seria ótimo, já que aumenta o consumo de tokens
  • Se era um app de produtividade tão low-stakes assim, talvez fazer você mesmo teria sido mais rápido do que o tempo gasto nisso
  • Talvez essa situação tenha servido para mostrar que os LLMs são muito mais não determinísticos do que parece, mas ligar isso diretamente à queda recente de desempenho pode ser um erro
    O não determinismo sempre existiu; a queda recente de qualidade amplamente relatada pode ser um fenômeno separado

• Eu já tinha perdido o entusiasmo no Opus 4.7
  A OpenAI está tentando entrar de forma muito agressiva no nosso lado enterprise e ofereceu até tokens ilimitados até o verão
  Então passei os últimos 30 dias usando o GPT5.4 com extra high effort e, não sei se é tratamento especial ou não, mas quase não vi erros
  O reasoning trace às vezes era tão bom que chegava a ser engraçado, e ele até antecipava partes que eu tinha esquecido de pedir e cuidava dos elementos necessários para manter 100% de integridade dos dados

  • Tenho uma impressão parecida
    Todo esse tipo de mudança meio ardilosa talvez venha do fato de a Anthropic estar muito limitada em compute e acabar forçando a barra para reduzir consumo
  • O GPT-5.4 já era melhor que o Opus 4.6 em várias áreas, especialmente em precisão e lógica mais complicada
    Então fico curioso para ver o quanto o 5.5 vai melhorar
  • extra high queima tokens demais
    Em 90% dos trabalhos, usar o 5.4 em medium é muito melhor em foco e minimiza mudanças; só subo para high quando medium claramente não dá conta
  • Concordo
  • Eu voltei para o 4.5 e não me arrependo
    Além disso, é um pouco mais barato

• Ultimamente o Claude tem produzido com frequência respostas como se estivesse respondendo ao próprio prompt interno
  Por exemplo, diz que um texto entre parênteses seria uma tentativa de prompt injection e que por isso vai ignorá-lo, ou que parece uma tentativa de esconder suas diretrizes gerais e por isso não vai obedecer, ou ainda que esse tipo de abordagem já é coberto pelas regras normais e portanto é desnecessário
  Eu nunca fiz nada disso, mas ele vive acrescentando esse tipo de frase no fim das respostas
  Parece que existe alguma parte mal feita nas diretrizes internas e que ele não consegue distingui-la direito das minhas perguntas

  • Eu uso stop hook scripts para obrigar a execução de testes a cada mudança de código, mas desde a 4.7 o Claude executa os scripts e ainda assim ignora as regras periodicamente
    Quando pergunto por quê, ele responde que achou que não era necessário
  • Vi algo parecido também na OpenAI, em que o modelo responde às próprias falas
    Parece até um jeito fácil de as empresas aumentarem o token churn
  • Também vejo com frequência o modelo colocar pontos que ele mesmo criou na memória e depois referenciá-los como se fossem afirmações minhas
    Aí surge um ciclo de auto-reforço em que o modelo afirma algo, salva isso como memória e depois volta nessa memória para empilhar mais coisas, e às vezes continua mesmo quando eu peço explicitamente para parar
  • Fiquei curioso sobre o nível de effort e o prompt real
    Isso pode ser um sintoma de reasoning effort alto demais, então talvez reduzir um pouco a intensidade de raciocínio nesse prompt específico já melhore
  • Eu deixo o Claude fazer commits e até PRs com frequência, e na semana passada vi várias vezes ele inventando trabalho extra desnecessário durante o processo de commit
    Travou na etapa de git add, mas no modo automático uma vez quase passou direto

• O fato de terem reduzido o reasoning effort padrão de high para medium porque a latência era tão grande que a UI parecia travada torna isso ainda mais suspeito
  Isso implica que, em vez de corrigirem a UI, primeiro reduziram a intensidade padrão de raciocínio, e por isso é difícil acreditar facilmente na explicação de que estavam acompanhando seriamente os relatos de queda de desempenho

  • O time disse que fez as duas coisas
    Melhoraram o estado de carregamento do thinking e mexeram várias vezes na UI, inclusive deixando mais clara a quantidade de tokens sendo baixada
    Mesmo assim, depois de evals e dogfooding decidiram baixar o effort padrão, mas reconheceram que foi uma decisão errada e já reverteram
    Também admitiram que muita gente ficava no padrão porque não entendia bem que precisava usar /effort para elevar a inteligência, e que deveriam ter previsto isso

• Dizer que sessões idle por mais de 1 hora são corner case não combina em nada com meu padrão de uso
  Em trabalho pessoal, eu peço ao Claude Code muitas tarefas de 10 a 15 minutos e gasto bastante tempo trocando ideias com o modelo sobre o plano antes de executar
  Quando a execução começa, costumo ir tomar um café ou trabalhar em outro projeto com o Codex, então é bem provável que eu leve mais de 1 hora para voltar ao Claude

  • Provavelmente isso só é corner case na cabeça dos desenvolvedores
    Confundir os próprios hábitos com o comportamento de todos os usuários é um erro clássico de desenvolvimento de produto
  • Isso também soa como se, ao fazer uma mudança tão grande, eles não tivessem validado o suficiente justamente esse caso de borda, o que levanta dúvidas sobre o rigor dos testes

• A abordagem de caixa-preta adotada pelos grandes frontier labs no fim vai afastar as pessoas
  Se continuam mudando o funcionamento fundamental sem avisar antes e só explicam depois, os usuários inevitavelmente vão migrar para modelos self-hosted
  Não dá para construir pipelines, fluxos de trabalho e produtos com estabilidade sobre uma base que continua tremendo o tempo todo

• Parece que o pessoal da Anthropic responsável pelo Claude Code lê os comentários, então vale dizer: há alguns dias vi um vídeo do theo t3.gg sobre se o Claude ficou burro
  O tom era agressivo e ele exagerou em algumas falas, mas especialmente as críticas sobre harness bloat me pareceram bastante corretas
  Acho que agora é hora de parar um pouco de adicionar recursos novos e pressionar forte por polimento e otimização
  Caso contrário, mais gente vai procurar alternativas mais leves e otimizadas, e o ponto central é melhorar o harness e reduzir o consumo de tokens
  https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

  • Independentemente de todo o resto, só o experimento de tirar o suporte ao CC do plano Pro já me fez pensar seriamente em alternativas
    Eu já tomava cuidado com vendor lock-in, mas aquilo foi um bom alerta e provavelmente vou olhar primeiro para opencode+openrouter
  • Nunca se deve esquecer o vídeo exagerado sobre o GPT 5 do theo e o fato de ele depois ter voltado atrás
    Parece bem claro que existe algum tipo de troca de dinheiro ou influência nos bastidores entre certos criadores de conteúdo e a OpenAI
  • Para ser sincero, isso tudo parece algo que daria para resolver com um simples git reset --hard

• Isso parece consequência de uma obsessão com adicionar recursos em vez de aperfeiçoar o produto principal
  Muitas vezes tenho a impressão de que a Anthropic precisaria de mais alguns líderes seniores de produto e de uma visão parecida com a de “Escaping the Build Trap”
  Só porque agora conseguem adicionar recursos rapidamente não significa que devam fazer isso
  Não estou citando um livro famoso para repetir clichês de organização de produto; é só que bom senso de produto é um talento diferente de boa engenharia, e a Anthropic parece estar em falta nessa área ultimamente

  • Eles precisam acompanhar a demanda e claramente parecem estar com falta de recursos de compute
    Então talvez não tivessem muita escolha, porque sem esse tipo de recurso o sistema quebraria ou deixariam de aceitar novos clientes, e ambas as opções seriam difíceis de aceitar
  • Já foi um lugar onde cerca de 100 desenvolvedores recebiam US$ 600 mil por ano, então falta de talento provavelmente não é o problema
    Talvez o problema seja empurrar demais a narrativa de vibe coding, e dizem que isso inclusive faz alguns candidatos recusarem entrevistas
  • Parece que já caíram fundo na armadilha da complexidade
    A natureza probabilística do modelo já é um problema por si só, mas agora parece que eles mesmos já não conseguem raciocinar direito sobre o próprio software
    Há alavancas e controles demais, e é bem possível que ninguém entenda o código por completo
    Pior ainda, pelas falas do Dario e outros, a liderança parece não ter muita empatia com essas preocupações de qualidade
    Dá a impressão de que, sob a visão de que SWEs são substituíveis, pedidos por guard rails nas ferramentas acabam ignorados ou até desencorajados, e no fim o Claude Code desde o começo teve mais cara de experimento científico do que de produto maduro com best practices consolidadas