What a "token" actually is, and why it decides your bill
Every price tag, every context-window limit, every "this prompt is too long" error traces back to one invisible step that runs before the model ever sees your text: tokenization. Here's what's actually happening in that step, and why the exact same sentence can cost different amounts — and count as a different number of tokens — depending on which model reads it.
A language model doesn't read letters or words. It reads a sequence of integers. Before any text reaches the model, a component called the tokenizer chops that text into fragments — words, pieces of words, punctuation, sometimes single characters — and looks each fragment up in a fixed vocabulary, usually somewhere between 32,000 and 100,000+ entries. Each fragment becomes one token: an integer id the model actually operates on.
A token can be a whole common word like the, a fragment of a rarer word like token + ization, or even a single byte when the text doesn't match anything in the vocabulary — which is how tokenizers handle emoji, rare scripts, or malformed text without crashing.
Rule of thumb
For plain English, a common estimate is roughly 4 characters, or about 0.75 words, per token. It's only an approximation — the real count depends on the specific tokenizer, and it gets noticeably worse for code, non-Latin scripts, or specialized jargon, where the same idea can take 2-3x more tokens than in English.
2. Why not just split by word?
Splitting by whole words sounds obvious, but it breaks in practice for two reasons. First, a whole-word vocabulary has to cover every word that might ever appear — every name, typo, technical term, and word in every language — which makes it enormous and still incomplete; any word missing from the list becomes an "unknown" the model can't represent at all.
Second, splitting by individual characters solves the coverage problem (any text can be spelled out one character at a time) but creates a different one: sequences get very long, since a 10-letter word becomes 10 tokens instead of one, and the model has to work much harder to reconstruct meaning from that many tiny pieces.
Subword tokenization is the compromise that every major model — GPT, Gemini, Claude, Llama — has converged on: pieces that are smaller than a word but larger than a single character, striking a balance between vocabulary size and sequence length.
3. Byte Pair Encoding: how the vocabulary gets built
The most common algorithm behind subword tokenization is Byte Pair Encoding (BPE) — originally a 1994 data-compression trick, adapted for language models around 2016. The idea is simple to state:
Start with every individual character (or byte) as its own token.
Scan a large training corpus and find the most frequent adjacent pair of tokens — for example, t and h appearing together as th very often.
Merge that pair into a single new token, added to the vocabulary.
Repeat — now looking for the next most frequent pair, which might combine two already-merged pieces — until the vocabulary reaches a target size (commonly 32,000 to 100,000 tokens).
The result is a vocabulary shaped by real frequency in the training data: extremely common words end up as single tokens, moderately common ones become two or three pieces, and rare words get chopped into many small fragments. SentencePiece and tiktoken are two widely used implementations of this same family of idea, each with its own trained vocabulary — which is exactly why different models don't agree on token counts for the same text.
4. Why this quietly controls cost, context, and quality
Tokens aren't a backstage implementation detail — they're the literal unit everything gets measured and billed in:
Price. API pricing is quoted per token (usually per million), for both input and output. The same sentence in two languages, or the same idea in prose vs. code, can cost meaningfully different amounts purely because it tokenizes into a different number of pieces.
Context window. A "1M token context window" is a hard cap measured in tokens, not characters or words — so a densely-tokenized language or format eats into that budget faster than English prose does.
Latency. Models generate output one token at a time; more tokens to produce means more time waiting, independent of how "hard" the underlying reasoning actually was.
Quality on edge cases. A vocabulary trained mostly on English will tokenize other languages, code, or unusual formatting less efficiently — sometimes falling back to byte-level tokens — which can measurably hurt a model's fluency and accuracy in exactly those cases.
Concretely: a vocabulary with 100,000 entries can represent more per token than one with 32,000 entries, so the exact same prompt can produce noticeably different token counts — and therefore different costs — across two models with different tokenizers, even before either model writes a single word back.
5. Where tokenization trips people up
A few consequences catch people off guard the first time they notice them:
Character-counting tasks are unreliable. Since the model reasons over tokens, not letters, asking it to count letters in a word or reverse a string is asking it to do something its internal representation doesn't naturally expose — this is a real known weak spot, not a random quirk.
Whitespace and casing matter. Many tokenizers treat " hello" (with a leading space) and "hello" as different tokens entirely, which is why prompt formatting — extra spaces, line breaks — can shift token counts more than people expect.
Code tokenizes unevenly. Programming languages have their own rhythm of symbols and indentation that doesn't match natural-language frequency patterns, which is part of why token counts for code can look surprisingly high relative to its visual length.
6. What to actually do with this
None of this requires becoming a tokenizer expert, but it's worth internalizing three practical habits: check a model's actual token count on a sample of your real content before assuming a rough word-count estimate holds, budget extra headroom for non-English text or code inside a fixed context window, and don't lean on a model to do exact character-level manipulation — that's a job for actual code, not a prompt.
Share:
Newsletter
Learn what AI is creating for you. Don't get lost.
Get notified when a new deep dive or lesson goes up. No spam, just new posts.
O que é um "token", de fato — e por que ele decide sua conta
Todo preço, todo limite de janela de contexto, todo erro de "esse prompt está longo demais" volta pra um passo invisível que roda antes do modelo sequer ver seu texto: a tokenização. Aqui está o que acontece de verdade nesse passo, e por que a mesma frase pode custar valores diferentes — e virar uma quantidade diferente de tokens — dependendo de qual modelo a lê.
Um modelo de linguagem não lê letras nem palavras. Ele lê uma sequência de números inteiros. Antes de qualquer texto chegar ao modelo, um componente chamado tokenizador corta esse texto em fragmentos — palavras, pedaços de palavras, pontuação, às vezes caracteres isolados — e busca cada fragmento num vocabulário fixo, geralmente entre 32 mil e mais de 100 mil entradas. Cada fragmento se torna um token: um número inteiro que o modelo de fato manipula.
Um token pode ser uma palavra comum inteira como o, um fragmento de uma palavra mais rara como token + ização, ou até um byte isolado quando o texto não bate com nada do vocabulário — é assim que os tokenizadores lidam com emoji, alfabetos raros ou texto malformado sem quebrar.
Regra de bolso
Para inglês comum, uma estimativa usual é de aproximadamente 4 caracteres, ou cerca de 0,75 palavra, por token. É só uma aproximação — a contagem real depende do tokenizador específico, e piora bastante para código, alfabetos não-latinos ou jargão especializado, onde a mesma ideia pode consumir de 2 a 3x mais tokens do que em inglês.
2. Por que não simplesmente separar por palavra?
Separar por palavra inteira parece óbvio, mas quebra na prática por dois motivos. Primeiro, um vocabulário de palavras inteiras precisa cobrir toda palavra que possa aparecer — todo nome, erro de digitação, termo técnico e palavra de todo idioma — o que o torna enorme e ainda incompleto; qualquer palavra fora da lista se torna um "desconhecido" que o modelo simplesmente não consegue representar.
Segundo, separar por caractere individual resolve o problema de cobertura (qualquer texto pode ser escrito letra por letra) mas cria outro: as sequências ficam muito longas, já que uma palavra de 10 letras se torna 10 tokens em vez de um, e o modelo precisa trabalhar muito mais pra reconstruir sentido a partir de tantos pedaços minúsculos.
A tokenização de subpalavras é o meio-termo pro qual todo modelo relevante — GPT, Gemini, Claude, Llama — convergiu: pedaços menores que uma palavra e maiores que um caractere único, equilibrando tamanho de vocabulário e tamanho de sequência.
3. Byte Pair Encoding: como o vocabulário é construído
O algoritmo mais comum por trás da tokenização de subpalavras é o Byte Pair Encoding (BPE) — originalmente uma técnica de compressão de dados de 1994, adaptada para modelos de linguagem por volta de 2016. A ideia é simples de descrever:
Começar com cada caractere (ou byte) individual como seu próprio token.
Escanear um grande corpus de treinamento e achar o par adjacente mais frequente de tokens — por exemplo, t e h aparecendo juntos como th com muita frequência.
Fundir esse par em um único token novo, adicionado ao vocabulário.
Repetir — agora buscando o próximo par mais frequente, que pode combinar dois pedaços já fundidos — até o vocabulário atingir um tamanho-alvo (normalmente entre 32 mil e 100 mil tokens).
O resultado é um vocabulário moldado pela frequência real nos dados de treino: palavras extremamente comuns terminam como um único token, palavras moderadamente comuns viram dois ou três pedaços, e palavras raras são cortadas em muitos fragmentos pequenos. SentencePiece e tiktoken são duas implementações amplamente usadas dessa mesma família de ideia, cada uma com seu próprio vocabulário treinado — e é exatamente por isso que modelos diferentes não concordam na contagem de tokens do mesmo texto.
4. Por que isso controla, silenciosamente, custo, contexto e qualidade
Tokens não são um detalhe de implementação nos bastidores — são literalmente a unidade em que tudo é medido e cobrado:
Preço. O preço de API é cotado por token (geralmente por milhão), tanto para entrada quanto para saída. A mesma frase em dois idiomas, ou a mesma ideia em prosa vs. código, pode custar valores bem diferentes só porque tokeniza em uma quantidade diferente de pedaços.
Janela de contexto. Uma "janela de contexto de 1M de tokens" é um limite rígido medido em tokens, não em caracteres ou palavras — então um idioma ou formato que tokeniza de forma densa consome esse orçamento mais rápido do que prosa em inglês.
Latência. Modelos geram saída um token por vez; mais tokens pra produzir significa mais tempo de espera, independente de quão "difícil" o raciocínio subjacente de fato foi.
Qualidade em casos de borda. Um vocabulário treinado majoritariamente em inglês vai tokenizar outros idiomas, código ou formatação inusual de forma menos eficiente — às vezes recorrendo a tokens no nível de byte — o que pode prejudicar de forma mensurável a fluência e precisão do modelo exatamente nesses casos.
Na prática: um vocabulário com 100 mil entradas consegue representar mais por token do que um com 32 mil entradas, então o mesmo prompt exato pode gerar contagens de tokens visivelmente diferentes — e portanto custos diferentes — entre dois modelos com tokenizadores diferentes, mesmo antes de qualquer um dos dois escrever uma única palavra de resposta.
5. Onde a tokenização pega as pessoas de surpresa
Algumas consequências pegam as pessoas desprevenidas na primeira vez que percebem:
Tarefas de contar caracteres são pouco confiáveis. Como o modelo raciocina sobre tokens, não sobre letras, pedir pra ele contar letras numa palavra ou inverter uma string é pedir algo que sua representação interna não expõe naturalmente — é um ponto fraco real e conhecido, não uma peculiaridade aleatória.
Espaço e capitalização importam. Muitos tokenizadores tratam " olá" (com espaço antes) e "olá" como tokens completamente diferentes, e é por isso que a formatação do prompt — espaços extras, quebras de linha — pode mudar a contagem de tokens mais do que se espera.
Código tokeniza de forma desigual. Linguagens de programação têm seu próprio ritmo de símbolos e indentação que não corresponde aos padrões de frequência da linguagem natural, o que explica em parte por que a contagem de tokens de código pode parecer surpreendentemente alta em relação ao seu tamanho visual.
6. O que fazer com isso na prática
Nada disso exige virar especialista em tokenizador, mas vale internalizar três hábitos práticos: checar a contagem real de tokens de um modelo numa amostra do seu conteúdo real antes de assumir que uma estimativa aproximada por palavra vale, reservar margem extra pra texto em outros idiomas ou código dentro de uma janela de contexto fixa, e não depender do modelo pra manipulação exata no nível de caractere — isso é tarefa pra código de verdade, não pra prompt.
Compartilhar:
Newsletter
Saiba o que a IA está criando pra você. Não fique por fora.
Seja avisado quando eu postar uma imersão ou lição nova. Sem spam, só posts novos.