Guia da API do Claude Opus 5.5: o ID do modelo, quatro mudanças incompatíveis e a quinta silenciosa

Altere a string do modelo de claude-opus-5 para claude-opus-5-5 e seu código continua compilando, continua passando na verificação de tipos e continua passando no que quer que passe por suíte de testes. Depois, ele retorna 400 em produção. Quatro formatos de requisição que o Claude Opus 5 aceitava são rejeitados de imediato pelo Claude Opus 5.5, e uma quinta mudança não quebra absolutamente nada — e é exatamente por isso que ela será a que chegará aos seus usuários. Esta é a referência de integração para o modelo: o identificador, as superfícies que o servem, o contrato de requisição, os quatro erros, o quinto silencioso e como o parâmetro effort funciona agora. Onde o comportamento corresponde ao Claude Fable 5.1, uma equipe que já migrou para lá já fez parte do trabalho, então cada mudança abaixo indica se ela também se aplica a esse modelo.

Tudo aqui foi retirado da própria documentação do Claude da Anthropic em 24 de setembro de 2026, dois dias após o lançamento do modelo. As alegações do fornecedor são rotuladas como alegações do fornecedor, os números independentes como independentes, e os dois nunca são apresentados na mesma configuração de esforço como se fossem comparáveis.

O ID do modelo e onde ele é servido.

O identificador é claude-opus-5-5 — um id de modelo fixo, sem sufixo de data, o mesmo esquema de claude-opus-5. Não há uma forma separada de snapshot fixado a adotar nem um alias que resolva para outra coisa.

A visão geral dos modelos da Anthropic lista cinco superfícies, com estas strings exatas:

• Claude API — claude-opus-5-5, disponível para todos os clientes.

• Amazon Bedrock — anthropic.claude-opus-5-5 (a única superfície que prefixa o fornecedor).

• Claude Platform on AWS — claude-opus-5-5, usando IDs da API do Claude em vez de IDs no estilo do Bedrock.

• Google Cloud — claude-opus-5-5.

• Microsoft Foundry — claude-opus-5-5; o nome da implantação é o que você envia, e o Foundry segue o cronograma do ciclo de vida da API do Claude.

Dois desses cinco importam mais do que o resto desta seção. O Amazon Bedrock e o Google Cloud definem suas próprias datas de ciclo de vida e de desativação e — como mostram as mudanças significativas abaixo — o Bedrock também é a única plataforma em que a antiga ferramenta de uso do computador ainda funciona. Se você usa o Bedrock, você não está na mesma migração que todo mundo.

O que toda solicitação precisa satisfazer agora

O guia de migração da Anthropic apresenta o contrato como uma lista, e a lista é curta o suficiente para você verificar seu próprio cliente com base nela. Independentemente do modelo de onde você vem, uma requisição para claude-opus-5-5 deve:

• Não envie nenhum campo thinking ou envie thinking: {"type": "adaptive"} — os dois são equivalentes, porque o pensamento adaptativo está sempre ativado.

• Controle a profundidade do raciocínio com effort, o único parâmetro de requisição que faz isso; todos os cinco níveis são compatíveis e o padrão é médio.

• Use tool_choice como {"type": "auto"} (o padrão) ou {"type": "none"}. Forçar uma ferramenta é rejeitado.

• Omita temperature, top_p e top_k, ou deixe-os nos valores padrão. Qualquer outro valor é rejeitado, neste modelo como em tudo a partir do Claude Opus 4.7 em diante.

• Não terminar mensagens com um turno de assistente pré-preenchido; isso já foi rejeitado no Opus 4.6 e versões posteriores.

• Declare o uso de computador como o computer_toolset_20260801 toolset na API do Claude e no Google Cloud.

• Não envie nenhum cabeçalho beta de janela de contexto. A janela de contexto de 1M é o padrão, e um cabeçalho escrito para um modelo mais antigo não tem efeito.

Quando o guia diz que uma configuração é rejeitada, a API retorna HTTP 400. Esse é todo o modo de falha de migrar para este modelo: não uma saída degradada, nem um aviso em um log — uma requisição que nunca é executada.

