Escrever prompt em português gasta mais token que em inglês?

Fala aí, beleza? Toda vez que a fatura da API sobe, alguém no time levanta a mesma suspeita: será que escrever em português tá comendo token à toa?

A dúvida faz sentido, porque o modelo não cobra por palavra, cobra por token, e token não é a mesma coisa em todo idioma

Aqui a gente vai por partes: primeiro COMO o texto vira pedaço, depois os números por idioma e por tokenizador, e no fim um veredito honesto sobre quando trocar de idioma compensa e quando é otimização inútil

Bora?

O que é um token e como o texto vira pedaço

O modelo não lê palavra, e muito menos letra

Ele lê pedaço de texto tirado de um vocabulário FIXO, montado antes do treino. Esse dicionário de pedaços é o tokenizador

Se você conhece compressão de arquivo, a lógica é bem parecida: sequência que aparece muito ganha um código curto, sequência rara é remontada juntando vários códigos

A OpenAI tem uma regra prática pra estimar tokens em inglês: 1 token equivale a mais ou menos 4 caracteres, e 100 tokens dão por volta de 75 palavras

Repara no detalhe: a regra é PRA INGLÊS

E por que isso importa? Porque o vocabulário do tokenizador foi construído olhando um corpus, e o que aparecia bastante lá virou token único

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Uma palavra comum em inglês costuma caber inteira num pedaço só. Uma palavra que aparecia menos naquele corpus é remontada em dois, três, quatro pedaços

O texto tem o mesmo sentido, o mesmo tamanho na tela, e mesmo assim entra no modelo com uma contagem maior

É daí que nasce a diferença entre idiomas: não é o português ser "mais pesado", é o vocabulário ter menos atalhos prontos pra ele 🙂

Português, inglês e os extremos: quanto muda a contagem

O trabalho de Petrov e colegas (NeurIPS 2023) mediu essa diferença idioma a idioma no tokenizador da era GPT-4

Boa notícia pra gente: o português é dos idiomas mais PRÓXIMOS da paridade com o inglês naquele tokenizador. Ainda assim, exige cerca de 50% mais tokens pro mesmo conteúdo

E o outro extremo da escala é de cair o queixo

Duas leituras diferentes moram nessa tabela, e misturar as duas é o erro clássico

A coluna do meio é referência de IDIOMA: quanto o mesmo conteúdo infla ao trocar a língua

A coluna da direita é referência de TOKENIZADOR: em qual modelo aquilo foi medido. O 1,5x do português é da era GPT-4, e não vale como número de hoje pra qualquer modelo que você abrir

Tome cuidado com isso, porque é exatamente aqui que a internet erra a conta

O tokenizador muda a cada modelo (e a conta muda junto)

A contagem de tokens não é propriedade do idioma

É propriedade do MODELO que você chamou

Olha o que aconteceu na virada pro GPT-4o: o tokenizador o200k_base dobrou o vocabulário em relação ao cl100k_base do GPT-4, saindo de 100 mil pra 200 mil tokens

Mais entradas no dicionário significa mais atalho pronto pra texto fora do inglês. O resultado medido foi uma redução de 1,1x a 4,4x na contagem de tokens em 20 idiomas

Ou seja: o mesmo texto, o mesmo idioma, e a conta mudou só porque o modelo mudou

E nem sempre muda a favor

A Anthropic documenta que os modelos Claude 4.7 e posteriores usam um tokenizador mais novo que produz cerca de 30% mais tokens pro mesmo texto, com o aumento exato variando conforme o conteúdo e o tipo de carga

Então o pulo do gato é esse: comparar idioma sem FIXAR o modelo não significa nada

Qualquer número de "português custa X" que não venha grudado num tokenizador específico é achismo

O que a diferença de idioma custa na fatura

Beleza, e em dinheiro?

Vamos usar um valor concreto: o preço de API do Claude Opus 4.7 é de US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de tokens de saída

Repara que a saída custa cinco vezes a entrada. E a saída também sai no idioma que você pediu, então a escolha de língua toca as duas linhas da conta, não só o prompt

Se a sua carga inflar 50% em tokens, a linha correspondente infla 50% junto. Simples assim, a matemática não tem mistério

Agora compara com as alavancas que estão na mesma página de preços: cache de prompt chega a até 90% de economia, e processamento em lote corta 50%

Sacou o tamanho da diferença? 😀

Mexer no idioma ataca uma fração do que entra e uma fração do que sai. Ligar cache num prompt de sistema que se repete a cada chamada ataca quase toda a entrada, e lote corta metade da conta inteira

É a diferença entre catar moeda no sofá e olhar pro aluguel

Como contar os tokens do seu próprio prompt

Chega de teoria, bora medir o SEU caso, que é o único que importa

1. Nos modelos Claude, use o endpoint oficial de contagem. É o POST /v1/messages/count_tokens, exposto nos SDKs como client.messages.count_tokens. O uso é gratuito, sujeito a um limite de requisições por minuto independente do de criação de mensagens

client.messages.count_tokens(
    model="<o MESMO model ID que roda em produção>",
    messages=[{"role": "user", "content": "seu prompt aqui"}],
)

