LLM Benchmark: Opus 5 é bom?

A Anthropic lançou o Claude Opus 5 ontem. A pergunta óbvia é:

“É bom?”

Resposta curta: sim, é muito bom. No meu benchmark fez 95/100, Tier A, com a engenharia mais completa que apareceu até agora em qualquer um dos harnesses que testei.

Agora a resposta que interessa: não, isso não prova que virou “o melhor LLM do mundo”. Nem prova que é melhor que Fable 5, Opus 4.8, GPT 5.6 Sol ou Kimi K3 em qualquer trabalho que você jogar neles. Semana passada publiquei um artigo inteiro explicando por que a maior nota não significa o melhor modelo. O Opus 5 chegou a tempo de produzir um belo estudo de caso praquele texto.

Onde a Anthropic posiciona o Opus 5

No anúncio oficial, a Anthropic descreve o Opus 5 como um modelo de uso diário que chega perto da inteligência de fronteira do Fable 5, mas custa metade. Ele virou o modelo padrão no Claude Max e o mais forte disponível no Pro.

A escadinha comercial parece simples:

Opus 4.8  <  Opus 5  ≈  Fable 5

Só que nem os dados da própria Anthropic formam uma linha tão limpa. No CursorBench 3.2, em esforço máximo, Opus 5 fica a 0,5% do pico do Fable 5. No Frontier-Bench v0.1, supera todos os outros modelos e mais que dobra o resultado do Opus 4.8 com custo menor por tarefa. No OSWorld 2.0, chega a passar o melhor resultado do Fable por pouco mais de um terço do custo.

Então “entre Opus 4.8 e Fable 5” é um atalho razoável pra entender o produto. Não é uma classificação universal. Dependendo da tarefa e do esforço escolhido, as curvas se cruzam.

O preço é mais objetivo. Opus 5 custa $5 por milhão de tokens de input e $25 por milhão de output, igual ao Opus 4.8. Fable 5 custa $10/$50. Em tarifa de API, Opus 5 entrega a promessa mais interessante do lançamento: comportamento próximo de Fable sem pagar a taxa Fable.

O benchmark

Pra quem caiu de paraquedas, meu LLM Coding Benchmark dá o mesmo problema a todos: construir sozinho um chat estilo ChatGPT em Rails 8, com RubyLLM, Hotwire, Tailwind, testes, CI, Docker e documentação.

Não avalio uma função isolada. Avalio o projeto que saiu no final: se usa a API real do RubyLLM, se multi-turn funciona, se trata falhas do provider, se a conversa persiste, se Turbo Streams está ligado de verdade, se os testes conseguem pegar bugs e se a imagem de produção sobe.

O Opus 5 rodou solo pelo Claude Code headless, com --dangerously-skip-permissions, usando minha assinatura Max. Foram:

• 38m57s
• 201 turnos
• 121 testes e 355 assertions
• 100% de cobertura de linhas e 95,94% de branches
• 22,1 milhões de tokens de cache read
• $16,02 equivalentes em tarifa de API, mas cobrados da assinatura

Isso exige um asterisco. Opus 4.8 e Fable 5 foram testados no OpenCode via OpenRouter. GPT 5.6 Sol rodou no Codex. Kimi K3 rodou no Kimi Code CLI. Coding benchmark mede o pacote inteiro:

modelo + prompt + harness + tools + contexto + execução + auditoria

Por isso o repositório mantém o Opus 5 no perfil de Claude Code em vez de fingir que foi uma comparação perfeitamente controlada com a tabela principal. Aqui vou juntar as 40 linhas do ranking principal com o novo resultado porque todo mundo quer enxergar onde o 95 cai. O asterisco não é enfeite.

Ranking atualizado: tabela principal + Opus 5

* Opus 5 recebeu 95/100 equivalente no perfil Claude Code. A tabela principal do repositório o mantém separado pra deixar a diferença de harness explícita.

O que o Opus 5 escreveu

O score sozinho esconde a parte mais interessante. O projeto do Opus 5 foi o melhor exemplo de engenharia defensiva que apareceu até agora no benchmark.

Ele isolou todo acesso ao RubyLLM num único Assistant::Client, injetou a factory do chat pra testes e verificou a API real da gem antes de depender dela. Além dos mocks de RubyLLM.chat, with_instructions, add_message e ask, criou um teste de guarda que confirma que esses métodos continuam existindo na gem instalada. Se a biblioteca mudar a interface, o CI quebra antes da produção.

