Quanto custa o Claude Opus 5.5? Preço por token, leitura de cache e onde a conta cai

Fala aí, beleza? A Anthropic soltou o Opus 5.5 em 22 de setembro de 2026 e fez algo que quase nunca acontece em lançamento de topo de linha: baixou o preço

O Opus 5.5 é o modelo de ponta da casa pra raciocínio, código e trabalho agêntico de longo prazo, sucedendo o Claude Opus 5

E é justamente em trabalho agêntico que a conta fica estranha, porque o número que mais pesa na fatura não costuma ser o que você olha primeiro

Então bora destrinchar isso: entrada, saída, leitura de cache, escrita de cache, batch, fast mode e, principalmente, ONDE a conta cai de verdade

Tabela de preços do Opus 5.5: entrada, saída, cache e batch

Todos os valores são por milhão de tokens, direto da tabela oficial da API

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Pra ter ordem de grandeza em real, usa o câmbio do dia do lançamento: US$ 1 = R$ 5,124, dólar à vista (venda) na manhã de 22/09/2026

Só lembra que cotação muda todo dia, então converte na hora com o dólar atual pra saber o que cai de verdade no cartão 🙂

Repara numa coisa antes de seguir: a saída custa 5 vezes a entrada, e a leitura de cache custa 1/20 da entrada

Guarda esses dois números, eles explicam tudo o que vem depois

Opus 5.5 vs Opus 5: o que baixou e quanto

Aqui é onde fica claro que o lançamento mexeu no bolso, não só no benchmark

Olha o descompasso: entrada e saída caíram 20%, mas a leitura de cache caiu 60%

Isso não é acaso, é sinalização de para QUE tipo de carga esse modelo foi precificado

E a Anthropic vai além da tabela: ela afirma que o custo real de rodar o Opus 5.5 cai cerca de 40% em relação ao Opus 5, porque o modelo usa menos tokens pra concluir a tarefa e gera saída mais de 30% mais rápido

Aqui vale o ceticismo saudável: 20% é tabela, dá pra conferir na fatura

Os 40% são estimativa do fabricante sobre o comportamento do modelo, e comportamento varia com a sua tarefa

Quem acompanha preço de modelo há um tempo já viu esse filme, e comparar com o que o preço por token do Claude 3 Opus representava na época mostra bem o tamanho da queda acumulada

Onde a conta cai de verdade em um fluxo de agente

Agora a parte que interessa

Quando você roda um agente de código, ele não manda uma pergunta e vai embora

Ele relê o mesmo contexto (instruções, arquivos, histórico da sessão) a cada passo do loop, dezenas ou centenas de vezes

E aí a pergunta muda de "quanto custa 1 milhão de tokens de entrada?" pra "quanto custa reler os MESMOS tokens 50 vezes?"

Vamos ver na prática, com uma conta simples usando os preços de tabela

Imagina um contexto fixo de 200 mil tokens, relido 50 vezes ao longo de uma sessão longa

Isso dá 10 milhões de tokens de entrada no total

Sem cache:
10.000.000 tokens x US$ 4 / 1.000.000 = US$ 40

Com prompt caching:
escrita (uma vez, TTL 5 min):
200.000 x US$ 5 / 1.000.000       = US$ 1
leitura (50 vezes):
10.000.000 x US$ 0,20 / 1.000.000 = US$ 2
-------------------------------------------
total                             = escrita + leitura

Mesmo contexto, mesmo trabalho, e a linha de entrada despenca de US$ 40 pra uma fração disso

Não é mágica, é só a diferença entre pagar US$ 4 e pagar US$ 0,20 pelo mesmo milhão de tokens

E é por isso que a queda de 60% no cache read muda o orçamento de quem roda loop longo MUITO mais do que os 20% da entrada cheia

No Opus 5, essas mesmas 50 releituras custariam US$ 5 de leitura. Agora custam US$ 2

Agora soma a saída nesse cenário: com o contexto cacheado, quem passa a dominar a fatura é o que o modelo ESCREVE, a US$ 20 por milhão

Ou seja, a ordem de prioridade pra cortar custo em agente é: cacheia o que repete, depois controla o tamanho da saída, e só depois se preocupa com a entrada

Se você já fez esse tipo de conta com outros modelos, vai reconhecer a lógica de estimar custo por bilhão de tokens de entrada: muda a escala, o raciocínio é o mesmo

Quando vale usar cache, Batch API ou fast mode

São três alavancas diferentes e elas resolvem problemas diferentes. Não adianta ligar tudo e torcer

Cenário 1: prompt fixo grande e repetido

É o caso do agente de código, do assistente com base de conhecimento colada no prompt, do system prompt gigante

