- O benchmark está dizendo uma coisa. O programador, outra. 🎯
- Quando consertar uma linha vira reconstruir a casa 🏗️
- Mas então o Opus 5 é ruim? Não tão rápido. ⚖️
- E a confiança? Aí a história fica mais complicada. 🔎
- “Opus 5” significa sempre Opus 5? 🤔
- E ainda tem a questão do dinheiro. 💸
- O Sonnet 5 é um sinal de pressão? 📉
- A Anthropic está perdendo os desenvolvedores? Ainda não. 🚦
- Talvez o problema seja esperar que um modelo faça menos
- E é aí que a conta realmente fecha 🔮
Principais destaques
- Benchmarks impressionam: Opus 5 supera amplamente modelos anteriores em testes de programação e tarefas agentic, mas isso não garante uma boa experiência no trabalho cotidiano.
- O excesso virou problema: desenvolvedores relatam respostas longas, reescritas desnecessárias e revisões cheias de críticas de baixo valor.
- Confiança entrou na conta: mudanças de comportamento, roteamento entre modelos e preço elevado aumentam a dúvida sobre quanto dessa capacidade realmente vale no uso diário.
A promessa parece simples: quanto melhor o modelo, melhor deveria ser trabalhar com ele.
Só que, para parte dos desenvolvedores, a experiência com o Claude Opus 5 está seguindo uma lógica bem diferente.
O modelo aparece no topo de benchmarks, resolve tarefas complexas e demonstra capacidade impressionante em projetos longos. No dia a dia, porém, usuários descrevem outra criatura: um assistente que transforma pequenos ajustes em grandes refatorações, explica o óbvio por páginas e trata comentários banais de código como se fossem falhas críticas.
E aí aparece uma questão incômoda.
Um modelo pode ser excepcional em testes e, ainda assim, ser cansativo de usar.
O benchmark está dizendo uma coisa. O programador, outra. 🎯
Os números publicados pela Anthropic são, de fato, fortes.
O Opus 5 teria mais que dobrado o desempenho do Opus 4.8 em um benchmark de programação de fronteira. Em outro teste voltado a tarefas agentic, chegou a aproximadamente três vezes o resultado do modelo seguinte.
No papel, é uma evolução gigantesca.
O problema é que benchmarks normalmente começam com uma vantagem importante: o problema já está definido.
Há uma tarefa, um ambiente preparado e um critério relativamente claro para determinar se o modelo conseguiu ou não chegar ao resultado esperado.
No trabalho real, quase nunca é assim.
O desenvolvedor pode pedir para corrigir uma função de dez linhas. Depois mudar de assunto. Em seguida perceber que faltou uma condição. Depois pedir apenas uma explicação.
Não existe uma bandeira dizendo ao modelo: “agora pare”.
🔎 A diferença fundamental: benchmark recompensa capacidade de chegar ao fim. O trabalho cotidiano também recompensa saber quando não fazer mais nada.
É justamente aí que começam as reclamações sobre o Opus 5.
Quando consertar uma linha vira reconstruir a casa 🏗️
Os relatos mais críticos se concentram em três comportamentos: verbosidade, excesso de engenharia e dificuldade para avaliar o tamanho real de um problema.
Theo Browne, desenvolvedor e CEO da T3 Chat, descreveu o Opus 5 como um modelo capaz de tratar praticamente qualquer comentário de código como um problema crítico que justificaria milhares de linhas novas.
É uma crítica particularmente importante porque não vem de uma tabela de benchmark. Vem de alguém usando o modelo em produção.
E existe uma diferença enorme entre encontrar possibilidades de melhoria e saber quais melhorias importam.
Code Rabbit colocou esse comportamento à prova em um teste controlado. O Opus 5 encontrou menos dos problemas conhecidos que o experimento queria identificar, mas produziu cerca de quatro vezes mais observações de baixo valor do que o baseline de produção.
| Comportamento | O que parece à primeira vista | Problema prático |
|---|---|---|
| Mais observações | Mais atenção aos detalhes | Mais ruído para o desenvolvedor |
| Mais texto | Mais explicação | Mais tempo para filtrar o que importa |
| Mais mudanças | Mais engenharia | Maior risco de alterar o que já funcionava |
💡 Mais trabalho produzido não significa necessariamente mais trabalho útil.
Em uma revisão de código, cada falso positivo tem um preço. Alguém precisa ler, entender, verificar e descartar aquela sugestão.
Multiplique isso por centenas de revisões e a suposta vantagem de “ser mais cuidadoso” começa a parecer uma conta de produtividade.
Mas então o Opus 5 é ruim? Não tão rápido. ⚖️
Seria um erro transformar essas críticas em uma sentença geral sobre o modelo.
O próprio material de teste aponta vantagens importantes em construções autônomas de longa duração, pesquisa, uso de computador e projetos visualmente complexos.
A diferença aparece mais claramente no tipo de trabalho.
Como construtor, o modelo pode ser excelente. Como revisor de uma pequena alteração, sua tendência a continuar cavando pode se tornar um problema.
🧠 O ponto não é capacidade. É calibração: um modelo otimizado para enfrentar problemas difíceis e abertos pode acabar usando a mesma intensidade quando a tarefa pedia apenas uma correção de cinco minutos.
É como levar uma escavadeira para plantar uma flor.
A ferramenta pode ser extraordinariamente poderosa. Só não significa que seja a ferramenta certa para aquele momento.
E a confiança? Aí a história fica mais complicada. 🔎
As dúvidas sobre a experiência do Claude não surgiram apenas com o Opus 5.
A Anthropic já alterou comportamentos do Claude Code que afetaram diretamente a percepção de desempenho dos usuários.
Em março, a empresa reduziu o raciocínio padrão do Claude Code de alto para médio. Posteriormente, reconheceu que a mudança trocava uma pequena quantidade de inteligência por menor latência e menos consumo dos limites de uso.
Também houve um problema de cache que fazia partes antigas do raciocínio desaparecerem em sessões longas, levando a comportamentos repetitivos e à impressão de que o Claude estava “esquecendo” o que havia feito.
Outro ajuste, criado para encurtar respostas, foi associado a uma queda medida de 3% no desempenho de programação.
Todos esses problemas acabaram sendo corrigidos.
Mas existe uma diferença importante entre corrigir um problema e evitar que o usuário precise descobrir que ele existe.
🗣 Para quem paga pelo produto, a experiência é o produto: pouco importa se a causa foi um modelo diferente, uma configuração ou um bug quando o resultado percebido é um assistente menos confiável.
A Anthropic nega ter enfraquecido deliberadamente seus modelos e afirma que a API não foi afetada pelas mudanças mencionadas. Essa distinção é relevante.
Ainda assim, para quem trabalha dentro do Claude Code, uma mudança silenciosa de comportamento pode ser sentida como uma mudança de capacidade.
“Opus 5” significa sempre Opus 5? 🤔
Há outra camada nessa história.
A própria documentação de lançamento da Anthropic informa que determinados pedidos relacionados a cibersegurança podem fazer o sistema retornar automaticamente do Opus 5 para o Opus 4.8.
Outras solicitações consideradas sensíveis podem ser encaminhadas entre diferentes modelos conforme classificadores internos de segurança.
A lógica declarada é compreensível: evitar bloquear pedidos legítimos enquanto se aplica um nível adicional de controle em tarefas potencialmente perigosas.
O detalhe desconfortável está em outro lugar.
Dois usuários podem escrever essencialmente o mesmo pedido dentro do mesmo plano e, dependendo da classificação interna, acabar recebendo modelos diferentes.
O usuário não necessariamente vê essa troca acontecendo.
💡 O nome do modelo começa a descrever não apenas uma inteligência, mas um sistema de roteamento.
Isso não significa que a Anthropic esteja escondendo o mecanismo. A empresa documenta essas regras.
Mas significa que comparar modelos apenas pelo nome pode ficar cada vez menos suficiente.
E ainda tem a questão do dinheiro. 💸
Capacidade tem preço. E, no caso do Opus 5, o preço não é exatamente tímido.
O modelo custa US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de tokens de saída.
A comparação citada no material deixa a diferença mais visível:
| Modelo | Entrada / 1M tokens | Saída / 1M tokens |
|---|---|---|
| Claude Opus 5 | US$ 5 | US$ 25 |
| Fable 5 | US$ 10 | US$ 50 |
| GPT 5.6 | US$ 2 | US$ 10 |
| Grok 4.6 | US$ 2 | US$ 6 |
| Gemini 3.7 Flash | US$ 0,75 | US$ 3,75 |
Preço por token, sozinho, não resolve a comparação. Um modelo mais caro pode valer a pena se concluir uma tarefa usando muito menos tentativas ou exigir menos intervenção humana.
Só que o Opus 5 enfrenta justamente o problema oposto em um dos testes.
O Code Rabbit registrou aproximadamente 50% mais tokens de entrada e 65% mais tokens de saída do que uma configuração comparável com GPT 5.6 na mesma tarefa de revisão.
Ou seja: não é apenas uma questão de pagar mais por cada token.
É também potencialmente pagar por mais tokens.
O Sonnet 5 é um sinal de pressão? 📉
A Anthropic tornou o Sonnet 5 mais competitivo em preço, com US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de saída.
Isso coloca uma camada interessante na estratégia da empresa.
Se tarefas cotidianas não exigem toda a capacidade do Opus, um modelo mais barato pode fazer mais sentido para grande parte do trabalho.
E os desenvolvedores agora têm alternativas suficientes para testar essa hipótese.
A competição deixou de ser “Claude contra modelos claramente inferiores”.
OpenAI, xAI e Google também oferecem modelos capazes de assumir boa parte das tarefas de programação e agentes.
Quando a diferença de preço é grande, a pergunta muda.
Não é mais “qual modelo é melhor?”.
É “qual modelo é bom o bastante para este trabalho?”
A Anthropic está perdendo os desenvolvedores? Ainda não. 🚦
Os números de negócio não apontam para uma empresa em crise.
A receita anualizada teria ultrapassado US$ 65 bilhões no fim de julho, em forte alta em relação ao ano anterior. A companhia também estaria se preparando para uma possível abertura de capital.
E o Claude Code continua profundamente integrado a fluxos profissionais.
Isso torna a história mais interessante, não menos.
Confiança raramente desaparece de uma vez.
Um desenvolvedor pode continuar usando Claude para projetos complexos e, ao mesmo tempo, migrar pequenas tarefas para outro modelo. Uma equipe pode manter a assinatura e mudar gradualmente seus workloads. Uma empresa pode descobrir que um concorrente “bom o suficiente” custa uma fração do preço.
O impacto financeiro só aparece depois.
📊 É por isso que receita atual e confiança futura não são a mesma métrica.
O material citado também aponta que o Fable 5 conquistou apenas uma participação modesta dos gastos de clientes americanos monitorados após o lançamento.
Não é prova de uma fuga em massa.
Mas é um lembrete de que os desenvolvedores não precisam escolher um único vencedor. Podem simplesmente usar cada modelo onde ele fizer mais sentido.
Talvez o problema seja esperar que um modelo faça menos
Existe uma ironia no caso do Opus 5.
Durante anos, a indústria de IA trabalhou para fazer modelos mais capazes.
Agora começa a surgir uma pergunta igualmente importante: eles sabem dosar essa capacidade?
Um bom assistente de programação não precisa transformar cada tarefa em uma missão épica. Às vezes, a resposta ideal é uma linha de código, uma explicação de duas frases ou simplesmente:
“Esse comentário não precisa ser alterado.”
Esse tipo de julgamento é difícil de medir em benchmarks porque o sucesso não está em fazer mais.
Está em não fazer demais.
💡 Talvez o próximo salto dos agentes de programação não seja escrever mais código. Seja aprender quando parar de escrever.
Isso ajuda a explicar por que um modelo pode dominar testes de autonomia e ainda frustrar quem passa oito horas por dia trabalhando com ele.
No benchmark, o Opus 5 recebe uma missão.
Na vida real, recebe interrupções, ambiguidades, pedidos mal formulados, mudanças de prioridade e aquele clássico “só ajusta isso rapidinho”.
São jogos diferentes.
E é aí que a conta realmente fecha 🔮
O Opus 5 parece ter capacidade suficiente para ser excelente em tarefas que exigem persistência, autonomia e raciocínio prolongado.
O desafio é fazer essa mesma inteligência parecer útil quando a tarefa é pequena.
Porque o desenvolvedor não mede um assistente apenas pelo problema mais difícil que ele consegue resolver. Mede também pela quantidade de problemas que ele não transforma em problemas maiores.
No fim, a metáfora da escavadeira volta.
Ter a máquina mais potente da obra é impressionante. Mas, se cada buraco de dez centímetros exige mobilizar todo o equipamento, alguém eventualmente vai perguntar se não havia uma ferramenta menor.
A próxima disputa entre os modelos talvez seja justamente essa: quem consegue entregar potência sem transformar cada pedido simples em uma obra de engenharia?
