Quantos tokens tem meu prompt?

Os modelos de linguagem não leem caracteres nem palavras. Eles leem tokens: fragmentos produzidos ao dividir o texto conforme um vocabulário fixo, aprendido a partir dos dados de treinamento.

Palavras comuns costumam ser um único token. Palavras raras são quebradas em pedaços. Os espaços em branco normalmente ficam anexados ao início do token seguinte, e é por isso que a mesma palavra pode ter contagens diferentes dependendo de estar ou não no começo da frase.

Medida com o tokenizador do GPT-4o, a palavra unbelievable sozinha são três tokens: un + bel + ievable. Escrita como ela de fato aparece numa frase, com o espaço à frente, vira um único token: unbelievable. É a regra do espaço inicial fazendo o serviço — a entrada que o modelo aprendeu é a forma com o espaço à frente, porque é assim que a palavra quase sempre ocorre em texto corrido. the e international se comportam do mesmo jeito, um token cada um com o espaço anexado.

É por isso que as contagens de tokens parecem imprevisíveis. A unidade não é linguística; é estatística. A frequência no corpus de treinamento determina se algo vira um token ou quatro.

Para texto em inglês, medido com o tokenizador do GPT-4o em registros que vão da escrita coloquial à referência técnica:

• 1 token ≈ 4,3–5,9 caracteres
• 1 token ≈ 0,75–0,95 palavras
• 1.000 palavras ≈ 1.050–1.350 tokens
• Uma página padrão (~500 palavras) ≈ 530–680 tokens

O registro pesa mais do que a maioria das regras práticas admite. A escrita informal, de conversa, fica perto do piso dessa faixa, em torno de 1.060 tokens a cada mil palavras, porque reaproveita um vocabulário pequeno de palavras comuns que cabem em um único token cada. O texto técnico denso — incluindo os próprios guias deste site — fica perto do topo, em torno de 1.310, porque os termos especializados são quebrados em pedaços. O número único conhecido, de 1.300 tokens a cada mil palavras, é a ponta técnica da faixa, e não o meio dela, então superestima a escrita comum em uns 20%. E esse é o lado seguro para errar quando você está planejando o orçamento de uma janela de contexto.

Essas regras deixam de valer rapidinho fora do texto comum:

Tipo de conteúdo	Aproximadamente
Texto em inglês	0,75–0,95 palavras por token, dependendo do registro
Código	Cerca de 1,2× os tokens do texto comum por caractere, e aproximadamente 1,5× para a mesma ideia expressa das duas formas
JSON com chaves longas	Muito alto — pontuação e aspas são tokens separados
Chinês, japonês, coreano	Cerca de 0,6–0,7 tokens por caractere — menos de um token cada, mas várias vezes o que o inglês gasta com a mesma quantidade de caracteres
Cirílico, devanágari, árabe	Cerca de 1,4–1,6× o inglês para o mesmo texto
URLs e hashes	Altíssimo — strings aleatórias tokenizam muito mal
Espaços repetidos	Baratos, e não caros — o byte-pair encoding funde sequências longas, então quarenta espaços seguidos são um token só

A diferença entre idiomas é real, mas bem menor do que diz o folclore. Medindo as páginas em inglês deste site contra suas traduções profissionais, a versão em japonês custa cerca de 1,7× a inglesa, a coreana cerca de 1,5×, a chinesa cerca de 1,2×, a hindi cerca de 1,6× e a árabe cerca de 1,4×. Com o tokenizador mais antigo cl100k_base, os mesmos pares davam 2,3×, 2,3×, 1,7×, 4,7× e 2,9× — que é de onde veio o número tão repetido de "duas a três vezes o inglês". Era verdade na época; os vocabulários mais novos praticamente fecharam essa distância.

Cada família de modelos usa seu próprio tokenizador, com seu próprio vocabulário, então o mesmo texto gera contagens diferentes.

Os modelos GPT usam variantes de byte-pair encoding — cl100k_base para os modelos da era GPT-4, o200k_base para os mais novos. O Claude usa um tokenizador diferente, com outro vocabulário. Modelos abertos como Llama e Mistral têm, cada um, o seu próprio.