As quatro alterações significativas

1. O raciocínio não pode ser desativado

O pensamento adaptativo está sempre ativado. thinking: {"type": "disabled"} retorna um 400, e um orçamento manual também — thinking: {"type": "enabled", "budget_tokens": N}. O texto do erro informa o tipo que você enviou e depois informa a substituição:

• "thinking.type.disabled" não é compatível com este modelo. Use "thinking.type.adaptive" e "output_config.effort" para controlar o comportamento de raciocínio.

• "thinking.type.enabled" não é compatível com este modelo. Use "thinking.type.adaptive" e "output_config.effort" para controlar o comportamento de raciocínio.

A consequência prática não é o erro, é o que acontece depois que você o corrige. No Claude Opus 4.8 e anteriores, uma requisição sem o campo thinking era executada sem thinking. No Claude Opus 5.5, toda requisição pensa, e max_tokens continua sendo um limite rígido que abrange o thinking mais o texto da resposta. Os tokens de thinking são cobrados como tokens de saída mesmo quando o texto do thinking nunca é retornado a você. Um endpoint que antes era executado sem thinking pode, portanto, produzir mais tokens de saída por requisição depois da "correção" do que produzia antes. A orientação da Anthropic é reduzir o esforço onde você antes desativava o thinking e — em esforço xhigh ou max — começar max_tokens em 64k e ajustar a partir daí.

A forma da resposta também muda. Uma resposta pode começar com um ou mais blocos de pensamento antes do primeiro bloco de texto, então o código que lê a resposta por posição — content[0].text, ou um manipulador de stream que trata o primeiro content_block_start como texto — falha nessas respostas mesmo quando a requisição foi bem-sucedida. Selecione os blocos pelo type campo, em vez disso.

2. O uso forçado de ferramenta retorna um erro

tool_choice tipos any e tool retornam um 400, e a mesma validação se aplica ao endpoint de contagem de tokens, então uma contagem prévia falha da mesma forma que a chamada real:

• tool_choice: os tipos "tool" e "any" não são suportados para este modelo.

Auto e none não são afetados. A substituição documentada é manter tool_choice: {"type": "auto"}, marcar ferramentas com strict: true para argumentos válidos pelo schema, ou mover o schema para saídas estruturadas — e dizer no prompt quando a ferramenta se aplica, já que auto não garante uma chamada. O uso estrito de ferramentas aceita um subconjunto de JSON Schema: todo objeto no input_schema de uma ferramenta deve definir additionalProperties: false, então verifique cada schema antes de ativar a flag. E observe a lacuna que isso deixa: se seu código dependia de forçar uma chamada em vez de apenas permiti-la, auto restaura a permissão e não a garantia. Verifique se um bloco tool_use realmente retornou.

3. Os blocos de pensamento estão vinculados ao modelo e à conversa

Cada bloco de pensamento registra qual modelo o produziu, e cada modelo lê seus próprios blocos, além de um conjunto definido de blocos de outros. As regras funcionam nos dois sentidos:

• O Claude Opus 5.5 lê blocos de raciocínio do Claude Opus 5 e de modelos Opus, Sonnet e Haiku anteriores — mas não dos modelos Claude Fable ou Claude Mythos.

• Na API da Claude, Claude Fable 5.1 e Claude Mythos 5.1 leem blocos do Claude Opus 5.5. Nenhum outro modelo o faz.

• Uma conversa que passa de Claude Opus 5.5 para qualquer coisa que não seja esses dois executa seus turnos posteriores sem o raciocínio anterior.

