Opus 4.7 da Anthropic gasta mais tokens: inflação oculta com os mesmos preços

A Anthropic lançou o Claude Opus 4.7, e os primeiros testes pela API mostraram algo inesperado: o mesmo texto no novo modelo pode ocupar bem mais tokens do que no Opus 4.6. Com preços formalmente inalterados, isso significa um aumento discreto, mas real, nos custos.

Qual é o problema

O tokenizador é o componente que divide o texto em fragmentos antes de enviá-lo ao modelo. É o número desses fragmentos que determina o custo da requisição e o espaço ocupado na janela de contexto. Quando a Anthropic muda o tokenizador entre versões, o mesmo prompt passa a "pesar" de outro jeito. No caso do Opus 4.7, o peso aumentou.

Se antes uma requisição típica ocupava 1.000 tokens, agora ela pode ocupar de 1.300 a 1.500. O preço por milhão de tokens não mudou, mas na prática você consome mais tokens pelo mesmo trabalho.

"O resultado é uma inflação oculta: preços e limites continuam os mesmos, mas na prática os custos podem aumentar" — de uma pesquisa da equipe da

Kodik.

A Kodik, que desenvolve um editor de código com suporte a vários modelos de IA, verificou por conta própria o comportamento do tokenizador pela API. A Anthropic não publicou dados comparativos oficiais, então os desenvolvedores fizeram os testes e compartilharam as conclusões.

Que tipo de conteúdo é mais afetado

O aumento de tokens não é igual para todos os tipos de texto. Com base nos dados disponíveis, o quadro é este:

• Código: aumento perceptível, principalmente em linguagens com muitos caracteres especiais: operadores, colchetes, indentação
• Strings técnicas (JSON, XML, YAML, SQL): as mudanças variam conforme a estrutura; construções aninhadas podem crescer mais
• Prompts de sistema: são afetados da mesma forma que as requisições do usuário; é especialmente sensível em produtos com instruções de sistema longas
• Texto comum: crescimento moderado, menos visível em requisições curtas
• Conteúdo misto (texto + código + JSON): o comportamento é imprevisível, vale testar para cada cenário específico

É preciso considerar a escala: se um prompt cresce 20% e você faz um milhão de requisições por dia, a conta real muda de forma muito significativa.

Por que é um problema sistêmico

O Opus 4.7 não é exceção. O tokenizador pode mudar em qualquer modelo de qualquer provedor, e nem sempre isso aparece de forma explícita nas notas de versão. Para equipes que constroem produtos sobre uma API, isso cria alguns riscos.

Surpresas no orçamento. Limites calculados com base em dados históricos podem ser estourados de forma inesperada após a troca de modelo, mesmo que as requisições não tenham mudado.

Estouro da janela de contexto. Um sistema que antes cabia em 128k tokens pode, após a atualização, começar a truncar o contexto ou retornar erro.

Testes A/B injustos. Ao comparar a qualidade de duas versões de um modelo com os mesmos dados, um tokenizador diferente significa que os modelos recebem uma entrada tecnicamente distinta, o que afeta a interpretação dos resultados.

Regressão oculta em pipelines de RAG. Se você empacota chunks por limite de tokens, a troca do tokenizador pode quebrar a lógica de divisão sem um único erro nos logs.

O que isso significa

Desenvolvedores que já usam o Opus em produção ou planejam migrar para o 4.7 devem rodar seus prompts reais pela API do tokenizador das duas versões antes da troca. Isso leva algumas horas, mas permite estimar com honestidade o aumento de custos e ajustar o orçamento ou a arquitetura.

O caso do Opus 4.7 é um bom lembrete: ao atualizar um modelo, verifique não só a qualidade das respostas, mas também a eficiência da tokenização.