DEV Community

Cover image for Migrando do Claude Opus 5 para o Opus 5.5: o que muda para quem faz chamadas à API
Lucas
Lucas

Posted on Originally published at apidog.com

Migrando do Claude Opus 5 para o Opus 5.5: o que muda para quem faz chamadas à API

Migrando do Claude Opus 5 para o Opus 5.5: o que muda para quem faz chamadas à API

A Anthropic lançou o Claude Opus 5.5 em 22 de setembro de 2026. Para quem chama a API do Claude, a atualização é uma string: claude-opus-5 passa a ser claude-opus-5-5.

Experimente o Apidog hoje

O que está por trás dessa string é 20% mais barato por token nas duas direções, limita uma única resposta a 128.000 tokens de saída, promete produzir saída 30% mais rápido e foi construído para permanecer em uma única tarefa por 18 horas ou mais. Nada disso é isento de consequências para o código que você ajustou para o Opus 5.

Este é o segundo salto de migração nesta linha de modelos e ele não se parece em nada com o primeiro. Opus 4.8 para Opus 5 foi uma migração de correção: os padrões mudaram por baixo de código que funcionava, e uma combinação de requisição antes válida passou a retornar um 400 rígido. Este salto é uma migração de orçamento e de envelope operacional. O trabalho está em remedir números que você já mediu uma vez, porque todos eles mudaram. O Opus 5.5 também chegou no mesmo dia que dois novos modelos da OpenAI, o que é uma história à parte.

O diff, nas únicas células que conseguimos comprovar

Item Opus 5 Opus 5.5 Alteração
ID do modelo claude-opus-5 claude-opus-5-5 uma string
Entrada, por milhão de tokens $5.00 $4.00 20% menos
Saída, por milhão de tokens $25.00 $20.00 20% menos
Escrita em cache, por milhão ver página do fornecedor $5.00 desconhecido
Leitura de cache, por milhão ver página do fornecedor $0.20 desconhecido
Modo rápido, por milhão ver página do fornecedor $8.00 de entrada, $40.00 de saída desconhecido
Máximo de tokens de saída ver página do fornecedor 128.000 desconhecido
Janela de contexto ver página do fornecedor 1.000.000 desconhecido

As células em branco são propositais. A Anthropic publicou o lado do Opus 5.5 na página do modelo, e não vamos reconstruir o lado do Opus 5 de memória, porque um número errado em um modelo de custos é pior do que um número ausente. Extraia essas cinco linhas da página de preços da Anthropic antes de construir uma estimativa de economia em cima delas.

1. A mudança de ID é real, os 20% são reais, os 40% precisam de leitura atenta

Troque a string e você paga 20% menos por token nas duas direções. Essa parte é aritmética: de $5 para $4 na entrada, de $25 para $20 na saída, o mesmo corte dos dois lados.

A Anthropic também afirma que o Opus 5.5 custa 40% menos para operar do que o Opus 5. Esses dois números não estão em conflito, mas também não são a mesma afirmação. Um corte de 20% por token não consegue, sozinho, produzir uma redução de 40% na fatura. A outra metade tem que vir do modelo usando menos tokens para concluir o mesmo trabalho, e a eficiência de tokens é específica de cada carga de trabalho de uma forma que uma tabela de preços não é.

Então trate os 40% como um motivo para remedir, e não como um número a ser jogado em uma previsão. Reexecute uma fatia representativa do tráfego real da semana passada contra os dois IDs de modelo, com prompts e configurações idênticos, compare os blocos usage em vez da sua impressão sobre eles, e multiplique as contagens reais de tokens pelas novas tarifas. Sua resposta vai cair em algum lugar entre 20% e 40%, e onde ela cair diz algo útil sobre quanto do seu prompt nunca foi necessário.

2. A linha de cache é a maior mudança de preço da tabela

As leituras de cache no Opus 5.5 custam $0.20 por milhão de tokens, contra $4.00 para entrada nova, um desconto de 95%. As escritas em cache custam $5.00 por milhão, um prêmio de $1.00 sobre os $4.00 que você teria pago para enviar esses tokens sem cache.

Esse prêmio se paga já no primeiro acerto, e ainda sobra. Escrever um prefixo custa $1.00 por milhão a mais do que não colocá-lo em cache. Cada leitura posterior desse prefixo economiza $3.80 por milhão. Você empata com aproximadamente um quarto de uma releitura, o que, na prática, significa: se o prefixo for reutilizado ao menos uma vez, colocá-lo em cache foi a decisão correta.