Um router ou fallback que move uma conversa é a forma óbvia de conseguir isso. A metade mais sutil é que o bloco também está vinculado ao prefixo da conversa — o prompt de sistema, as ferramentas e todas as mensagens anteriores a ele. A Anthropic aplica a verificação de prefixo por padrão para contas criadas em ou após 2026-08-31 00:00 UTC, na API da Claude e em plataformas de nuvem: reproduza um bloco depois de editar o prompt de sistema, a lista de ferramentas ou uma mensagem anterior e a requisição retorna 400. Existem duas saídas. Envie o thinking-binding-controls-2026-08-01 cabeçalho beta e defina thinking.block_binding.prefix_mismatch_behavior como "drop_block" para descartar os blocos afetados em vez de fazer a requisição falhar. Ou mantenha a conversa somente em modo append e altere as instruções com uma mensagem de sistema no meio da conversa em vez de uma edição — que é o que o Claude Code, o claude.ai, o Claude Managed Agents e o Claude Agent SDK já fazem.

Há uma boa notícia fácil de passar despercebida: quando uma solicitação carrega um bloco que o modelo de destino não consegue ler, a API o descarta antes que o modelo o veja. A solicitação é bem-sucedida, e os blocos descartados não são cobrados.

4. A ferramenta mais antiga de uso do computador é rejeitada na Claude API e no Google Cloud

Uma entrada de ferramentas do tipo computer_20251124 retorna um 400 na API Claude e no Google Cloud. A mensagem indica o tipo rejeitado e, em seguida, lista os tipos que o modelo aceita:

• 'claude-opus-5-5' não oferece suporte a tipos de ferramenta: computer_20251124.

A substituição é o computer_toolset_20260801 toolset: remova o cabeçalho beta computer-use-2025-11-24 e envie a entrada de ferramentas sem nome e sem dimensões de exibição. Isto não é apenas uma mudança de requisição — o loop do agente muda junto. As ações chegam como blocos tool_use de membro em vez de uma única ferramenta de computador, pode haver vários em um turno, a ação é o name do bloco em vez de input.action, e todo resultado tem que ecoar toolset_name de volta. Na Amazon Bedrock, computer_20251124 continua funcionando exatamente como funciona no Claude Opus 5 e nenhuma mudança é necessária.

Qual dos quatro também se aplica ao Claude Fable 5.1

A Anthropic afirma que os três primeiros também se aplicam ao Claude Fable 5.1 — pensamento sempre ativo, sem escolha forçada de ferramenta e blocos de pensamento vinculados ao modelo e à conversa. A mudança no uso de computador não: essa é específica deste modelo na Claude API e no Google Cloud. Assim, uma equipe que já migrou para o Claude Fable 5.1 aposentou seus caminhos de código com o pensamento desativado e suas escolhas forçadas de ferramenta, e adota um padrão de conversa somente com acréscimos; o que resta é o id do modelo e o conjunto de ferramentas de uso de computador. Uma equipe que vem do Claude Opus 5 enfrenta todos os quatro de uma só vez. Essa é a migração que vale a pena agendar, e ela representa uma quantidade diferente de trabalho dependendo de onde você começa.

A quinta mudança: nada dá erro, e o seu feed de progresso fica em silêncio

No Claude Opus 5, as notas curtas que o modelo escreve entre chamadas de ferramenta voltam como blocos de texto comuns. No Claude Opus 5.5 — assim como no Claude Fable 5.1 — essa narração retorna como blocos de pensamento de atualização de progresso, no máximo um antes de cada chamada de ferramenta. E thinking.display tem como padrão "omitted", então esses blocos chegam com um campo thinking vazio junto com sua assinatura.

Nenhuma solicitação falha. Nenhum erro é registrado. Uma aplicação que transmite o texto entre ferramentas aos seus usuários como indicador de progresso simplesmente deixa de mostrar progresso entre as chamadas de ferramentas e passa a não mostrar nada. O sintoma visível é uma interface que parece congelada exatamente no trecho de trabalho em que o usuário mais deseja segurança, e isso será relatado como um problema de desempenho, um problema de rede ou um travamento — não como um bug de migração. Essa é a mudança que vai para produção.

A correção é uma configuração de exibição, além de uma leitura que corresponda a ela:

• Defina thinking.display como "updates" — beta, atrás do thinking-display-updates-2026-08-18 cabeçalho — para recuperar as atualizações de progresso enquanto o raciocínio em si permanece oculto. Esta é a configuração que um feed de progresso deseja.

