Claude Opus 4.7, da Anthropic, gasta mais tokens do que o anunciado

O novo tokenizador do Claude Opus 4.7 pode encarecer de forma perceptível o uso do modelo: em testes reais, o consumo ficou perto de 45–47%, e não nos 0–35% que a Anthropic cita no guia de migração. Para equipes que trabalham com prompts longos, grandes instruções de sistema e prefixos em cache, a diferença não é cosmética. Ela atinge diretamente as cotas, a velocidade e o custo de cada sessão.

A análise surgiu da discrepância entre promessa e prática. A documentação da Anthropic diz que o novo tokenizador usa cerca de 1.0–1.35 vez mais tokens do que o do Opus 4.6. O autor decidiu verificar isso não com exemplos abstratos, mas com materiais parecidos com a carga de trabalho real dos desenvolvedores.

Na primeira medição, ele passou documentação técnica pelo tokenizador e obteve aumento de até 1.47x. Na segunda, pegou um arquivo CLAUDE.md real, ou seja, um grande contexto de instruções, e viu um resultado quase igual: 1.45x. A distância em relação ao limite superior do guia é grande demais para ser tratada como ruído comum de medição.

O problema não é o aumento de tokens em si: às vezes um tokenizador mais pesado realmente traz ganhos de qualidade, estabilidade ou suporte a textos complexos. A questão é que a Anthropic não mudou nem os preços nem as cotas. Se o mesmo texto agora ocupa mais tokens, o usuário bate mais cedo nos limites de contexto, esbarra antes no rate limit e gasta mais orçamento a cada iteração.

Isso dói especialmente em cenários com prompt de sistema longo, conjunto de regras, exemplos de respostas, trechos de documentação e um prefixo em cache enviado repetidamente. No papel, o plano é o mesmo, mas a capacidade útil dele é, na prática, menor.

Por isso o autor foi além da contagem simples e tentou entender o que o modelo recebe em troca. Pela descrição do experimento, foram verificados os benefícios declarados do novo tokenizador e seu comportamento em tarefas práticas. A conclusão central é que não houve compensação milagrosa: pelo menos nos cenários testados, o aumento do consumo foi muito visível, enquanto o ganho não pareceu tão óbvio nem sistemático. Em outras palavras, para quem paga por tokens ou vive dentro de cotas de assinatura, a troca não favorece o usuário. Isso não significa necessariamente que o Opus 4.7 seja um modelo pior, mas significa que a economia dele ficou menos confortável.

É um sinal importante para o mercado. O tokenizador raramente é discutido fora de um círculo restrito de engenheiros, embora determine quanto texto real cabe na janela de contexto e quanto custa cada operação via API. Uma diferença de 5–10% costuma ser tolerável e pode se perder na variabilidade normal das requisições. Mas um salto de cerca de 45% já não é detalhe técnico: afeta a arquitetura de agentes, o tamanho das instruções de sistema, a estratégia de cache e até a economia unitária de um produto. Se a equipe tem um pipeline em que o mesmo prefixo grande participa de centenas de chamadas, os tokens extras passam a consumir dinheiro e capacidade de processamento muito rápido.

A conclusão prática é simples: a migração para o Claude Opus 4.7 deve ser avaliada com os corpora de texto da própria equipe, e não pela formulação de marketing do guia de migração. Vale testar separadamente prompts de sistema, arquivos de instruções, documentação, modelos de tarefas de agentes e tudo o que costuma entrar no contexto. Se as medições mostrarem aumento próximo de 1.45x, a equipe talvez precise enxugar prompts, tirar parte da lógica do contexto, repensar o cache ou até adiar a migração até que o benefício fique mais claro.

A principal lição é que a qualidade de um modelo não pode ser julgada apenas por demos e benchmarks: às vezes o que decide não é a inteligência da resposta, mas o preço de cada token a mais.