O erro comum deste passo: medir com um model ID diferente do que você usa de verdade na inferência. A contagem é específica de cada modelo, então trocar o ID troca o resultado

2. Nos modelos OpenAI, use o Tokenizer ou o tiktoken. Pra um teste rápido e visual tem a ferramenta Tokenizer, em platform.openai.com/tokenizer. Pra medir dentro do código, tem a biblioteca tiktoken

import tiktoken

enc = tiktoken.encoding_for_model("<modelo alvo>")
print(len(enc.encode("seu prompt aqui")))

O erro comum deste passo: reaproveitar a codificação de outro modelo. Use tiktoken.encoding_for_model(model) pra pegar a codificação do modelo alvo, senão você mede o cl100k enquanto paga o o200k

3. No Claude Code, olhe a janela antes de culpar o idioma. O comando /context mostra uma repartição AO VIVO por categoria do que está ocupando a janela de contexto, com sugestões de otimização e quais arquivos CLAUDE.md e de memória foram carregados. O /cost mostra o gasto acumulado da sessão pra quem usa API key, e /compact (que resume a conversa) ou /clear (que limpa o histórico) liberam espaço

O erro comum deste passo: jurar que o problema é o português quando o /context vai te mostrar que o peso está no histórico da conversa e nos arquivos carregados automaticamente

Quando pensar em idioma faz diferença e quando é otimização inútil

Nem todo cenário responde igual, então vale separar

Volume alto e repetitivo na API, com prompt fixo. Aqui o idioma é praticamente irrelevante perto do resto: você tem um bloco que se repete a cada chamada, e é exatamente o formato que cache de prompt e processamento em lote atacam. Otimizar idioma antes de ligar cache é começar pelo fim

Prompt de sistema longo mandado a cada requisição. Esse é o único caso em que enxugar texto rende de verdade, e olha que o ganho vem mais de CORTAR instrução redundante do que de traduzir. Prompt de sistema costuma ter parágrafo repetido que ninguém releu desde o primeiro dia

Sessão longa de Claude Code com janela apertada. Aqui o problema quase nunca é a língua: é histórico acumulado, arquivo grande lido inteiro, saída de comando gigante colada no contexto. Roda /context, vê onde tá o peso, resolve o peso

Uso conversacional pontual. Papo solto, uma pergunta aqui, um ajuste ali? Esquece a otimização. A economia é ridícula perto do risco de você perder precisão no pedido escrevendo num idioma em que se expressa pior

E esse risco é real, viu. A qualidade do resultado depende muito mais de o pedido estar claro, e a gente já falou disso ao mostrar prompts que aproveitam o Claude Opus em vez de desperdiçar o modelo mais forte

Veredito: vale trocar de idioma para economizar token?

Veredito honesto: a diferença de contagem existe, é medida, mas é a MENOR alavanca de custo que você tem na mão. E ela vem com um preço escondido, que é a chance de perder qualidade no pedido

E não é achismo meu, tem gente que foi medir

Simiao Ren e colegas (arXiv 2604.14210, submetido em 06/04/2026) testaram justamente a crença de que prompts em chinês economizam token em vibe coding, usando o SWE-bench Lite

A vantagem alegada não apareceu

O MiniMax-2.7 teve custo 1,28x MAIOR em tokens com chinês. O GLM-5 foi pro outro lado e consumiu menos tokens com prompts em chinês

E o dado que mais interessa: a taxa de sucesso em chinês foi geralmente menor que em inglês em TODOS os modelos testados

Ou seja, no melhor cenário você economiza um pouco de token e entrega uma tarefa que funciona menos vezes. Belo negócio, né? haha

A literatura que compara prompt em idioma nativo com prompt em inglês também diverge entre estudos e modelos: parte dos trabalhos aponta vantagem do inglês, parte encontra vantagem do idioma nativo dependendo da tarefa e do modelo. Não existe consenso

Então fecha assim: trocar de idioma só compensa quando você escreve igualmente bem nos dois E o texto que infla é grande e repetido, o que na prática é raro. Fora disso, é otimização inútil, porque o ganho é pequeno e o risco de piorar o pedido é grande

Escreva no idioma em que VOCÊ é mais preciso, e vá atacar cache, lote e tamanho de contexto

Se mesmo assim bater a curiosidade sobre um modelo específico, dá pra medir caso a caso, do jeito que a gente olhou pra usar o DeepSeek em português em vez de simplesmente supor

Conclusão

A resposta certa não vem de achar, vem de MEDIR

O português realmente pede mais tokens que o inglês na medição que existe, mas esse número tem endereço: um tokenizador, um modelo, um ano. Trocar o modelo troca a conta, e o Claude 4.7+ com cerca de 30% mais tokens é a prova de que a régua se mexe

Seu próximo passo prático é curto:

• roda a contagem de tokens no model ID que você usa DE VERDADE, não num parecido
• abre uma sessão real de Claude Code e olha /context e /cost pra ver onde o gasto realmente mora
• liga cache de prompt e compara o custo antes e depois

Aposto que a surpresa não vai estar no idioma…

até o próximo post! =)