Veja o formato em um prompt de sistema de 200.000 tokens, que é um tamanho normal depois que você cola um pacote de especificações OpenAPI:

Padrão Custo para 10 chamadas
Entrada nova a cada chamada, $4.00/M $8.00
Escrever uma vez a $5.00/M, depois 9 leituras a $0.20/M $1.36

Os mesmos prompts, o mesmo modelo, 83% menos. A requisição que te leva à segunda linha marca o prefixo explicitamente:

{
  "model": "claude-opus-5-5",
  "max_tokens": 4096,
  "system": [
    {
      "type": "text",
      "text": "<your 200k-token spec bundle>",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "Which endpoints changed between v2 and v3?"}
  ]
}
Enter fullscreen mode Exit fullscreen mode

Depois leia a resposta para confirmar que você obteve um acerto, porque um cache que você acha que tem e não tem é o tipo mais caro:

"usage": {
  "input_tokens": 41,
  "cache_creation_input_tokens": 204800,
  "cache_read_input_tokens": 0,
  "output_tokens": 612
}
Enter fullscreen mode Exit fullscreen mode

Na primeira chamada, cache_creation_input_tokens carrega a carga. Em todas as chamadas seguintes, esse número deve cair para zero e cache_read_input_tokens deve assumi-la. Se isso não acontecer, algo em algum ponto anterior está alterando seu prefixo, geralmente um timestamp, um ID de requisição ou uma lista de ferramentas reordenada. Salvar uma chamada no Apidog e disparar duas vezes é a forma mais rápida de ver qual dos dois campos se move. Toda a aritmética, incluindo quando um contexto de 1M vale a pena colocar em cache, está em a matemática de custo de cache do Opus 5.5.

3. Uma resposta de 128.000 tokens é um problema do cliente antes de ser um problema do modelo

O Opus 5.5 retornará até 128.000 tokens de saída em uma única resposta. A $20 por milhão, isso dá $2.56 por uma única chamada no limite, o que vale saber antes que alguém defina max_tokens no teto dentro de um laço de retentativas.

A questão maior é tudo o que fica entre o modelo e o seu código:

  • Timeouts de leitura HTTP. Uma resposta tão longa leva minutos, não segundos. Os timeouts padrão de cliente na maioria dos SDKs e proxies reversos são mais curtos que isso.
  • Buffers de proxy e gateway. Um gateway que armazena o corpo inteiro antes de repassá-lo segura megabytes por requisição em andamento, e alguns simplesmente cortam a conexão.
  • Chamadas sem streaming. Sem streaming, você espera o tempo todo sem nada para mostrar e nada para marcar como checkpoint.
  • JSON truncado. Atingir max_tokens no meio de um objeto produz JSON inválido, não um objeto parcial que você possa recuperar. Verifique stop_reason antes de fazer o parse.

Aumentar max_tokens porque o teto subiu é a metade fácil. Fazer sua cadeia de timeouts, seus buffers e seu parser concordarem com o novo teto é a metade que causa o incidente.

4. Saída mais rápida não significa uma espera menor

A Anthropic afirma que o Opus 5.5 produz saída 30% mais rápido que o Opus 5. A velocidade de saída é um termo entre os que compõem a latência que você realmente entrega. O tempo até o primeiro token, as retentativas e o enfileiramento ficam ao lado dele, e um modelo que faz streaming mais rápido ainda pode parecer mais lento se pensar por mais tempo antes de o primeiro token chegar.

Então meça. Dispare um conjunto fixo de prompts representativos contra os dois IDs de modelo a partir da mesma posição de rede, e registre p50 e p95 separadamente para o tempo até o primeiro token e para o tempo total. A latência média esconde justamente o caso que derruba a sua página.

Se você mantém cenários de teste de API no Apidog, isso é um trabalho pequeno: clone uma requisição salva, mude o ID do modelo, execute as duas em uma agenda e leia a série temporal de tempos de resposta em vez de usar um cronômetro. O ponto é entrar na migração com um número de antes, porque depois que você fizer a troca não haverá como obtê-lo.

5. O modo rápido é exatamente o dobro da tabela

O modo rápido no Opus 5.5 custa $8.00 por milhão de entrada e $40.00 por milhão de saída. Colocados ao lado dos $4.00 e $20.00 padrão, a regra de preços é fácil de guardar na cabeça: o modo rápido é um 2x direto dos dois lados.

