O orçamento que a gente refez duas vezes
Antes de trocar o modelo de um agente que já rodava em produção, a gente fez o que todo time faz. Pegou a planilha com a contagem de token do fluxo atual, multiplicou pelo preço por milhão do modelo novo, comparou com o que já se gastava. O preço por milhão era menor. A planilha dizia que a conta ia cair.
Rodou o piloto por alguns dias. A conta tinha subido.
Ninguém aumentou o volume de chamadas. O prompt era o mesmo, letra por letra, com o mesmo bloco de contexto recuperado do banco. O que mudou foi a unidade de medida.
Trinta por cento, escrito pela própria Anthropic
Está na documentação de contagem de token da Anthropic, na seção sobre os modelos mais novos: os modelos a partir do Claude Opus 4.7 usam um tokenizador diferente, e o mesmo texto produz cerca de 30% mais token do que nos modelos anteriores. A nota de versão que introduziu isso é de 9 de junho de 2026, quando o Claude Fable 5 e o Claude Mythos 5 foram lançados.
A documentação é direta sobre a consequência. Ela diz, com todas as letras, para não reaproveitar contagem de token medida em modelo anterior ao Opus 4.7 nem para estimar custo, nem para calcular se o prompt cabe na janela de contexto.
Trinta por cento não é ruído. É a diferença entre um orçamento que fecha e um que estoura no segundo mês.
Preço por milhão de token não é comparável entre gerações de modelo quando o que conta como token mudou. Você está comparando dois preços em unidades diferentes.
E isso acontece exatamente na hora em que o time menos desconfia: durante uma migração, quando a atenção está toda em qualidade de resposta e em quebra de contrato de API.
A conta de padaria que quase ninguém faz
A aritmética é simples e vale rodar antes da reunião de orçamento. Se o mesmo texto vira 30% mais token, o preço por milhão precisa cair 23% só para a conta empatar. Qualquer queda menor que isso é aumento disfarçado.
| Queda no preço por milhão | Efeito real na conta com 30% mais token |
|---|---|
| 0% | +30% |
| 10% | +17% |
| 20% | +4% |
| 23% | empata |
| 30% | menos 9% |
Olhe a linha dos 20%. Um anúncio de corte de um quinto no preço soa como economia garantida, e ainda assim a fatura sobe. Foi mais ou menos essa a distância entre a nossa planilha e o extrato.
Vale dizer o outro lado, porque ele é real. Em 10 de agosto de 2026 a Anthropic tornou permanente o preço promocional do Claude Sonnet 5, de 2 e 10 dólares por milhão de token de entrada e saída, cancelando o aumento para 3 e 15 que estava marcado para 1 de setembro. Preço caindo é bom e a direção do mercado continua sendo essa. O ponto é outro: a régua mudou junto, e quem só olha o preço não enxerga a régua.
O problema mais silencioso é o de contexto
Custo você descobre no fim do mês. Corte de contexto você descobre em produção, na resposta errada.
Quase todo agente sério tem um limite escrito em algum lugar do código: recupera documento até encher X token, aí para. Se esse limite foi calibrado com uma biblioteca local de contagem presa ao tokenizador antigo, ele passou a mentir. O contador local diz 100 mil, a API cobra e preenche a janela como se fossem 130 mil.
O agente não quebra com erro. Ele trunca. Perde o último documento da lista de recuperação, que muitas vezes é justamente o mais específico, e responde com confiança em cima do que sobrou. Depois alguém abre um chamado dizendo que a IA piorou.
O que a gente faz agora antes de trocar de modelo
A gente parou de estimar por planilha e passou a medir. O endpoint de contagem de token da Anthropic é gratuito e tem limite de requisição separado do limite de geração, então não existe desculpa de custo nem de cota para pular esse passo.
O teste é contar o mesmo request duas vezes, uma com a régua antiga e uma com a nova:
for M in claude-sonnet-4-6 claude-sonnet-5; do
echo -n "$M: "
curl -s 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\":\"$M\",\"messages\":[{\"role\":\"user\",\"content\":$(jq -Rs . < prompt-real.txt)}]}"
done
Duas observações sobre esse comando, porque o diabo mora aqui. Use um prompt real do seu tráfego, com o contexto recuperado dentro, não um exemplo de três linhas: os 30% são uma média e o número muda conforme o tipo de conteúdo. Código, JSON e texto em português não inflam igual. E inclua o bloco de definição de ferramentas no request, porque ele conta como entrada em toda chamada e costuma ser a parte mais gorda de um agente com muitas ferramentas.
Depois disso, a razão entre as duas contagens é o seu fator de correção. É esse número que entra na planilha, não os 30% da documentação.
Na segunda de manhã
Pegue os cinco prompts mais frequentes do seu produto, os que respondem pela maior parte do volume. Rode a contagem dupla neles. Se o fator ficar perto de 1,3, refaça a projeção de custo do trimestre com o número novo antes de levar qualquer proposta de migração para a mesa.
Depois procure no código onde está escrito o limite de token do contexto e confira com o que a API conta hoje, não com o que a biblioteca local conta. Se os dois discordam, o limite está errado desde a última troca de modelo.
É um trabalho de meia manhã. A gente descobriu isso do jeito caro, olhando fatura, e o jeito barato estava a um curl de distância. Quando a Overflow faz diagnóstico de IA e automação numa operação que já tem agente rodando, essa contagem virou item fixo da primeira semana.