A conversa fica atrás de um ConversationRepository em Rails.cache, com TTL de 12 horas e limite de 40 mensagens no replay. Antes de mandar histórico ao provider, normaliza a alternância entre user e assistant, remove respostas que falharam e garante que a janela não começa com uma mensagem de assistant. Parece detalhe até a API rejeitar o payload no segundo turno.

Foi exatamente aí que o modelo encontrou e consertou dois bugs durante o próprio run. Uma resposta que falhou podia deixar duas mensagens de usuário seguidas. Cortar a janela do histórico também podia começar numa resposta do assistant. Ele escreveu os testes, corrigiu e validou multi-turn real, inclusive recuperação depois de uma falha.

Também entregou:

• streaming fora do request principal;
• broadcasts Turbo Streams assinados e limitados a cerca de 10 atualizações por segundo;
• preflight de credencial;
• mensagens diferentes pra chave inválida, rate limit, falta de crédito, contexto estourado e provider indisponível;
• Markdown escapado antes de formatar HTML;
• Dockerfile multi-stage, produção, non-root;
• RuboCop, Brakeman, bundler-audit, importmap audit e GitHub Actions.

Não é 100. Existe uma race de lost update se outra mensagem entrar durante a geração, embora o próprio projeto limite o deploy a WEB_CONCURRENCY=1. Também deixou o modelo padrão em Sonnet 4.6 quando Sonnet 5 já existia, e comitou lixo de log/ e coverage/ dentro do artefato. Foram as deduções que seguraram em 95.

Opus 5 contra Opus 4.8 e Fable 5

Primeiro os números do nosso teste:

O Opus 4.8 tinha feito 95 com uma solução menor e muito mais rápida. Usou a API correta, escreveu testes honestos e fez a melhor validação ao vivo daquela rodada: Rails local, chamada real ao OpenRouter, Docker, container de produção e Compose. Perdeu pontos por deixar o histórico sem limite no cookie e não fazer preflight da chave.

Opus 5 corrigiu os dois defeitos e foi bem além na arquitetura, no streaming e nos testes. Em compensação, criou outra race, deixou o pin desatualizado e gastou mais do dobro do tempo. Mesma nota, artefatos bem diferentes.

O Fable 5 original fez 94. Foi o primeiro modelo que vi parar no meio do trabalho pra ler o source instalado do RubyLLM antes de escrever a integração. Tinha 99,3% de cobertura, cap de histórico, preflight e uma fase 2 sem nenhum conserto. A grande dedução foi guardar conversa num singleton em memória: reinicia o processo, perde tudo; sobe mais de um worker, cada um enxerga um mundo.

O re-release do Fable corrigiu isso com Rails.cache, mas deixou o cache sem hard cap, manteve Sonnet 4.6 e fez uma validação ao vivo mais fraca. Caiu um ponto. Mesma identificação de modelo, outro projeto, outro score.

Nos limites desse app Rails, Opus 5 parece mais completo que os dois Fable e pelo menos tão bom quanto Opus 4.8. Só não confunda isso com “Opus 5 tem mais inteligência que Fable”. A Anthropic diz que a vantagem do Fable cresce quanto mais longa e complexa fica a tarefa. Nosso projeto é pequeno, greenfield e fechado. Pode simplesmente não ter espaço pra mostrar a diferença.

O preço: metade do Fable, mas cuidado com a conta

Na API, a vantagem é direta:

Se Opus 5 realmente entrega comportamento próximo de Fable no seu workload, pagar o dobro por Fable fica difícil de justificar. Fable precisa resolver algo que Opus não resolve, não apenas carregar o nome da tier acima.

Mas o custo observado nessa rodada conta outra história:

Como um modelo com tarifa pela metade do Fable acabou com equivalente maior? Porque preço por milhão não é custo por tarefa. O run do Opus 5 fez 201 turnos e acumulou 22,1 milhões de cache reads no Claude Code. O run do Fable usou outro harness e outro perfil de tokens. Comparar $16,02 com $11,20 como se fosse só diferença de modelo seria errado.

Pra mim, assinante Max, o custo marginal real foi zero enquanto eu estiver dentro da franquia. Pra automação que paga API por token, a tarifa do Opus 5 é metade da do Fable e igual à do 4.8. Aí eu começaria no Opus 5 e só subiria pra Fable com evidência de que a tarefa precisa dele.