• Ou defina-o como "summarized" para receber atualizações de progresso e resumos de raciocínio misturados nos mesmos blocos.

• Em seguida, leia o texto dos blocos de pensamento em vez dos blocos de texto, renderize cada bloco de pensamento não vazio antes do bloco tool_use que ele precede e passe os blocos de volta inalterados com o restante do turno do assistente.

A própria nota da Anthropic sobre isso merece ser citada em espírito: espera-se que uma interface que renderiza texto entre chamadas de ferramentas defina um valor de exibição, em vez de depender do padrão. Se a sua integração ignora completamente os blocos de pensamento hoje, esse é o único lugar em que o padrão é seguro.

O esforço é a superfície da API

Com o thinking impossível de desativar, output_config.effort passa a ser o único controle de quanto o modelo raciocina e, portanto, o único controle de custo e latência em uma determinada tarefa. Vale a pena conhecer quatro coisas sobre isso antes de copiar uma configuração do modelo antigo.

O padrão mudou. Claude Opus 5.5 usa o esforço médio como padrão, enquanto Claude Opus 5 e modelos Opus anteriores definiam o esforço alto como padrão. Uma solicitação que omite o esforço agora é executada um nível abaixo do que era antes da troca. A Anthropic também documenta que o modelo tende a pensar mais por turno em uma determinada configuração de esforço do que o Claude Opus 5 fazia, principalmente em xhigh e max. Esses dois efeitos empurram em direções opostas, e é exatamente por isso que a instrução do fornecedor é realizar uma nova varredura de esforço em suas próprias avaliações, em vez de transpor uma configuração.

A escala é low / medium / high / xhigh / max, todos os cinco suportados aqui. O nível nomeado não é, para começar, um orçamento fixo de tokens — a Anthropic descreve o esforço como um sinal comportamental, não um orçamento estrito — e a alocação de tokens por trás de cada nível mudou entre os modelos, portanto "high" no Claude Opus 5.5 não é "high" no Claude Opus 5. Definir o esforço como o padrão do modelo é idêntico a omiti-lo.

Dois detalhes operacionais, porque ambos custam dinheiro quando passam despercebidos. Primeiro, alterar o valor de esforço de nível superior entre requisições invalida o cache de prompt: escolha um nível e mantenha-o constante em uma conversa que depende de acertos de cache e, em vez disso, varie-o entre cargas de trabalho. Segundo, este modelo oferece suporte a esforço por mensagem (cabeçalho beta mid-conversation-output-config-2026-07-01), que altera o nível a partir de um turno posterior sem reiniciar o cache. O mínimo do cache de prompt aqui é 512 tokens, abaixo dos 1.024 da geração anterior, então prompts que antes eram curtos demais para entrar no cache agora podem criar entradas sem qualquer alteração no código.

Limites de saída: 128K síncrono, 300K em Batch

A API Messages síncrona limita a saída a 128K tokens. A API Message Batches vai até 300K tokens de saída por trás do output-300k-2026-03-24, cabeçalho beta — exatamente essa string. A entrada é a janela de contexto completa de 1M tokens por padrão, sem necessidade de cabeçalho.

A leitura prática: o teto de 128K permanece inalterado em relação ao Claude Opus 5, então nada em uma integração síncrona exige recalcular o orçamento apenas nesse eixo. O que exige recalcular o orçamento é o raciocínio dentro dela. Como max_tokens agora cobre raciocínio e texto em todas as solicitações, um valor que era justo para o texto de resposta no Claude Opus 5 fica mais apertado aqui — e, em xhigh ou esforço máximo, o fornecedor sugere começar em 64k e ajustar. Se um trabalho de longa duração foi dimensionado para o teto síncrono de 128K e agora sofre truncamento, não foi o teto que mudou.

O roteamento do Safeguard faz parte da especificação.

Isto é um fato de integração, não uma nota de rodapé de política: em alguns prompts, a string de modelo que você envia não descreve o que respondeu.

