Benchmark diário para rastrear degradação de desempenho do Claude Code

 (marginlab.ai)
9 pontos por GN⁺ 2026-01-30 | 2 comentários | Compartilhar no WhatsApp
  • Sistema de rastreamento que mede diariamente o desempenho do Claude Code Opus 4.5 em tarefas de SWE para detectar degradação de desempenho estatisticamente significativa
  • Usa um subconjunto selecionado do SWE-Bench-Pro para avaliar 50 instâncias de teste por dia, e os resultados refletem o desempenho real do modelo executado diretamente em um ambiente CLI
  • Nos últimos 30 dias, foi detectada uma taxa média de aprovação de 54% e uma queda estatisticamente significativa de 4,1% em relação à linha de base de 58%
  • Os resultados diários e semanais são analisados com base em intervalos de confiança de 95% e limiares de significância (±14,0%, ±5,6%), distinguindo variações de curto prazo de tendências de longo prazo
  • Operado por uma instituição independente terceirizada, é uma ferramenta para detectar precocemente degradação de desempenho causada por mudanças no modelo ou no ambiente de execução

Visão geral

  • O objetivo deste rastreador é detectar degradação estatisticamente significativa no desempenho do Claude Code Opus 4.5 em tarefas de SWE
    • A avaliação é realizada diariamente usando um subconjunto resistente à contaminação do SWE-Bench-Pro
    • É executado diretamente no Claude Code CLI, refletindo o ambiente real do usuário sem um harness customizado separado
  • Trata-se de uma instituição independente terceirizada, sem afiliação com provedores de modelos de fronteira
  • Após o postmortem da Anthropic relacionado à degradação de desempenho em setembro de 2025, passou a ser operado como um recurso para detectar precocemente casos semelhantes no futuro

Resumo de desempenho

  • Taxa de aprovação da linha de base: 58%
  • Taxa de aprovação dos últimos 30 dias: 54% (com base em 655 avaliações)
  • Taxa de aprovação dos últimos 7 dias: 53% (com base em 250 avaliações)
  • Taxa de aprovação do último 1 dia: 50% (com base em 50 avaliações)
  • A degradação de desempenho em 30 dias é estatisticamente significativa no nível p < 0,05
    • Variação em 30 dias: -4,1%
    • Limiar de significância: ±3,4%
  • As variações de 1 dia (-8,0%) e 7 dias (-4,8%) não são estatisticamente significativas

Tendências diárias e semanais

  • Tendência diária (Daily Trend)
    • Visualiza as taxas de aprovação diárias dos últimos 30 dias
    • Linha de base de 58%, faixa de limiar de significância de ±14,0%
    • É possível exibir intervalos de confiança de 95%; quanto menor a amostra, mais amplo o intervalo
  • Tendência semanal (Weekly Trend)
    • Fornece uma tendência suavizada da volatilidade diária por meio de uma média móvel de 7 dias
    • Linha de base de 58%, faixa de limiar de significância de ±5,6%
    • Da mesma forma, é possível exibir intervalos de confiança de 95%

Visão geral das mudanças (Change Overview)

  • Mudança em 1 dia (em relação a ontem): -8,0%, não estatisticamente significativa
    • Com base em 50 avaliações, é necessária uma variação de ±14,0% (p < 0,05)
  • Mudança em 7 dias (em relação à semana passada): -4,8%, não estatisticamente significativa
    • Com base em 250 avaliações, é necessária uma variação de ±5,6% (p < 0,05)
  • Mudança em 30 dias (em relação ao mês passado): -4,1%, estatisticamente significativa
    • Com base em 655 avaliações, é necessária uma variação de ±3,4% (p < 0,05)

Metodologia

  • Cada teste é modelado como uma variável aleatória de Bernoulli, e intervalos de confiança de 95% são calculados
  • As diferenças estatísticas nas taxas de aprovação diárias, semanais e mensais são analisadas para reportar se há degradação de desempenho significativa
  • A avaliação é realizada com 50 instâncias de teste por dia, então existe volatilidade de curto prazo
  • Os resultados agregados semanais e mensais fornecem estimativas mais estáveis
  • É possível detectar tanto degradação de desempenho causada por mudanças no modelo quanto por mudanças no harness de execução