Contra GPT 5.6 Sol e Kimi K3

O GPT 5.6 Sol fez 92 em 17 minutos. Foi muito mais econômico em tokens e entregou uma aplicação defensiva: Docker non-root, 99,2% de cobertura, histórico limitado por mensagens, caracteres e bytes, e um teste específico pra não repetir o prompt atual no contexto.

Perdeu pontos porque não usou with_instructions e carregou o histórico num hidden field do browser. Funciona, mas perde a conversa no reload e deixa o cliente adulterar o contexto. O Opus 5 colocou essas responsabilidades no servidor, separou melhor domínio, persistência e provider, e testou muito mais. Neste projeto, a diferença de três pontos faz sentido. No uso diário, os dois continuam no mesmo cluster de modelos fortes.

O Kimi K3 fez 89 em 26 minutos. Ele já tinha acertado o padrão que decide boa parte do topo: Rails.cache, TTL e cap de histórico. Custou só cerca de $2,10 equivalentes em API pela assinatura Moderato.

Ficou abaixo porque não tinha system prompt, colocou I/O do LLM dentro do model Conversation, não fez preflight de credencial e deixou o cache de produção no default efêmero do container. Opus 5 fecha quase todas essas lacunas. Kimi continua sendo uma alternativa Tier A bem mais barata; Opus 5 é o projeto que eu precisaria mexer menos antes de confiar.

O Opus 5 também derrubou o antigo campeão

Tem uma mudança importante na tabela que não veio do código novo. Até ontem, Opus 4.7 aparecia em primeiro com 97. O cross-audit cego entre ele e Opus 5 deu 94 contra 70 a favor do 5. Fui reler os artefatos antigos.

O Opus 4.7 tinha um bug de double-send: o controller salvava a mensagem do usuário antes de chamar o service, e o service reenviava todo o histórico, incluindo aquela mesma mensagem. Cada prompt chegava duas vezes ao LLM. As mensagens de erro também voltavam no contexto de pedidos futuros, e o cookie tinha limite de quantidade, mas não de bytes.

Os testes passavam porque controller e service eram testados em arranjos diferentes do fluxo de produção. O modelo não piorou desde abril. O projeto também não mudou. Minha auditoria é que estava incompleta. Recalculei a nota de 97 pra 87.

Isso é quase cômico porque o artigo da semana passada usava justamente “por que Opus 4.7 fica acima de 4.8 e Fable?” como exemplo. Agora não fica. E o argumento do artigo ficou ainda mais forte.

Benchmark não é escritura sagrada. A rubrica evolui, o auditor encontra um ponto cego, o harness muda, o mesmo modelo gera outro projeto. Se uma tabela não publica prompt, artefato, logs e correções, ela serve mais pra marketing que pra engenharia.

Conclusão

Opus 5 é bom? Sim. Muito.

Fez 95/A, empatou com Opus 4.8 e GPT 5.4 no score, ficou um ponto acima do Fable original, três acima do GPT 5.6 Sol e seis acima do Kimi K3. Produziu o projeto mais cuidadoso desta rodada inteira: arquitetura limpa, RubyLLM verificado na gem real, histórico correto, streaming bem feito, erros separados e 121 testes.

Também levou 39 minutos, queimou 22 milhões de cache reads e rodou num harness diferente. A nota maior que Fable não prova que é melhor que Fable no geral. Prova que, neste app Rails, nesta execução pelo Claude Code e nesta auditoria, o artefato encaixou um pouco melhor na rubrica.

Minha leitura prática: Opus 5 merece entrar como primeira opção. A tarifa é a mesma do Opus 4.8 e metade da do Fable. Pra quem tem Claude Pro ou Max, vira a escolha óbvia antes de gastar créditos no Fable. Pra quem paga API, eu também começaria nele e exigiria dados antes de subir pra tier de $10/$50.

E a regra continua a mesma: leia 90+ como um grupo. Tier A está claramente acima de Tier C neste workload. Dentro do grupo bom, escolha por custo, assinatura, velocidade, harness e pelo tipo de defeito que você aceita revisar.

Não use meu benchmark pra decidir qual é “o melhor LLM”. Use pra escolher o que vale testar no seu problema. Se a decisão importa, rode a sua metodologia, mais de uma vez, e leia o código.