O Claude Opus 5.5 vem com classificadores de segurança, e uma solicitação recusada retorna como HTTP 200 com stop_reason: "refusal" e um stop_details objeto que nomeia a área da política. Este modelo cobre mais categorias do que o Claude Opus 5 — espere bio, frontier_llm e reasoning_extraction ao lado do familiar cyber. A recusa de reasoning_extraction é bloqueada de imediato em vez de ser tentada novamente: o fallback do lado do servidor da Anthropic não a tenta novamente, e a recusa é devolvida a você.

Para as categorias que fazem nova tentativa, o mecanismo é um parâmetro. Defina fallbacks como "default" com o server-side-fallback-2026-07-01 cabeçalho beta e a API reexecuta uma solicitação recusada no modelo que a Anthropic recomenda para essa categoria, dentro de uma única chamada, retornando uma resposta. A central de ajuda da Anthropic nomeia o roteamento para esse modelo diretamente: solicitações sinalizadas de cibersegurança recorrem ao Claude Opus 4.8, e seus classificadores de biologia — o conjunto no estilo Fable-5 — provocam um fallback para Claude Opus 5 para trabalhos de ciências da vida de uso dual. Um conjunto restrito de capacidades de desenvolvimento de LLMs de fronteira também é roteado para o Claude Opus 5. A Anthropic também observa que as verificações revisam tudo o que o modelo lê, não apenas sua mensagem mais recente, então memória, conteúdo de conectores, resultados de busca e arquivos podem acionar uma troca.

Três coisas decorrem para a sua integração. Leia o campo de nível superior model em todas as respostas, porque ele informa qual modelo realmente produziu a mensagem, e um fallback marca cada ponto de transferência. Verifique os próprios limites de taxa do fallback, porque um fallback com limite de taxa não é tentado e a recusa é retornada em seu lugar — os fallbacks degradam para recusas sob carga. E trate qualquer execução de benchmark publicada com as salvaguardas habilitadas como uma medição do sistema roteado, e não apenas do Claude Opus 5.5, que é exatamente o que a Anthropic diz sobre seus próprios números abaixo.

O fallback do lado do servidor está em beta e é exclusivo da Claude API: não é suportado na Message Batches API e não está disponível na Amazon Bedrock, Google Cloud ou Microsoft Foundry, onde, em vez disso, o middleware do SDK é o caminho documentado. Do lado da verificação, existem vias de acesso para ambas as categorias — o Cyber Verification Program e o Life Sciences Verification Program —, mas note a assimetria que o centro de ajuda da Anthropic documenta à data desta redação: o Claude Opus 5.5 não está atualmente listado no Cyber Verification Program, enquanto o programa de ciências da vida é descrito como dando às organizações verificadas acesso aos modelos mais capazes.

Contexto, corte, descontinuação e modo rápido

O restante do envelope, da página do modelo e da tabela de depreciações:

• Janela de contexto — 1M tokens, padrão, sem cabeçalho beta.

• Data de corte de conhecimento — junho de 2026, que também é a data de corte dos dados de treinamento.

• Desativação — não antes de 2027-09-22 nas plataformas operadas pela Anthropic, com pelo menos 60 dias de aviso prévio. A Amazon Bedrock e o Google Cloud definem suas próprias datas. O Claude Opus 5 permanece Ativo até pelo menos 2027-07-24, portanto não há migração forçada.

• Tabela de preços — US$ 4,00 por milhão de entrada, US$ 20,00 por milhão de saída, US$ 5,00 por milhão de gravações em cache de 5 minutos, US$ 8,00 por milhão de gravações em cache de 1 hora, US$ 0,20 por milhão de leituras de cache. O modo batch custa metade do preço em ambos os sentidos, a US$ 2,00 / US$ 10,00.

• As leituras de cache são o valor atípico que vale a pena notar: US$ 0,20 é 5% da entrada base, enquanto a maioria dos modelos Claude fica em 10% e o Claude Fable 5.1 em 2,5%. Cargas de trabalho mistas com uso intenso de cache percebem isso como um desconto real.