Função de alerta

  • Se a degradação de desempenho for detectada estatisticamente, um alerta por e-mail é enviado
  • Os usuários podem se inscrever registrando um endereço de e-mail
  • Após a confirmação da inscrição, é possível receber alertas; em caso de erro, há orientação para tentar novamente

Leituras relacionadas

2 comentários

 
iolothebard 2026-01-31

Não é que o Claude Code tenha ficado mais burro… talvez seja porque quem usa tenha aprendido a aproveitar melhor o Claude…
 
GN⁺ 2026-01-30
Comentários do Hacker News

  • Sou Thariq, da equipe do Claude Code
    Corrigimos o problema no harness que ocorreu em 26 de janeiro. Também fizemos o rollback em 28 de janeiro, então recomendamos atualizar para a versão mais recente com o comando claude update

    • A versão 2.1.x do Claude trava com frequência ou usa 100% da CPU, a ponto de ficar praticamente inutilizável. Há uma issue relacionada em GitHub #18532
    • O Claude desperdiçou tokens, então quero saber se haverá alguma compensação por isso
    • Quero entender melhor o que exatamente significa “harness issue” e que impacto isso teve
    • O problema já existia antes de 26 de janeiro. Foi nessa época que o Claude começou a alterar planos por conta própria dizendo que estava “melhorando”
    • Mais do que o modelo em si, tenho curiosidade sobre o sistema de controle de qualidade. Fico em dúvida se existe algum processo interno para inspecionar regularmente amostras reais de saída ou monitorar degradação de desempenho com benchmarks. Do ponto de vista de segurança em IA, esse tipo de verificação também é essencial

  • Sou coautor do SWE-bench
    Pelo que parece, o teste atual roda apenas uma vez por dia e só em 50 tarefas. Para aumentar a precisão, seria melhor testar 300 tarefas de 5 a 10 vezes por dia e tirar a média. Fatores aleatórios como carga do servidor podem afetar muito o resultado

    • A degradação causada por sobrecarga do servidor também não deveria entrar na medição? A menos que a intenção seja medir apenas destilação do modelo
    • Imagino que o problema seja o custo de executar o modelo. Seria bom se a Anthropic oferecesse algum crédito de apoio, ou abrisse um link para doações
    • A diferença de desempenho ao longo dos horários do dia pode ser ainda maior
    • Há a preocupação de que o custo para rodar o SWE-bench seja alto demais, dificultando executar o suficiente. mafia-arena.com está enfrentando um problema parecido
    • É estranho dizer que “o servidor está sobrecarregado, então a medição não é precisa”. Nesse caso, existe pelo menos algum horário comercial em que o Claude funcione bem?

  • Um resumo de por que não acredito que a Anthropic esteja entregando um modelo pior aos usuários

    1. A queda de acurácia é pequena e oscila em forma de flutuação
    2. Não há referência de comparação com o Sonnet 4.5, e sob carga de GPU o Opus pode cair ao nível do Sonnet
    3. É bem provável que estejam fazendo testes A/B com vários checkpoints. Atualizações da versão do Claude Code ou a não determinismo da amostragem de tokens também podem ser a causa
    • Entendo a explicação científica, mas usando todo dia dá claramente a sensação de que o desempenho está piorando
    • Também acho que testes A/B são a principal causa. Seria bom divulgar com transparência coisas como limites da janela de contexto ou mudanças no prompt de sistema. O ideal seria permitir que o usuário escolhesse a versão diretamente e desse feedback
    • Fico curioso sobre por que o gráfico começa em 8 de janeiro. Talvez aquele tenha sido um dia anormalmente alto
    • Também pode haver uma estrutura que ajusta automaticamente a relação desempenho-custo conforme a carga. Talvez comece com alto desempenho e, aos poucos, reduza o modelo para economizar custo, ou diminua o número de especialistas em um MoE
    • A afirmação de que “a queda é pequena demais” é apenas um julgamento subjetivo que ignora significância estatística

  • A metodologia estatística é estranha
    Eles consideram apenas o intervalo de confiança do valor anterior e verificam se o novo valor está fora dele, mas isso não é a forma correta de testar a significância estatística da diferença. Como ambas as medições têm incerteza, é preciso calcular o intervalo de confiança da própria diferença. Além disso, se a comparação é mensal, então seria necessário comparar dados de 60 a 31 dias atrás com os dados de 30 dias atrás até ontem, então o gráfico deveria mostrar pelo menos dois meses

  • Cerca de uma semana atrás, o Claude ficou fora do ar por aproximadamente uma hora. Logo depois da recuperação, talvez porque o número de usuários tivesse caído, a velocidade ficou mais de 3 vezes maior. Naquela uma hora consegui fazer o que normalmente levaria meio dia. Foi como ter um vislumbre de um futuro sem restrições de recursos

    • Durante o feriado nos EUA, as limitações de uso também foram afrouxadas e tudo funcionou muito mais suavemente
    • Tive a mesma experiência há alguns dias. Ficou tão rápido que cheguei a pesquisar por “claude speed boost”. Foi uma velocidade relâmpago momentânea, como na época dos upgrades de modem
    • Quando fica rápido demais, dá até uma certa pena. Agora pelo menos parece que o modelo está trabalhando duro

  • Se medirem a frequência de palavrões nos prompts dos usuários, talvez dê para detectar o aumento da hostilidade quando o desempenho do modelo piora

    • Mas existe alguma forma de simplesmente escanear os prompts dos usuários do Claude?
    • Há uma correlação de aumento de palavrões logo após pedidos de feedback como “How’s Claude Doing This Session?”
    • Eu já falo palavrão com frequência, então meus dados podem ficar enviesados
    • Fico aliviado em saber que não sou o único
    • Às vezes sai palavrão quando ele dá uma resposta burra demais. É uma reação causada por expectativas altas

  • Há a possibilidade de irem quantizando o modelo gradualmente com o tempo. Isso facilitaria escalabilidade e redução de custos, além de fazer novas versões parecerem “melhores”

    • Uso de 5 a 10 horas por dia, e na última semana ficou claramente a sensação de que ele ficou mais burro. Mesmo que neguem, a mudança é perceptível no uso
    • Nem precisariam quantizar; também daria para reduzir carga com encurtamento do comprimento da conversa ou redução do tempo de inferência
    • Modelos abertos como GPT-OSS e Kimi K2.x também foram treinados com camadas de 4bit. O Opus 4.5 custa 8 vezes mais por token, então é provável que seja um modelo maior, mas é difícil comparar de forma simples por causa da estrutura de preços por assinatura
    • A Anthropic não parece ser uma empresa tão limitada por custos de infraestrutura assim. Em um cenário de competição acirrada, reduzir qualidade de propósito seria uma má estratégia. Talvez os usuários só estejam percebendo melhor os defeitos depois do efeito lua de mel passar
    • Ainda assim, uma estratégia dessas de degradação gradual parece totalmente possível. Ela poderia maximizar o efeito de melhoria relativa de um novo modelo

  • No modo API, quando o Claude passa de certa quantidade de tokens, ele de repente fica mais burro e começa a fazer coisas sem sentido, como dizer “há um bug na linha 23” e então apagar a funcionalidade inteira. Falha até em correções simples que até o ChatGPT 3.5 conseguiria fazer. Não entendo por que isso acontece

    • Provavelmente por causa de restrições de recursos. Em vez de dar ótimas respostas a alguns usuários, podem ter optado por dar respostas razoáveis para mais gente
    • Tive a mesma experiência. Tenho a sensação de que o Claude está ficando cada vez mais preguiçoso

  • Na última semana, a qualidade do código do Claude piorou de forma perceptível. Por exemplo, ele sugeriu usar frozen em um Enum, ou recomendou urlparse de novo em uma função que já usava urlparse. Antes ele não cometia esse tipo de erro básico

  • Minha grande reclamação com provedores de LLM é a falta de consistência na capacidade de raciocínio. Com o ChatGPT acontece o mesmo: acima de 45k tokens de entrada, a inteligência despenca ou a entrada é truncada. Seria melhor simplesmente receber uma mensagem de “recusa” do que sofrer um downgrade oculto, porque isso destrói a confiança. Transparência é realmente importante