Quase Fable 5 pela metade do preço: por que Opus 5 muda sua decisão de modelo por-projeto para por-tarefa
Levo dois anos vendo equipes escolherem “um modelo” da mesma forma que se escolhe um banco de dados: uma vez, no início, com uma reunião longa e uma planilha. Opus 5, que a Anthropic lançou em 24 de julho, aposenta essa reunião sem fazer barulho. Não porque seja um novo state-of-the-art — é — mas porque transforma o trade-off custo/inteligência em um botão que você move por tarefa, em vez de uma aposta que faz por projeto.
O número que vai circular é o destaque: Opus 5 “fica perto da inteligência de fronteira de Claude Fable 5 pela metade do preço”. Em CursorBench 3.2, a máximo esforço, fica dentro de 0,5% do pico de Fable 5 pela metade do custo por tarefa. É o state-of-the-art absoluto em Frontier-Bench v0.1 e GDPval-AA, e mais que dobra a pontuação de Opus 4.8 em Frontier-Bench a um custo por tarefa menor. Mesmo preço do seu antecessor — $5 por milhão de input tokens, $25 de output — disponível agora na API como claude-opus-5, e já é o modelo padrão em Claude Max e a opção mais forte em Pro.
Mas o preço não é a parte interessante. A parte interessante é a configuração de esforço.
Opus 5 traz um controle de esforço — baixo, médio, alto, muito alto, máximo — que permite trocar inteligência por tokens em cada requisição. Isso é o que muda como uma equipe deveria pensar. Até agora, “mais barato vs. mais inteligente” era uma decisão de seleção de modelo: você roteava para Haiku no caminho barato e para Opus no caminho difícil, e tinha que manter essa lógica de roteamento. Com Opus 5, o mesmo modelo cobre todo o intervalo. Você baixa o esforço para boilerplate e sobe para refatoração complicada, e cobra de acordo.
Os relatos de early-access apontam na mesma direção. Um cliente de workflows legais descobriu que Opus 5 manteve a precisão gerando 26% menos tokens em média que Opus 4.8 a máximo raciocínio. Outros descrevem o ganho de eficiência diferentemente — uma empresa de trading cita cerca de um sétimo dos tokens de raciocínio e menos da metade da latência de Opus 4.8; uma equipe de modelagem financeira viu um terço menos de turns e chamadas de ferramentas e 60% menos tempo de relógio — . Os números específicos variam dependendo da carga de trabalho, mas o padrão não: em Opus 5, mais esforço compra menos desperdício que antes.
Aqui vai o enquadramento de CTO que eu usaria de verdade em uma reunião de planejamento. Sua decisão de modelo era um custo fixo: você escolhia um tier e vivia com seu piso e seu teto. Opus 5 transforma esse custo fixo em um variável que você controla no momento da chamada. Isso é uma mudança de orçamento disfarçada de flag de API. Significa que seu custo por tarefa agora é função de um parâmetro que seus engenheiros estabelecem, não de um contrato que assinou. Também significa que “qual modelo” deixa de ser a alavanca e “quanto esforço por tarefa” passa a ser.
Duas advertências que convém manter honestas. Primeiro, o enquadramento dos benchmarks: os claims de SOTA são em Frontier-Bench e GDPval-AA; a história de CursorBench é proximidade com Fable 5 pela metade do custo, não um novo pico — não convém confundir os dois — . Segundo, Opus 5 está deliberadamente atrás de Mythos 5 em cibersegurança e biologia. Anthropic não treinou em tarefas de ciber; seus classificadores de ciber são ~85% menos restritivos que os de Fable 5, mas ainda bloqueiam a geração de exploits e a varredura de vulnerabilidades baseada em binários, e as requisições sinalizadas caem de volta para Opus 4.8 em Claude.ai, Claude Code e Cowork. Se seu trabalho vive em segurança ofensiva, este não é seu modelo — e é por design — . (Anthropic também o chama de seu modelo mais alinhado até à data, com a pontuação mais baixa em sua auditoria interna de desalinhamento — vale notar, já que o mesmo lançamento afrouxou as barandas de ciber — ).
Nota prática para a galera de Claude Code (o canto do Dev): a configuração de esforço não é apenas uma abstração de API — é a alavanca a que se recorre quando uma corrida agêntica longa está queimando tokens em passos fáceis — . Convém começar uma sessão em um esforço mais baixo para scaffolding e edições rotineiras, e subir para alto/muito alto/máximo quando passa para debugging difícil ou uma busca de causa raiz. Vários times de early-access relatam a mesma precisão em níveis de esforço mais baixos, então o padrão de “sempre máximo” agora é o hábito caro, não o seguro.
A mudança real não é que há um novo melhor modelo esta semana — há um novo melhor modelo quase toda semana — . É que a escolha entre inteligente e barato se moveu da decisão de compra para o código, onde um desenvolvedor a define por tarefa. Se ainda está escolhendo um modelo por projeto, está deixando o botão sobre a mesa.
Já está roteando por configuração de esforço, ou ainda escolhe um modelo fixo por projeto? Onde você coloca o corte entre “baixe o esforço” e “vá no máximo”?