O reajuste que está anunciado, e o que não está
A Anthropic lançou o Claude Sonnet 5 em 30 de junho de 2026 com preço de lançamento: US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de saída, válido até 31 de agosto. Em 1º de setembro o preço padrão passa a ser US$ 3 e US$ 15. São 50% a mais na etiqueta. Está documentado, cabe numa célula de planilha, e quase todo time que usa a API já anotou a data no calendário.
O que não veio na mesma frase do anúncio é o resto: o Sonnet 5 roda num tokenizer novo, e esse tokenizer conta mais peças para o mesmo texto de sempre. Times que mediram o consumo real entre Sonnet 4.6 e Sonnet 5 no mesmo payload acharam de 1,0x a 1,35x mais tokens para o mesmo conteúdo, com média por volta de 30% a mais. Prompt de código, cheio de pontuação e identificador, vai para o topo da faixa. Texto corrido em português fica perto do piso.
A conta prática incomoda mais que o comunicado. Um workload que custava US$ 1.000/mês no Sonnet 4.6 tende a custar perto de US$ 1.300/mês no Sonnet 5 ainda dentro do preço de lançamento, só pelo efeito do tokenizer, sem nenhum reajuste de tabela envolvido. Depois de 1º de setembro, com o preço novo aplicado em cima de uma contagem já inflada, o mesmo workload gira perto de US$ 1.950/mês. Não é aumento de 50%, é de quase 100%. E metade desse aumento está escondida na forma como o modelo conta o próprio texto, num lugar onde ninguém pensa em olhar.
Preço por token é a etiqueta da prateleira. O que a fatura mede é quantas peças o carrinho levou.
Por que comparar preço por token engana
A tabela de preço por milhão de tokens é o primeiro número que qualquer time olha na hora de escolher modelo. Também é o número errado para decidir sozinho. Dois modelos com tokenizers diferentes não gastam a mesma quantidade de tokens para fazer o mesmo trabalho, e a tabela não tem coluna para isso.
| Modelo | Entrada (US$/MTok) | Saída (US$/MTok) | Observação |
|---|---|---|---|
| Claude Haiku 4.5 | 1 | 5 | tokenizer anterior |
| Claude Sonnet 4.6 | 3 | 15 | tokenizer anterior |
| Claude Sonnet 5 (até 31/08) | 2 | 10 | tokenizer novo, 1,0x a 1,35x mais tokens |
| Claude Sonnet 5 (a partir de 01/09) | 3 | 15 | tokenizer novo, 1,0x a 1,35x mais tokens |
| Claude Opus 5 | 5 | 25 | tokenizer novo |
Olhando só a coluna de preço, o Sonnet 5 parece barganha até agosto e depois empata com o Sonnet 4.6. Empata em preço por token, é verdade. Perde em custo por tarefa, porque o denominador mudou embaixo do preço: quantos tokens a sua tarefa consome deixou de ser o mesmo número de antes.
O que torna isso traiçoeiro é o atraso. Você troca de modelo numa terça, os testes passam, a latência melhora, ninguém reclama. A conta só aparece semanas depois, junto com todo o resto do mês, e aí já não dá para saber se o que subiu foi o tokenizer, o volume de usuários ou aquele agente novo que alguém colocou em produção sem avisar.
Como medir antes de decidir
Comparar direito começa antes da planilha. Pegue um payload seu, de verdade, e rode contra o endpoint de contagem de tokens antes de trocar de modelo em produção.
curl https://api.anthropic.com/v1/messages/count_tokens \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"messages": [{"role": "user", "content": "cole aqui um prompt real do seu produto"}]
}'
Rode o mesmo payload contra o modelo atual e contra o candidato, compare a contagem que volta e só então multiplique pelo preço de cada um. Duas linhas de diferença na sua planilha valem mais que qualquer benchmark público, porque benchmark público não usa o seu prompt de sistema, o seu histórico de conversa nem o seu schema de ferramentas. E é justamente aí que mora o volume: na maioria dos produtos que a gente vê, o texto que o usuário digita é a menor parte do que sai na fatura.
Medir é o começo. Depois vêm as alavancas. Prompt caching cobra 0,1x o preço de entrada quando dá cache hit, então prompt de sistema grande que se repete a cada chamada devolve boa parte do que o tokenizer levou. A Batch API sai com 50% de desconto para o que não precisa de resposta na hora, o que reescreve a conta de qualquer pipeline de processamento em lote.
O que fazer na segunda de manhã
Se você já está no Sonnet 5, roda o count_tokens contra os três ou quatro prompts que mais pesam na fatura e compara com a contagem que o Sonnet 4.6 fazia para o mesmo texto. Isso dá o multiplicador do seu workload. Os 30% de média que circulam por aí são o workload de outra pessoa.
Se ainda não migrou e 1º de setembro está chegando, decide com o multiplicador que você mediu, não com a tabela. E se o seu produto tem prompt de sistema grande e repetido, liga prompt caching antes de qualquer outra otimização. É o ajuste que devolve mais dinheiro por menos esforço nessa mudança específica.
A gente audita esse tipo de consumo antes de trocar modelo em qualquer projeto de IA e automação que constrói. Decisão de stack sem medir o próprio payload é decisão tomada com o número errado.