Aqui o prompt caching é obrigatório, não opcional

Dois detalhes que te salvam de frustração:

• o prompt precisa ter no mínimo 512 tokens pra ser cacheável no Opus 5.5. Abaixo disso, não adianta marcar nada
• você escolhe entre TTL de 5 minutos (US$ 5 por milhão escrito) e de 1 hora (US$ 8 por milhão escrito)

E a escolha do TTL é uma conta, não um gosto pessoal

Se a sessão tem pausas maiores que 5 minutos, o cache de 5 min expira e você paga a escrita de novo

Duas escritas de 5 min (US$ 10 por milhão) já saem mais caras que uma de 1 hora (US$ 8 por milhão), então sessão longa e intermitente tende a compensar o TTL maior

Cenário 2: volume grande e sem pressa

Classificar 200 mil registros, gerar resumo de um backlog inteiro, rodar avaliação em lote

Nada disso precisa de resposta em tempo real, e a Batch API aplica 50% de desconto sobre entrada e saída: US$ 2 e US$ 10 por milhão de tokens

E tem um bônus pra tarefa pesada: a Message Batches API suporta saída estendida de até 300 mil tokens de saída pro Opus 5.5, usando o cabeçalho beta output-300k-2026-03-24

Pra geração de documento longo ou refactor em massa, isso muda o que dá pra fazer numa chamada só

Cenário 3: trabalho interativo onde latência importa

Aqui entra o fast mode, um modo de maior throughput com preço próprio: US$ 8 por milhão de entrada e US$ 40 por milhão de saída

Ele está disponível no Claude Code e na Claude Platform, com aumento de throughput de até 2,5 vezes

Ou seja: você paga o dobro da tabela normal pra esperar menos

Faz sentido quando tem gente parada olhando pro terminal esperando a resposta, e faz zero sentido em job noturno que ninguém está acompanhando

Três detalhes que afetam a conta antes de você migrar

Tem coisa que não aparece em tabela nenhuma e mexe no planejamento. Tome cuidado com essas três

1. Sua chamada pode não rodar no Opus 5.5

A Anthropic usa classificadores de segurança (cibersegurança, biologia, desenvolvimento de LLMs de fronteira) e, quando um deles dispara, a requisição é reencaminhada pra Opus 4.8 ou Opus 5

Isso pode variar DENTRO de um mesmo fluxo de agente

Na prática, seu custo efetivo e seu comportamento observado podem não ser 100% Opus 5.5, mesmo você tendo pedido Opus 5.5

Se você trabalha com segurança ofensiva ou pesquisa em modelos, vale medir isso antes de fechar orçamento

2. Preserved Thinking

O Opus 5.5 traz o Preserved Thinking, medida antidestilação que já tinha aparecido antes no Fable 5.1

Ela impede que usuários da API editem o contexto anterior do Claude pra extrair o raciocínio do modelo

Se o seu pipeline mexia no histórico de raciocínio na mão, esse é o tipo de coisa que quebra na migração e você só descobre em produção 😛

3. O modelo passou por avaliação externa

O Opus 5.5 foi testado por avaliadores externos antes do lançamento, incluindo Frontier Design e METR

Isso não é linha de custo, mas é sinal de processo de release, e é informação útil pra quem precisa justificar a troca de modelo internamente

Vale migrar para o Opus 5.5?

Veredito honesto: depende muito menos do preço de tabela e muito mais do formato da sua carga

Se você roda agente de código, loop longo, contexto grande relido muitas vezes, a queda de 60% na leitura de cache sozinha já justifica olhar a migração com carinho. É a linha que mais dói nesse perfil e é a que mais caiu

Se você faz chamada avulsa, prompt curto, sem reuso de contexto, o ganho é o 20% de tabela e mais nada. Bom, mas não é evento

E os 40% de economia real que a Anthropic cita? Trata como hipótese a verificar, não como premissa de planilha. Pode ser que bata no seu caso, pode ser que não

Próximo passo prático, antes de trocar qualquer coisa:

1. Mede os tokens de cache read do seu fluxo atual, não o total de tokens. É esse número, multiplicado por US$ 0,20 por milhão, que vai dizer o tamanho real da economia
2. Separa o que é entrada cacheada do que é entrada nova. Se quase tudo é entrada nova, cache não vai te salvar e o problema está no design do prompt
3. Roda o mesmo prompt nas duas durações de cache (5 minutos e 1 hora) e compara a fatura, porque o padrão de pausa da sua sessão é que decide qual TTL vale

Depois disso a conta deixa de ser chute e vira número

E aí sim dá pra decidir com sossego, beleza? 😀

Até o próximo post!