Claude Opus 5.5: mais barato por token, incerto por tarefa

Uma Opus mais barata que recusa parte das suas requisições existentes

A Claude Opus 5.5 é a substituta da Anthropic para a Opus 5 no mesmo nível, anunciada hoje, somente por API, sem pesos publicados. Para quem roda a Opus 5 em produção, duas coisas mudam ao mesmo tempo, e elas puxam em direções diferentes.

A primeira é a fatura. Pela tabela do fornecedor, a entrada cai de $5 para $4 por milhão de tokens, a saída de $25 para $20, e as leituras de cache de $0.50 para $0.20. O anúncio da Anthropic resume assim:

It costs less per token than Opus 5 and uses fewer tokens per task, which nets out to a 40% drop in costs.

Essa frase embute duas afirmações. O preço por token é um fato que dá para ler direto na tabela. Os tokens por tarefa são uma medição, e em cima de qual carga de trabalho ela foi medida importa mais do que o percentual.

A segunda mudança é que a API não aceita mais requisições que a Opus 5 aceitava. A página What's new da Anthropic lista quatro breaking changes: o thinking não pode ser desativado, o uso forçado de tool retorna erro, os blocos de thinking ficam presos ao modelo e à conversa, e a ferramenta de computer-use anterior, computer_20251124, não é mais aceita na Claude API nem no Google Cloud.

As duas primeiras são as que a maioria das integrações com a Opus 5 vai encontrar. Qualquer requisição que envie thinking: {"type": "disabled"} ou um orçamento de thinking manual recebe um 400. Qualquer requisição que envie tool_choice como any ou uma tool nomeada recebe um 400. As substituições recomendadas pelo fornecedor são o parâmetro effort para o primeiro caso e tool_choice: auto com strict tool use ou structured outputs para o segundo. Se você estava forçando uma chamada de tool para obter um JSON válido pelo schema, isso é uma mudança de código, não de configuração.

Uma quinta mudança não falha em nada e é mais fácil de passar despercebida:

text between tool calls comes back in thinking blocks

Na configuração padrão de display, esses blocos têm texto vazio, então um aplicativo que transmite as notas de progresso do modelo para os usuários fica em silêncio entre chamadas de tool, sem nenhum erro para capturar.

A alegação de custo e o padrão de effort são a mesma frase

A causa é o lançamento, e o que torna isso urgente é que, para boa parte das integrações com a Opus 5, migrar não é opcional como costuma ser com um modelo novo. A própria página do fornecedor diz que código já rodando na Opus 5 com thinking ligado não precisa de nenhuma mudança. Código que roda com thinking desativado, força uma chamada de tool, usa a ferramenta de computer-use mais antiga, ou edita o contexto anterior de uma conversa numa conta criada a partir de 31 de agosto de 2026 não pode simplesmente ser apontado para a Opus 5.5 e deixado quieto. Quem está na Opus 5 precisa decidir, e o argumento do fornecedor para decidir que sim é o custo.

A ressalva desse argumento está na mesma página da manchete:

at default settings it will cost 40% less than Opus 5 on typical workloads

"Default settings" está fazendo mais trabalho do que parece. A documentação de effort da Anthropic diz que a Opus 5.5 usa medium por padrão, onde a Opus 5 usava high:

a request that omits effort runs one level lower than it did on Claude Opus 5

Ou seja, o 40% do fornecedor compara a Opus 5.5 em medium com a Opus 5 em high. Essa é uma comparação legítima entre os padrões de cada modelo. Não é uma comparação no mesmo nível de effort, e o próprio guia de prompting do fornecedor diz o que acontece se você mantiver o effort constante:

At a given level, Claude Opus 5.5 tends to think more per turn than Claude Opus 5, especially at xhigh and max.

Juntando essas duas linhas, a migração ganha um formato. Migrar e aceitar o novo padrão significa rodar um nível de effort abaixo do que rodava antes, num modelo que o fornecedor diz ser mais forte nesse nível. Migrar e manter o valor de effort da Opus 5 significa que o próprio fornecedor avisa para esperar turnos mais longos e mais tokens de saída, a um preço por token só 20% menor. O 40% é o primeiro caminho. Nada na página do anúncio reivindica esse número para o segundo.

Três relatos independentes, e ninguém testou o padrão

A evidência mais forte do fornecedor sobre custo por tarefa é um gráfico, e o fornecedor o publicou com os eixos identificados.

Pelo relato da própria Anthropic, a Opus 5.5 no effort padrão supera a Opus 5 no effort máximo no Terminal-Bench 4.0 por cerca de um quinto do custo por tentativa. É o benchmark do fornecedor, as execuções do fornecedor e o gráfico do fornecedor, e é a versão mais forte do argumento porque é por tentativa, não por token. O anúncio também cita cerca de duas dezenas de parceiros de lançamento que relatam bons resultados. Isso é material do fornecedor. Nenhum deles publicou uma contagem de tokens.

