A configuração de "esforço máximo" (max effort) do Claude Opus 5 infla o preço de uma solicitação rotineira de US$ 0,76 para US$ 19,21, entregando essencialmente o mesmo resultado funcional. O gasto extra compra uma etapa de auditoria interna, não uma solução melhor, e só mostra ganhos mensuráveis em tarefas que começam com baixa cobertura de testes.

O que o teste mostrou

O experimento comparou o nível de esforço padrão do Claude Opus 5 com o ajuste de "esforço máximo" em dois tipos de prompt: tarefas cotidianas de codificação e problemas deliberadamente difíceis.

  • Para uma tarefa típica, a execução de baixo esforço terminou em dois minutos e custou US$ 0,76. Aumentar a configuração para o máximo elevou a conta para US$ 19,21, mas a pontuação de cobertura de requisitos — a métrica que o modelo reporta sobre o quão bem ele atendeu ao briefing — permaneceu idêntica.
  • A transcrição mostra uma mudança da criação para a revisão. O modelo parou de gerar código novo e começou a polir o que já havia escrito. As edições superaram as novas escritas em uma proporção de 2,4 para 1. As chamadas para a ferramenta read aumentaram dezoito vezes, e as invocações da ferramenta bash subiram seis vezes. Na prática, o modelo relê módulos, executa seus próprios testes, realiza linting e até testes de mutação sem ser solicitado.

O ajuste de "esforço máximo" não introduz um novo algoritmo; ele simplesmente aumenta o orçamento que o modelo pode gastar. Uma vez que o orçamento é grande o suficiente, o modelo muda para um modo de autoauditoria, procurando por qualquer ajuste que possa justificar o gasto.

Por que o custo dispara

Quando o modelo decide auditar, cada chamada extra de read ou bash é adicionada à conta, e os efeitos multiplicadores fazem o custo total inflar rapidamente.

O modo de auditoria é uma escolha de design explícita. O modelo trata o orçamento maior como permissão para "procurar algo que valha a pena consertar". Se nada parecer passível de melhoria, o gasto extra não gera nenhum benefício funcional.

Quando um esforço maior faz sentido

O modo de auditoria brilha apenas quando o resultado inicial deixa margem para melhorias. Em um projeto Go com cobertura de testes de 0,73, elevar o esforço ao máximo aumentou a cobertura para 0,88.

Por outro lado, uma tarefa em Python que já havia alcançado 0,98 de cobertura não apresentou mudanças quando o orçamento foi aumentado. O modelo simplesmente rechecou o mesmo código de alta qualidade, inflando o custo sem adicionar valor.

Possíveis desvantagens

  • Estouro de orçamento – Usuários acostumados ao preço de baixo esforço podem se surpreender com um aumento de vinte e cinco vezes para a mesma entrega.

Orientações práticas para desenvolvedores

  • Mantenha os prompts rotineiros no nível de esforço padrão. Você obtém o mesmo resultado funcional por uma fração do preço.
  • Reserve o "esforço máximo" para códigos que não atendem a um limiar de qualidade claro — baixa cobertura de testes, avisos de lint ausentes ou outras lacunas mensuráveis.
  • Trate a configuração como um modo separado: uma etapa opcional de autorrevisão, em vez de um botão de ajuste rápido para obter respostas melhores.

Conclusão

A chave de esforço máximo do Claude Opus 5 troca dinheiro por uma verificação de qualidade interna, não por um código melhor. Use com moderação, apenas quando seus resultados de base deixarem uma lacuna quantificável para preencher; caso contrário, o padrão barato entrega o mesmo resultado sem o preço do modo de auditoria.

Fonte: https://dev.to/adrianco_54/retort-thinking-level-results-what-opus-actually-does-with-the-extra-time-55f7

Discussão da comunidade: https://t.me/GyaanSetuAi