A Anthropic Nerfou o Opus 5.5? Um Dev Fez o Benchmark pra Descobrir

Toda vez que uma empresa de IA lança um modelo novo, o ciclo é o mesmo: euforia, benchmarks impressionantes, migração em massa. Duas semanas depois, os fóruns enchem de gente reclamando que “o modelo piorou”. Placebo? Frustração legítima? Até agora, era impossível saber.

O Claude Opus 5.5 caiu na mesma armadilha. Lançado em 22 de setembro de 2026 com números absurdos (67,7% no Humanity’s Last Exam, 66,4% no Terminal-Bench 4.0, preço 40% menor que o Opus 5), ele virou o modelo queridinho da comunidade dev. Mas bastaram poucos dias para as reclamações surgirem no X: respostas mais curtas, recusas desnecessárias, raciocínio raso. O mesmo roteiro que vimos com o GPT-4, com o GPT-6 Astra e com praticamente todo modelo de grande porte dos últimos três anos.

Dessa vez, porém, alguém resolveu parar de reclamar e começar a medir.

O projeto que ninguém pediu (mas todo mundo precisava)

Um desenvolvedor conhecido como ninjahawk publicou no GitHub o livenerf, um benchmark open source desenhado com um único objetivo: responder com dados se o Claude Opus 5.5 foi nerfado após o lançamento.

A ideia é simples na superfície, mas sofisticada na execução. O livenerf roda 78 perguntas contra o Opus 5.5 todos os dias, durante 30 dias consecutivos. Essas perguntas foram selecionadas de um pool inicial de 2.336 questões extraídas do GPQA Diamond, MMLU-Pro, competition-math e AIME 2025/2026. A seleção não foi aleatória: entraram apenas as perguntas que o Opus 5.5 acerta de forma inconsistente, ou seja, as que revelam variação real de capacidade.

Se o modelo mantiver a performance, as 78 perguntas vão flutuar dentro de uma margem estatística previsível. Se a Anthropic alterar o modelo (via quantização, swap de pesos, redução de esforço computacional ou roteamento para versões mais baratas), os números vão mostrar.

Como funciona por dentro

O que diferencia o livenerf de benchmarks amadores é o rigor metodológico. Eu já vi dezenas de “provas” de nerfing no X que não passam de um screenshot de uma conversa ruim. Isso não prova nada. O livenerf ataca o problema de forma diferente:

Testes herméticos. Os prompts são congelados. A versão do CLI é fixada. Os avaliadores são funções puras, sem nenhum modelo de IA envolvido na correção. Isso elimina a variável mais traiçoeira de benchmarks caseiros: o avaliador mudar junto com o avaliado.

Comparações pareadas. As mesmas perguntas se repetem semanalmente contra suas próprias baselines. Não é “o modelo acertou X% das perguntas difíceis”, é “o modelo acertou X% das mesmas perguntas que acertou na semana passada”. A diferença parece sutil, mas elimina completamente o viés de dificuldade variável entre rodadas.

Braço de controle duplo. Aqui fica interessante. O painel principal rastreia o Opus 5.5, mas um braço paralelo roda o Opus 5 (versão anterior) pela mesma infraestrutura. Se os dois modelos caírem ao mesmo tempo, o problema é de plataforma, não de modelo. Se só o 5.5 cair, aí sim temos evidência de nerfing.

Rigor estatístico. O livenerf usa erros padrão clusterizados, seguindo a própria metodologia publicada pela Anthropic. É como usar as regras do adversário contra ele.

O que os primeiros resultados dizem

A primeira rodada de reteste rodou poucos dias após o lançamento, e o resultado foi: 99,2% de precisão relativa ao dia do lançamento, uma queda de 0,8 ponto percentual. Dentro da variância normal.

Traduzindo: até agora, o Opus 5.5 não foi nerfado. Pelo menos não de forma mensurável.

Mas o livenerf tem uma segunda camada de detecção que vai além da acurácia. O projeto monitora a contagem de tokens de saída como sistema de alerta precoce. A lógica é que, se a Anthropic reduzir o esforço de raciocínio do modelo (uma forma comum e silenciosa de cortar custos), os tokens de pensamento vão diminuir antes da acurácia cair. O modelo começa a “pensar menos” antes de começar a “errar mais”.

