Por que o Claude Sonnet 5.5 sai mais barato por tarefa se o preço por token é o mesmo?

O preço por token do Claude Sonnet 5.5 não mudou nada, e mesmo assim a sua conta pode cair

Fala aí, beleza? A Anthropic soltou o Sonnet 5.5 em 28/09/2026, uma semana depois do Opus 5.5

Ele é o segundo modelo da família Claude 5.5, e veio com a mesma tabela de preço do Sonnet 5 🙂

Aí vem a pergunta que motivou este post: se a tabela é igual, de onde vem a economia?

A resposta está na diferença entre preço de tabela e gasto real, e é isso que eu vou destrinchar aqui, linha por linha da fatura

Quanto custa o Claude Sonnet 5.5 na API?

Primeiro os números oficiais, com o Sonnet 5 e o Opus 5.5 do lado pra comparação:

Se liga em algumas regras gerais da tabela de preços dos modelos Claude atuais:

• Leitura de cache custa 10% do input base (por isso os US$ 0,20 do Sonnet 5.5)
• Escrita de cache custa 1,25x o input com duração de 5 minutos, ou 2x com duração de 1 hora
• Batch API dá 50% de desconto em input e output

O Sonnet 5.5 está disponível direto pela Anthropic e também na Amazon Web Services, no Google Cloud e no Microsoft Azure

Se tu curte essa parte de história, vale ver como o preço por token mudou de uma geração do Claude pra outra

Qual a diferença entre preço por token e custo por tarefa?

Preço por token é a tarifa, tipo o preço do litro da gasolina

Custo por tarefa é quanto tu gastou pra chegar no destino, e isso depende de quanto o carro bebe no caminho 😀

Na prática, o custo de uma tarefa é: tokens de input vezes a tarifa de input, mais tokens de output vezes a tarifa de output, mais os tokens de cache lidos vezes a tarifa de cache

E tudo isso somado em TODAS as chamadas que a tarefa precisou, inclusive as chamadas de ferramenta que o agente faz no meio do caminho

Exemplo hipotético: mesmo preço, conta diferente

Aqui é só pra ilustrar a lógica da conta, beleza? Não tem teste nenhum por trás, só os preços é que são os oficiais

Tarefa rodada de um jeito mais gastão:

• Muito input lido, e relido a cada chamada de ferramenta, a US$ 2 por milhão
• Muito output gerado até chegar na resposta, a US$ 10 por milhão
• Total: a soma de tudo isso, em todas as chamadas

A mesma tarefa, mesma tarifa, gastando menos tokens:

• Menos input, porque o agente faz menos idas e voltas, ainda a US$ 2 por milhão
• Menos output pra chegar na mesma resposta, ainda a US$ 10 por milhão
• Total: menor, com a MESMA tarifa

A tabela não mudou um centavo, e a conta ficou menor, simples assim

Por que cortar output pesa mais?

Porque no Sonnet 5.5 o output custa 5x o input (US$ 10 contra US$ 2)

Ou seja, cada token de output que o modelo deixa de gerar economiza 5x mais que um token de input a menos

Então um modelo que fala menos pra chegar na mesma resposta economiza MUITO mais do que um que só lê menos

Onde a economia do Sonnet 5.5 aparece na fatura?

Segundo a Anthropic, o Sonnet 5.5 reduz em até 30% o custo por tarefa, principalmente porque usa menos tokens e menos chamadas de ferramenta, e não por causa de tarifa menor

Bora ver onde isso bate em cada linha da fatura:

1. Menos tokens de output

É a linha mais cara da conta, como a gente viu ali em cima

Qualquer corte aqui rende 5x mais que o mesmo corte no input

2. Menos chamadas de ferramenta

Que chamada de ferramenta? É quando o agente para, lê um arquivo, roda uma busca, e volta pro modelo com o resultado

Cada ida e volta vira uma nova chamada, e o contexto vai junto de novo, então menos chamadas significa menos contexto repetido cobrado

A Lovable relatou que, nas avaliações de código dela, o Sonnet 5.5 usou cerca de um terço a menos de chamadas de ferramenta

3. Leitura de cache a US$ 0,20

Contexto que se repete (instruções do sistema, documentação, código base) pode vir do cache

Ler do cache custa US$ 0,20 por milhão de tokens, contra US$ 2 por milhão se o mesmo contexto fosse cobrado como input normal

A escrita de cache custa mais que o input, mas se paga depois de 1 leitura no cache de 5 minutos ou de 2 leituras no de 1 hora

4. Nível de effort padrão

O effort padrão do Sonnet 5.5 muda conforme onde tu usa: no Claude Code e nos apps de consumo da Anthropic é Medium, na Claude Platform (API) é High

Isso importa porque a mesma tarefa pode consumir diferente dependendo do produto, então não compare número do Claude Code com número da API como se fosse a mesma coisa

5. Batch API pro que não tem pressa

Se a tarefa não precisa de resposta na hora (processar um lote de documentos, por exemplo), a Batch API dá 50% de desconto em input e output