Isso transforma a decisão em aritmética, e não em julgamento: se a latência em uma determinada rota vale dobrar a conta de tokens dessa rota, use-o ali; caso contrário, não use. A divisão usual é modo rápido nos caminhos interativos e tarifas padrão no trabalho em lote e em segundo plano.

6. Trate a tabela de benchmarks como um motivo para testar, não como um resultado

Os números publicados pela Anthropic para o Opus 5.5 são fortes: Terminal-Bench 4.0 com 66,4%, FrontierCode v1.1 com 54,4%, CursorBench 4.0 com 57,8%, GDPval-AA v2.1 com 1846 Elo, AutomationBench com 40,0%, Humanity's Last Exam com 67,7% com ferramentas, OSWorld 2.0 com 81,8% e Chartography com 89,0%. A Artificial Analysis, um terceiro em vez de qualquer um dos fornecedores, o coloca em primeiro lugar entre 212 modelos em seu índice, com uma pontuação de 58.

Mais duas afirmações do fornecedor importam operacionalmente, e não competitivamente. O Opus 5.5 foi construído para permanecer em uma única tarefa por 18 horas ou mais, o que quebra muitas suposições comuns sobre timeouts, retentativas e retomabilidade. E a Anthropic relata 85% menos tentativas bem-sucedidas de contornar limites, o que é uma propriedade testável dos seus próprios endpoints e não uma propriedade que você herda.

Nada disso diz se o Opus 5.5 é melhor nos seus prompts. Execute seu próprio conjunto de avaliações nos dois IDs antes de colocar em produção, pelo mesmo motivo pelo qual você não faria o deploy de uma atualização de banco de dados com base nos números de benchmark do fornecedor.

Checklist de migração

  1. Altere claude-opus-5 para claude-opus-5-5 em um serviço, não em todos.
  2. Leia o guia de migração da Anthropic para este salto antes de presumir que a superfície de parâmetros não mudou. O salto de 4.8 para 5 moveu padrões silenciosamente, então verifique em vez de inferir.
  3. Reexecute uma fatia de tráfego real contra os dois IDs e compare os blocos usage.
  4. Recalcule seu gasto mensal a $4 e $20, e separadamente a $5 de escrita em cache e $0.20 de leitura de cache.
  5. Confirme os acertos de cache em cache_read_input_tokens em vez de confiar que o prefixo é estável.
  6. Aumente seus timeouts de leitura HTTP e verifique os buffers do gateway antes que alguém defina max_tokens perto de 128.000.
  7. Registre a latência p50 e p95 nos dois IDs antes de fazer a troca.
  8. Decida o modo rápido rota por rota, a 2x a tabela.
  9. Execute novamente seu próprio conjunto de avaliações. Os benchmarks do fornecedor são o motivo para testar, não o teste.

O Opus 5.5 é uma versão mais barata, mais rápida e de execução mais longa de um modelo que você já chama. O risco da migração não é a mudança de string falhar. É você carregar adiante um modelo de custos, um timeout e um valor de max_tokens que foram todos dimensionados para um modelo diferente.

FAQ

claude-opus-5-5 é um substituto direto de claude-opus-5? Trate-o assim somente após verificar o guia de migração da Anthropic para este salto. A mudança de ID é uma edição de uma linha, mas o salto anterior nesta linha moveu padrões sem alterar o formato da requisição, então a verificação é um seguro barato.

Quanto mais barato é o Opus 5.5? 20% menos por token nas duas direções, de $5 para $4 na entrada e de $25 para $20 na saída. A Anthropic afirma separadamente uma redução de 40% no custo de operação, o que implica ganhos de eficiência de tokens além do corte de tarifa. Meça sua própria carga de trabalho para ver em que ponto entre os dois você cai.

Quanto custa o cache de prompt no Opus 5.5? As escritas custam $5.00 por milhão de tokens e as leituras custam $0.20 por milhão, contra $4.00 para entrada sem cache. Uma única reutilização de um prefixo em cache já paga com folga o prêmio de escrita.

O limite de 128.000 tokens de saída muda algo no meu cliente? Normalmente sim. Verifique seus timeouts de leitura HTTP, o buffering do seu gateway e se você usa streaming. Verifique também stop_reason antes de fazer o parse, porque atingir o limite no meio de um objeto produz JSON inválido em vez de um objeto truncado.

Top comments (0)