Essa sensibilidade permite detectar mudanças de aproximadamente 7,5 pontos de acurácia por janela de 10 dias. Não vai pegar um downgrade microscópico, mas pega qualquer coisa relevante.

O histórico que alimenta a paranoia

Se a comunidade dev é paranoica sobre nerfing, não é sem motivo. Existem casos documentados.

O mais famoso é o paper de Stanford e Berkeley publicado em 2023 por Lingjiao Chen, Matei Zaharia e James Zou. Os pesquisadores compararam o GPT-4 de março e junho de 2023 em tarefas idênticas. O resultado chocou: na identificação de números primos, o GPT-4 de março acertava 97,6%. Em junho, o mesmo modelo, mesma tarefa: 2,4%. Uma queda de 95 pontos percentuais.

A OpenAI inicialmente negou qualquer mudança. Depois admitiu que fazia “atualizações silenciosas”. E por fim, em pelo menos um caso, fez rollback de uma atualização após confirmar que o feedback de curto prazo dos usuários tinha sido pesado demais durante um fine-tuning.

Não foi só o GPT-4. O GPT-6 Astra, lançado em 3 de setembro de 2026, acumulou reclamações em questão de dias: raciocínio mais curto, instruções ignoradas, completude prematura de tarefas. A Remio.ai publicou uma análise detalhada mostrando que, embora as reclamações sejam reais, a evidência de downgrade intencional permanece não comprovada.

O padrão é sempre o mesmo: empresa lança modelo impressionante, cobra um preço premium, e gradualmente redireciona tráfego para versões mais baratas de servir. Quantização pós-treinamento, destilação para modelos menores, roteamento condicional baseado no tipo de query. Todas técnicas legítimas de engenharia, mas que, se aplicadas sem transparência, configuram o que a comunidade chama de “nerfing”.

As quatro causas técnicas do nerfing (real ou percebido)

Nem todo nerfing é malícia corporativa. Na verdade, a maioria provavelmente não é. Existem razões técnicas legítimas pelas quais um modelo pode performar pior semanas após o lançamento.

O livenerf é especialmente bom em detectar as duas primeiras. Quantização e roteamento afetam a acurácia de forma mensurável. Drift de dados e atualizações de safety são mais difíceis de capturar com benchmarks fixos, porque o benchmark em si não muda.

Vale lembrar que quantização nem sempre é ruim. Ir de FP32 para FP16 quase não afeta qualidade e corta custo de memória pela metade. O problema começa quando a compressão vai além: INT8, INT4, GPTQ agressivo. Cada passo remove nuance do modelo, e em tarefas que exigem raciocínio longo (como debug de código ou provas matemáticas), essa perda de resolução numérica aparece primeiro.

Por que isso importa pra quem escreve código

Se você usa Claude (ou qualquer LLM) como ferramenta de desenvolvimento, a estabilidade do modelo é uma feature, não um detalhe. Eu já vi equipes inteiras migrarem de modelo porque “o Copilot parou de funcionar direito”, sem saber se o modelo realmente mudou ou se o prompt deles é que era frágil.

O livenerf introduz uma prática que deveria ser padrão na indústria: monitoramento contínuo de capacidade. Não confiança cega no provider, não reclamação anedótica no X. Dados.

Pensa assim: você monitora o uptime dos seus servidores, a latência das suas APIs, o tempo de resposta do seu banco de dados. Por que não monitorar a qualidade do modelo de IA que gera metade do seu código?

Algumas equipes já fazem isso internamente. Rodam um subset de testes de regressão contra o modelo toda semana. Se a taxa de acerto cair abaixo de um threshold, trocam de modelo ou congelam a versão. É engenharia básica, mas que pouquíssimas empresas aplicam à camada de IA.

O problema da confiança sem contrato

Tem um detalhe incômodo que o livenerf expõe, mesmo sem querer. Quando você contrata uma API de IA, o SLA cobre uptime e latência. Ninguém garante qualidade de resposta.

A Anthropic pode, tecnicamente, trocar o modelo por trás do endpoint claude-opus-5-5-20260922 por uma versão quantizada, destilada ou de menor esforço, e o contrato continua valendo. Você paga por tokens processados, não por inteligência entregue.