Os vocabulários divergem mais em código e em textos em outros idiomas, então é aí que as contagens também divergem mais.

Na prática, isso significa:

• Uma contagem feita com um tokenizador é uma estimativa para qualquer outro modelo.
• Só o tokenizador do próprio provedor dá o número exato usado na cobrança.
• Planeje com margem de folga em vez de tentar encaixar exatamente no limite.

Nosso Contador de tokens mostra lado a lado a contagem do GPT-4o e uma estimativa para o Claude. O número do GPT-4o é uma contagem real de tokenizador. O do Claude, deliberadamente, não é: a Anthropic não publica um tokenizador que possamos rodar no seu navegador, então trata-se de uma estimativa baseada em caracteres, de um token a cada 3,5 caracteres. Em texto comum em inglês, essa estimativa fica de 22 a 50% acima da contagem do GPT-4o — cerca de um terço acima na escrita típica —, então leia a diferença como a margem de uma estimativa, e não como uma diferença medida entre as duas famílias de modelos. O par ainda basta para saber se um prompt está confortavelmente dentro do limite ou perigosamente perto dele; quando o número precisa ser exato, use o contador do próprio provedor.

Custo. O preço das APIs é por token, com entrada e saída cobradas separadamente, e a saída costuma custar várias vezes mais. Dobrar o tamanho de um prompt de sistema dobra esse custo em cada chamada — o tipo de coisa que passa despercebida nos testes e fica cara em volume.

Limites de contexto. A janela cobre tudo: prompt de sistema, histórico da conversa, documentos recuperados, a mensagem atual e o espaço reservado para a resposta. Conversas longas falham não porque uma mensagem específica seja longa, mas porque o histórico se acumula.

Truncamento. Quando a entrada excede o limite, algo é descartado — muitas vezes em silêncio, e muitas vezes o conteúdo mais antigo. Um modelo que "esqueceu" suas instruções frequentemente apenas as teve truncadas.

Divisão para recuperação. Dividir documentos para embeddings funciona em tokens, não em caracteres. Partes dimensionadas por contagem de caracteres ficam inconsistentes, e partes cortadas no meio de uma frase são recuperadas com baixa qualidade, então um pipeline de recuperação precisa de um divisor que respeite a estrutura de frases e parágrafos. Nosso Dividir texto em partes não é essa ferramenta: ele corta partes de tamanho fixo de até 2.000 caracteres, quebrando no espaço em branco mais próximo para que nenhuma palavra seja cortada ao meio, o que significa que uma parte pode terminar no meio de uma frase. Use-o para fazer um documento longo caber numa janela de contexto ou num limite de colagem — não para produzir partes de embedding para recuperação.

As reduções de maior impacto, mais ou menos nesta ordem:

1. Enxugue o histórico da conversa. Em chats longos, ele supera todo o resto. Resuma os turnos antigos em vez de reenviá-los na íntegra.
2. Corte instruções redundantes. Repetir uma regra de três jeitos não a torna três vezes mais obedecida. O que ela faz, com certeza, é triplicar o custo dessa regra.
3. Remova artefatos de formatação. Caracteres invisíveis, espaços repetidos e linhas decorativas de separação tokenizam. Individualmente eles saem mais baratos do que se imagina, porque o byte-pair encoding funde sequências longas: quarenta espaços seguidos são um token e uma linha separadora de quarenta hífens são dois, contra treze da frase logo acima. Ainda assim, são puro peso morto e, num documento com um traço entre cada seção, isso se acumula. O Remover caracteres invisíveis limpa os que você não consegue ver.
4. Encurte as chaves do JSON em prompts estruturados. {"n": ...} em vez de {"customer_full_name": ...}, multiplicado por mil registros, faz uma diferença enorme.
5. Envie apenas os trechos relevantes. Recuperar três parágrafos pertinentes é melhor do que colar o documento inteiro, e normalmente gera respostas melhores, além de mais baratas.

O que não ajuda: remover pontuação comum, apagar artigos ou escrever em estilo telegráfico. A economia é marginal e o estrago na qualidade da resposta não é.