Três partes de fora da Anthropic publicaram algo no dia do lançamento. Nenhuma delas é um teste equivalente à alegação do fornecedor sobre as configurações padrão, e cada uma mostra algo mais estreito do que a manchete que costuma receber: um aumento de tokens em todo um pipeline contra uma mistura de produção, uma requisição que bateu no teto de saída em max, e uma rodada de índice max contra max.

A CodeRabbit rodou a Opus 5.5 dentro do seu pipeline de revisão de código e reportou uso maior de tokens em toda configuração: +49.2% e +57.6% em 80 padrões de bug open-source, +40.6% e +60.1% em 13 casos mais difíceis. Duas condições acompanham esses números. A linha de base é a própria mistura de modelos de produção da CodeRabbit, não a Opus 5, e "Standard" e "Max" são suas configurações no nível do pipeline, não valores de effort da API. A própria CodeRabbit afirma a primeira parte:

The token increase is also a different comparison from the price reduction relative to Opus 5.

Os números vêm de um resumo de execução que não separa tokens de entrada dos de saída, e eles não estabelecem nem custo em dólares nem latência. O post não diz se a CodeRabbit teve acesso antecipado. O que ele diz é onde fica o ônus:

Its efficiency remains an open question, so teams should verify whether its lower token prices actually translate into lower production-review costs.

Não é uma review hostil. A razão do mesmo post para experimentar o modelo é capacidade, não preço:

The strongest reason to try Opus 5.5 is that it finds a different mix of bugs.

Simon Willison esbarrou na outra ponta do thinking sempre ativo. Ao pedir um SVG em effort max:

it hit the limit of 128,000 cap for output tokens while it was still reasoning about the question!

So that failed attempt on max cost me $2.56.

Isso é comportamento documentado, não um bug. A página de effort da Anthropic recomenda:

set a large max_tokens at the higher levels: it's a hard limit on total output (thinking plus response text)

O guia de migração confirma que o teto ficou em 128k. Na Opus 5 dava para desligar o thinking e tornar esse teto irrelevante. Na Opus 5.5 não dá, então, nos níveis mais altos de effort, uma requisição pode gastar todo o orçamento raciocinando e não retornar nada, e você paga pelo raciocínio.

A Artificial Analysis rodou seu Intelligence Index nos dois modelos em effort max, com fallback ligado para a Opus 5.5. Acessadas no dia do lançamento, as duas páginas dizem:

When evaluating the Intelligence Index, it generated 260M tokens, which is very verbose in comparison to the median of 88M.

When evaluating the Intelligence Index, it generated 140M tokens, which is very verbose in comparison to the median of 88M.

A Opus 5.5 pontuou 58 contra 51 da Opus 5 nesse índice, e as mesmas páginas, lidas no dia do lançamento, colocam a execução completa em $8,708.20 contra $7,274.74, ou $5.98 por tarefa contra $5.86. Vinte por cento mais barata por token, 86% mais tokens, dois por cento a mais por tarefa. Duas ressalvas: isso é max contra max, então não diz nada sobre o padrão em medium effort no qual a alegação do fornecedor se apoia, e o fallback estava ligado, então algumas tarefas podem ter sido respondidas por outro modelo. A mesma página lista a velocidade de saída da Opus 5.5 como indisponível. O anúncio da Anthropic diz que o modelo gera saída mais de 30% mais rápido que a Opus 5. Até hoje, ninguém fora da Anthropic mediu isso.

O que ninguém independente testou: a própria comparação entre configurações padrão, a Opus 5.5 em medium contra a Opus 5 em high, numa carga de trabalho real. Essa é a única medição que resolveria o número do fornecedor, e é a única que você pode rodar você mesmo.

Há mais um desacordo, e ele está entre duas páginas da própria Anthropic. O anúncio descreve as novas proteções (safeguards) sobre cibersegurança, biologia e destilação assim:

all of which fall back to another model transparently

A documentação de refusals-and-fallback cita a Opus 5.5 já na primeira frase e depois descreve algo que quem chama a API precisa configurar. Uma recusa não é um erro:

When that happens, you receive a normal response, not an error, with stop_reason: "refusal".

Conseguir uma resposta de outro modelo significa optar por uma de três rotas: server-side fallback, middleware do SDK, ou uma nova tentativa que você mesmo escreve. Sobre a primeira, a mesma página diz:

Server-side fallback is in beta on the Claude API.

Em seguida, diz que o parâmetro fallbacks não é suportado na Message Batches API e não está disponível na Amazon Bedrock, no Google Cloud nem no Microsoft Foundry, onde o middleware do SDK é a rota usada em vez disso. A cobrança também está documentada:

An attempt that declined before producing any output is not billed: its tokens are reported on its usage.iterations entry but not charged.