E a velocidade?

O Sonnet 5.5 gera output mais de 30% mais rápido que o Sonnet 5

Isso muda o TEMPO da tarefa, não a tarifa, tome cuidado pra não misturar as duas coisas na hora de fazer a conta

Menos tokens desperdiçados, tarefa mais rápida: o que eu vi na prática

O teste que eu fiz foi com o FastContext, uma skill que delega a busca de contexto no repositório pra outra IA, mais barata, enquanto o Opus fica só com a resposta final dentro do Claude Code

A lógica é a mesma que a Anthropic usa pra explicar a economia do Sonnet 5.5: a tarefa custa o que ela consome, e contexto desperdiçado é tempo e dinheiro jogados fora

Instalei no Windows via WSL e foi de boa, sem complicação nenhuma

Antes de ligar no agente, rodei o FastContext isolado pra ver se a busca funcionava, perguntando onde ficava a lógica de autenticação e o que precisaria mudar pra aceitar login por token

Aí comparei a mesma pergunta com e sem a skill:

• Com FastContext: cerca de 40 segundos
• Sem FastContext: passou de 50 segundos (tempo aproximado, não cronometrei com precisão)

Sem a skill demorou mais

Depois refiz o teste com o mesmo prompt, mandando usar o FastContext de forma explícita

Ficou em 40 e poucos segundos, um pouco mais que o primeiro, mas ainda na frente do teste sem a skill

Não medi consumo de tokens nem economia em dólar nesse teste, só o tempo, então não vou inventar número aqui

A lição que fica é: cortar contexto inútil encurta a tarefa, e é exatamente essa a aposta do Sonnet 5.5

Minha opinião: no meu teste o FastContext deixou a resposta mais rápida, mas exige um setup inicial pra funcionar

A dica é configurar a busca com um modelo mais simples dentro da assinatura que tu já usa, em vez de deixar a IA mais cara vasculhando o repositório, e o cenário ideal seria até um modelo local pra essa parte

No vídeo abaixo eu mostro a instalação, o teste isolado e as duas comparações de tempo, bem na prática:

Em quais tarefas o custo menor do Sonnet 5.5 tende a aparecer?

A cobertura do lançamento cita quatro casos pra que o Sonnet 5.5 foi treinado, e cada um consome tokens de um jeito diferente:

• Geração de documentos: output longo, que é justamente a linha mais cara, então gerar o mesmo documento com menos tokens pesa bastante
• Resumos: muito input e contexto que se repete quando tu resume várias partes do mesmo material, cenário bom pro cache
• Planilhas: costuma envolver várias idas e voltas até o resultado ficar certo, e cada chamada a menos conta
• Correção de bugs de código: o agente lê arquivo, busca, testa, e aí o número de chamadas de ferramenta faz toda a diferença

Nenhuma dessas tarefas vem com percentual garantido, beleza? O "até 30%" é um teto, não uma promessa por caso

Sonnet 5.5 ou Opus 5.5: qual sai mais barato para o seu projeto?

No preço de tabela não tem discussão: o Opus 5.5 custa o dobro por token (US$ 4 e US$ 20 contra US$ 2 e US$ 10)

E segundo a Anthropic, o Sonnet 5.5 chega perto do Opus 5.5 em vários testes da empresa (ela não trouxe números de ranking nessa comparação)

Pra quem já usa o Sonnet 5, a troca é tranquila: a tarifa é a mesma e o custo por tarefa pode cair

Mas se liga: o "até 30%" é o teto informado pela própria Anthropic, e a economia real depende da sua carga de trabalho

Meu veredito: pra maioria das tarefas do dia a dia, o Sonnet 5.5 tem tudo pra ser o daily driver mais barato, e o Opus 5.5 fica pro que realmente pede mais músculo

Só não conclua nada pela manchete, mede antes 😛

Como saber se o Sonnet 5.5 está mesmo reduzindo sua conta?

O resumo do post é: para de comparar só a tabela e começa a comparar custo por tarefa

O preço do Claude Sonnet 5.5 por token é o mesmo do Sonnet 5, então a economia, se vier, vem de gastar menos tokens e fazer menos chamadas

O próximo passo prático é simples:

1. Escolhe uma tarefa real do teu projeto, dessas que tu roda toda semana
2. Roda a mesma tarefa no modelo que tu usa hoje e no Sonnet 5.5
3. Compara os tokens de input, output e cache consumidos em cada um, e multiplica pelas tarifas da tabela
4. Onde couber, considera o cache pro contexto repetido e a Batch API pro que não tem pressa

O erro comum no passo 2 é comparar produtos diferentes: lembra que o effort padrão é Medium no Claude Code e High na API, então compara sempre no mesmo lugar

É o mesmo exercício que a gente fez com o Kimi K3 no n8n, olhando quanto a conta de tokens realmente cai em vez de confiar só na tarifa

Mediu e a conta caiu? Massa, tá provado no teu caso 🙂

Não caiu? Também é informação valiosa, e tu economizou o hype…

Beleza? Até o próximo post! 😀