• Modo rápido — ainda documentado como prévia de pesquisa, somente na API Claude, com preço separado de US$ 8,00 de entrada / US$ 40,00 de saída por milhão. Ative com speed: "fast" e o fast-mode-2026-02-01 cabeçalho beta. Ele não está disponível no Bedrock, na Claude Platform on AWS, no Google Cloud ou no Microsoft Foundry, nem com a Batch API, nem com um compromisso do Priority Tier. Observe que o Claude Opus 5.5 não oferece suporte ao Priority Tier de modo algum.

O que os benchmarks dizem, e em qual configuração

As configurações de esforço são a razão pela qual uma tabela de fornecedor e uma tabela independente não podem ser comparadas linha a linha, e por que cada número abaixo carrega sua configuração.

Reportado pelo fornecedor, pelo próprio harness da Anthropic. A nota de lançamento da Anthropic afirma que, salvo indicação em contrário, todos os resultados do Claude Opus 5.5 usam raciocínio adaptativo com esforço máximo; a exceção é o Terminal-Bench 4.0, reportado em xhigh para o Claude Opus 5.5 e high para o GPT-6 Astra, porque essas são as pontuações mais altas de cada modelo. Com base nisso, o fornecedor reporta o Terminal-Bench 4.0 em 66.4%, o FrontierCode v1.1 Main em 54.4%, o CursorBench 4.0 em 57.8%, o GDPval-AA v2.1 em 1,846 Elo, o AutomationBench em 40.0%, o Humanity's Last Exam com ferramentas em 67.7%, o Terminal-Bench-Science 0.1 em 58.7%, o OSWorld 2.0 em 81.8% parcial e o Chartography com ferramentas em 89.0%. No esforço médio padrão do modelo, o fornecedor informa o FrontierCode em 54.6% e o CursorBench em 52.5%. Observe o que a mesma nota divulga: as avaliações foram executadas com as salvaguardas de produção ativadas e, quando estas foram acionadas, as tarefas de cibersegurança foram concluídas pelo Claude Opus 4.8, e as tarefas de biologia e de desenvolvimento de LLMs de fronteira, pelo Claude Opus 5 — a Anthropic diz que isso provavelmente reduz o desempenho do Claude Opus 5.5 nesses benchmarks. As pontuações publicadas nas avaliações afetadas, portanto, não são medições limpas desse modelo.

Independente, Artificial Analysis. No Intelligence Index v4.3.2, o Claude Opus 5.5 obtém 58 na configuração que a Artificial Analysis rotula como "Adaptive Reasoning, Max Effort, Default Fallback" — sua pontuação medida mais alta, por vários pontos de diferença, e lidera seis das dez avaliações que o compõem. No mesmo índice e no mesmo harness, o Claude Fable 5.1 pontua 53 e o Claude Opus 5 pontua 51. A Artificial Analysis publica a escada completa de esforço, que é o artefato independente mais útil aqui: max 58, xhigh 56, high 54, medium 51, low 42. Suas próprias medições colocam o Claude Opus 5.5 em cerca de 119.000 tokens de saída por tarefa do índice em esforço máximo, contra cerca de 73.000 para o Claude Opus 5, 78.000 para o Claude Fable 5.1 e 27.000 para o GPT-6 Astra — tokens cobrados como tokens de saída — e sua página relata um custo de US$ 5,98 por tarefa do índice. Ela também mede o Terminal-Bench 4.0 em 59,6% e o Humanity's Last Exam em 61,4%, contra os 66,4% e 67,7% do fornecedor em esforço máximo em um harness diferente.

Leia esses dois parágrafos em contraposição e a conclusão honesta é restrita. Os 66,4% do Terminal-Bench do fornecedor e os 59,6% independentes são o mesmo benchmark executado por pessoas diferentes em configurações sem garantia de correspondência, e nenhum dos dois é evidência sobre sua carga de trabalho. A escala de esforço é a descoberta transferível: em um índice independente, as próprias configurações deste modelo abrangem dezesseis pontos, uma dispersão maior que a diferença entre ele e seu antecessor. Escolher um nível de esforço importa mais do que escolher entre esses modelos, e a cláusula "Default Fallback" naquele rótulo é o roteamento de salvaguarda descrito acima, não um artefato do benchmark.