Toda tentativa que produziu saída, incluindo uma que recusou no meio do caminho, é cobrada nas tarifas do modelo que a executou, e usage.iterations é o registro por tentativa. Quando um fallback roda, a resposta nomeia o modelo que a atendeu. Ou seja, "transparently" significa visível, não automático. Um pipeline que não opta por nenhuma rota e só verifica erros vai ler uma recusa de proteção como uma chamada bem-sucedida sem nenhuma resposta dentro dela.

Meça tokens por tarefa concluída, depois decida

A migração é um trabalho de duas partes, e a ordem importa. Primeiro, deixe as requisições válidas: remova o campo thinking, troque o tool_choice forçado por auto mais strict tool use ou structured outputs, mude para o conjunto de ferramentas de computer-use mais novo se você usa um, e defina display como updates se você transmite conteúdo entre chamadas de tool. Defina effort explicitamente em vez de herdar o novo padrão por acidente, e defina max_tokens alto o suficiente nos níveis superiores para que o raciocínio tenha espaço.

Depois, antes que qualquer coisa disso chegue à produção, rode a comparação que a própria página de effort do fornecedor recomenda: um sweep de effort sobre suas evals, em vez de configurações simplesmente carregadas do modelo antigo. O número a registrar não é preço por token. É o total de tokens, dividido em entrada, saída e leituras de cache, por tarefa que de fato terminou, em cada nível de effort, sobre os seus prompts. As leituras de cache importam mais do que parece: a Anthropic diz que elas respondem pela maior parte dos custos de trabalhos agentic e de código, e são a linha que caiu 60%, então uma carga de trabalho pesada em cache pode sair na frente mesmo com mais tokens de saída. Uma carga de trabalho com pouco cache e raciocínio longo pode sair atrás. Você só vai saber qual é o seu caso depois de contar.

Essa comparação é um workflow pequeno, e é o tipo de coisa para a qual o Latenode foi feito, independentemente de o modelo testado ser o ponto central. Pegue os trinta prompts que o seu produto realmente envia, rode cada um em duas configurações, Opus 5 no effort que você usa hoje e Opus 5.5 em medium, e tenha um node de JavaScript, que pode instalar qualquer biblioteca NPM, fazendo as duas chamadas pelo SDK do fornecedor e registrando tokens de entrada, tokens de saída, leituras de cache e o tempo de parede (wall-clock) de cada uma. Um plano pago inclui 5 workers de execução paralela, então o sweep roda em algo perto da concorrência que você serve em produção, em vez de um prompt de cada vez. O medidor coopera com o experimento: o Latenode cobra os segundos de CPU que uma execução realmente consome, não por node nem por chamada de API, e sem mínimo por execução, então algumas centenas de execuções curtas de comparação custam apenas os segundos que levam. A fatura que importa é a fatura do modelo, e o sweep existe para produzir esse número antes de você se comprometer com ele.

Migre esta semana se sua carga é pesada em cache e você consegue contar

Migre agora se três coisas forem verdadeiras: você roda a Opus 5 com thinking ligado, seu tráfego é trabalho agentic ou de código onde as leituras de cache dominam, e você tem como medir tokens por tarefa concluída, antes e depois. Nesse cenário, a tabela de preços do fornecedor já faz a maior parte do trabalho sozinha, a queda do effort padrão é um bônus que você pode aceitar ou recusar, e as breaking changes custam uma tarde do seu tempo. Comece em medium. Só suba de nível se as suas evals mandarem.

Não migre esta semana se qualquer um destes se aplicar. Você roda a Opus 5 com thinking desativado: essa configuração não existe mais, e o substituto mais próximo é um nível de effort mais baixo que você ainda não calibrou. Você força chamadas de tool para obter JSON válido: esse caminho acabou e o substituto precisa de testes. Você roda em xhigh ou max: as únicas medições independentes nessa ponta mostram mais tokens, e o teto de 128k agora inclui raciocínio que você não consegue desligar. Sua conta de API foi criada a partir de 31 de agosto de 2026 e seu pipeline edita o system prompt ou as tools no meio da conversa: o preserved thinking vai rejeitar o replay. Seu tráfego toca ferramentas de segurança ou biologia: uma recusa de proteção volta como uma resposta normal com um stop reason de refusal, não como um erro, e conseguir uma resposta de outro modelo significa optar por uma rota de fallback, sendo que a rota server-side está em beta na Claude API e não é oferecida em batches nem nas plataformas de nuvem. Monte a nova tentativa antes de precisar dela.

E não migre com base no 40%. É o número do fornecedor para as próprias cargas de trabalho, nos próprios padrões, e hoje ninguém fora do fornecedor reproduziu isso em nada. A primeira medição independente da comparação padrão-contra-padrão numa carga de trabalho de produção vai valer mais do que todo benchmark da página do anúncio. Até que ela exista, o número que decide a sua migração é o que você mesmo produzir.