É como contratar uma consultoria que garante que vai responder seus emails em 24 horas, mas não garante que as respostas vão ser úteis.

O livenerf torna essa assimetria visível. E por isso incomodou tanta gente no Hacker News, onde a thread passou de 260 comentários. Porque o problema não é só técnico. É de incentivos: empresas de IA têm um incentivo financeiro direto para reduzir custo de inferência após capturar a base de usuários com benchmarks de lançamento.

A psicologia do nerf: por que achamos que o modelo piorou

Existe um fenômeno que todo dev que usa LLM já experimentou: você tem uma sessão incrível com o modelo, resolve um problema complexo, e na próxima vez que abre o chat, a resposta é medíocre. O instinto imediato é “nerfaram o modelo”.

Mas a VentureBeat publicou uma análise em setembro de 2026 mostrando que a maioria dos relatos de degradação sofre do mesmo problema: falta de controle experimental. As pessoas comparam sessões diferentes, com prompts diferentes, em contextos diferentes, e atribuem qualquer variação ao provider.

Tem também o efeito de adaptação hedônica. Quando o Opus 5.5 lançou e você viu ele resolver um bug que você lutava há horas, a sensação foi de mágica. Na segunda, terceira, décima vez, aquilo virou normal. E quando o modelo erra algo trivial, a decepção é desproporcional porque a baseline de expectativa subiu.

Nada disso significa que nerfing não existe. Significa que provar nerfing requer metodologia, não anedota. E é exatamente isso que o livenerf traz.

O que o BridgeMind encontrou (e o que não encontrou)

Além do livenerf, a empresa BridgeMind publicou seus próprios resultados usando o NerfBench, um benchmark com metodologia similar. O veredito inicial foi alinhado: o Opus 5.5 não mostra sinais de nerfing na primeira semana.

Mas o BridgeMind adicionou uma observação que vale citar: a ausência de evidência nos primeiros dias não é garantia de estabilidade futura. O padrão histórico mostra que downgrades costumam acontecer entre 2 e 8 semanas após o lançamento, quando a atenção da mídia diminui e o volume de uso estabiliza.

O livenerf vai rodar por 30 dias. Se o Opus 5.5 sobreviver esse período inteiro sem degradação mensurável, será a primeira vez que um modelo de fronteira passa por auditoria pública contínua e sai ileso.

Como rodar o livenerf você mesmo

O projeto é open source e roda com pouca configuração. Se você quer monitorar o modelo que usa na sua stack:

git clone https://github.com/ninjahawk/livenerf.git
cd livenerf
pip install -r requirements.txt

# Configurar API key
export ANTHROPIC_API_KEY="sua-chave-aqui"

# Rodar o benchmark completo
python run_benchmark.py --model claude-opus-5-5-20260922

# Comparar com baseline
python compare.py --baseline results/day1.json --current results/day7.json

Os resultados saem em JSON, com breakdown por categoria (math, reasoning, knowledge, code). Dá pra integrar num dashboard ou num CI pipeline se você quiser automação.

O futuro do monitoramento de IA

O livenerf é um projeto de um dev. Mas ele aponta pra uma necessidade de mercado que ainda não tem solução madura: observabilidade de qualidade de modelos de IA em produção.

Hoje existem ferramentas de monitoramento de LLM (Langfuse, Helicone, Weights & Biases), mas todas focam em métricas operacionais: latência, custo, volume de tokens. Nenhuma responde a pergunta “o modelo ficou mais burro desde terça-feira?”.

O livenerf responde. De forma limitada, com 78 perguntas fixas, mas responde. E se a indústria não criar algo melhor, projetos como esse vão se multiplicar. Porque a confiança do desenvolvedor no provider de IA depende de transparência, e quando a transparência não vem voluntariamente, a comunidade open source cobra.

O Opus 5.5 não foi nerfado. Ainda. O livenerf continua rodando. E se algo mudar, dessa vez vai ter dado.

Agora, se você quer o meu palpite pessoal? A próxima fronteira não é benchmark de acurácia. É benchmark de consistência. Um modelo que acerta 95% das vezes mas varia selvagemente entre sessões é pior que um que acerta 90% de forma previsível. Estabilidade é a feature invisível que ninguém mede e todo mundo sente falta quando some.