Eficiência relatada pelo fornecedor, com atribuição. A Anthropic diz que o Claude Opus 5.5 tem desempenho no nível do Claude Fable 5.1 na maioria dos trabalhos, com custo de execução cerca de 40% menor, e que cargas de trabalho típicas custam cerca de 40% menos do que no Claude Opus 5, frente a um corte de 20% no preço de tabela. A saída é mais de 30% mais rápida. Essas são caracterizações do fornecedor de médias entre cargas de trabalho selecionadas pelo fornecedor. As declarações de clientes feitas no lançamento são o mesmo tipo de evidência: Box relata um terço dos tokens, e respostas cerca de 40% menos verbosas; Kiro, aproximadamente metade dos tokens e cerca de 40% menos chamadas; Factory, 20–25% menos tokens de saída; GitHub, entre os menores números de tokens e etapas que já mediu. A Anthropic também relata um teste interno de verificação de fatos no qual 16 de seus 18 relatórios superaram um patamar de qualidade que nem o Claude Fable 5.1 nem o Claude Opus 5 conseguiu superar em nenhuma tentativa. Tudo isso é relatado pelo fornecedor e nada disso é auditado. A limitação divulgada é excepcionalmente franca e vale a pena registrar: a Anthropic diz que o Claude Opus 5.5 "frequentemente suspeita que está sendo avaliado".

Por fim, os modelos irmãos: a Anthropic diz que Claude Sonnet 5.5 e Claude Haiku 5.5 chegam "nas próximas semanas". Nenhum foi lançado, nenhum tem preço definido e nenhum está disponível em nenhuma superfície hoje.

Testando as quatro alterações sem uma migração completa

O risco de migração aqui não é a qualidade — é que um caminho de código que você nunca exercitou em staging é justamente o que retorna 400 em produção. As quatro mudanças incompatíveis são todas mudanças no formato da requisição, o que significa que falham de forma determinística e imediata, e a única maneira de encontrar os caminhos que você deixou passar é rodar tráfego real por eles.

O Claude Opus 5.5 está no OrcaRouter como anthropic/claude-opus-5.5pelo preço de tabela da própria Anthropic, com 0% de markup — o preço de tabela do provedor é repassado, então uma mudança de preço do fornecedor já fica no ar aqui no mesmo dia.

Isso permite direcionar uma porcentagem do tráfego de produção para o modelo enquanto o restante continua rodando no Claude Opus 5, observar quais requisições falham e por quê, e corrigi-las uma de cada vez. Os quatro erros são autoexplicativos: cada um nomeia o parâmetro que rejeitou e, em três dos quatro casos, a substituição. O failover automático cobre a lacuna enquanto um caminho ainda está quebrado — uma requisição que falha contra um modelo que você ainda não caracterizou completamente recorre a um que você já caracterizou, em vez de expor o 400 a um usuário.

Uma ordem prática de trabalho: troque o id do modelo e defina o esforço explicitamente primeiro, já que o padrão passou para medium; em seguida, remova os caminhos de thinking desativado e de escolha forçada de ferramenta; depois, corrija o leitor de streaming — seleção de blocos por tipo e a configuração thinking.display —, porque é o que falha silenciosamente, e não ruidosamente; e deixe a migração do conjunto de ferramentas de computer-use para o final se você estiver no Bedrock, já que é a que não se aplica lá. Todo o resto — preço, janela de contexto, taxas de cache e o padrão de 1M tokens — já está onde você deixou.

Encaminhe uma parte do tráfego em tempo real para o novo modelo sem uma migração completa: Claude Opus 5.5 no OrcaRouter é executado pelo preço de tabela da Anthropic com failover automático para um modelo que você já caracterizou.