Skip to content
The Daily Triptych017 / 365
One phrase, five tokens

"The Rosetta Stone" as a tokeniser actually sees it: leading spaces belong to their tokens, a proper noun fractures, and each piece becomes an integer id that carries no meaning of its own.

Try it in the local lab

Watch a real tokeniser split your text

Nothing here needs a GPU. The point is to see fertility differ between languages, and to find a word that fractures.

$ pip install tiktoken
$ python3 -c "import tiktoken; e=tiktoken.get_encoding('cl100k_base'); s='The Rosetta Stone'; t=e.encode(s); print(t); print([e.decode([i]) for i in t])"
$ python3 -c "import tiktoken; e=tiktoken.get_encoding('cl100k_base'); [print(len(e.encode(x)), repr(x)) for x in ['tokenisation','strawberry','Velázquez','ロゼッタストーン']]"
$ ollama run qwen3.5:9b 'How many letter r characters are in the word strawberry? Answer with just the number.'

Compare the token count for the Japanese string against the English one of similar meaning. That ratio is the fertility difference, and it is what makes the same content cost more in some languages than others.

II · THE IDEA · ARTIFICIAL INTELLIGENCE

Tokens: How Language Becomes Something a Model Can Process

Language and tokens · 17 of 100 · Turning text into numbers

▶ Listen · narrated

Ask a model to count the r's in strawberry and it may get it wrong. Not because it cannot count, but because it never saw the letters.

At a glance

What it is
Splitting text into units from a fixed vocabulary, then mapping each to an integer id
Typical vocabulary
Tens of thousands of entries, learned from data rather than designed
Rough guide
In English, one token averages about four characters
Why it exists
A model needs a finite input alphabet; whole words are too many, single characters too few
Where it bites
Spelling, arithmetic, rhyme, and the cost of non-English text

Think of a set of fridge magnets. Not one magnet per letter, and not one per word — a mixed set, where the words you use constantly get their own magnet, and rarer words have to be spelled out from smaller pieces you snap together. "The" is a single magnet. "Tokenisation" might take two or three.

Before a model reads your sentence, it rebuilds it out of these magnets. Then it swaps each magnet for its number in the box — magnet 4383, magnet 991 — because numbers are the only thing the model can actually work with.

That is the whole idea. Two things follow from it, and both are worth carrying around.

The first is that the model does not see letters. It sees the magnets. Asking it how many r's are in "strawberry" is like asking someone to count the letters in a word when they are only allowed to look at two or three tiles that spell it. Often they will know the answer from memory. Sometimes they will not.

The second is that the magnet set was not designed — it was assembled by looking at an enormous amount of text and keeping whichever fragments came up most. So it fits the languages that dominated that text, and fits others badly. Writing in a language the set was not built for means using far more magnets to say the same thing.

Look closer

  1. The split is not on word boundaries

    Common words usually survive intact — "the", "and", "model" are each one token. Rarer words fracture. "Tokenisation" might arrive as "token" + "isation", and an unusual surname may come apart into three or four fragments that mean nothing individually. The leading space is normally part of the token too: " model" and "model" are different entries in the vocabulary, which is why a stray space can change a model's behaviour more than it seems it should.

  2. Every token is just an integer

    After splitting, each piece is replaced by its index in the vocabulary. That number carries no meaning at all — token 4383 is not more or less than token 4384 in any sense the model can use. Meaning only appears at the next step, when each id is used to look up a learned vector. The id is a name, not a measurement. This is worth holding on to, because it is the reason the embedding lesson matters.

  3. The vocabulary was learned, not written

    Nobody sat down and decided that "isation" deserved its own entry. The vocabulary is produced by running a merge algorithm over a large corpus and keeping whichever fragments turn out to be frequent. That means it encodes the statistics of the training data — including which languages were well represented. A tokeniser built mostly on English will handle English efficiently and spend far more tokens on the same content in Thai or Telugu.

The story

Everything a language model does begins with an act of chopping.

The model is a mathematical function. It consumes numbers and produces numbers. It has no notion of a letter, a word, or a sentence, and no mechanism for acquiring one. So the very first thing any system does with your text is convert it into a sequence of integers — and the scheme for doing that conversion is the tokeniser.

The obvious approaches both fail. Give every word its own number and the vocabulary becomes unbounded: new words appear constantly, proper nouns are endless, and any word the model never saw during training has no id at all. Go the other way and treat each character as a token and the vocabulary becomes trivially small, but now the model must learn that the twelve characters t-o-k-e-n-i-s-a-t-i-o-n form a meaningful unit, and every sequence becomes very long — which matters enormously, because attention cost grows with the square of sequence length.

Subword tokenisation is the compromise, and it is the one everything modern uses. Frequent strings get their own entry; infrequent ones are assembled from smaller pieces. Common words stay whole, rare words break into fragments, and nothing is ever out-of-vocabulary because the fragments bottom out at individual bytes.

The method that made this standard was introduced by Sennrich, Haddow and Birch in 2016, adapting a 1990s data-compression algorithm called byte pair encoding. Start with characters, count adjacent pairs across the corpus, merge the most frequent pair into a new symbol, and repeat until the vocabulary reaches the size you want. It is almost embarrassingly simple, and it works. Kudo and Richardson's SentencePiece later packaged the idea so it could run directly on raw text without language-specific pre-processing — significant for languages that do not put spaces between words.

The consequences are not confined to preprocessing. They surface as behaviour.

Counting letters is the famous one. If "strawberry" reaches the model as two or three tokens, the individual r's are not separate objects it can enumerate — they are interior details of chunks it has only ever seen whole. It can often answer correctly anyway, because it has read text about spelling, but it is reasoning about the word rather than inspecting it.

Arithmetic degrades for related reasons. Whether a number splits as "1", "234" or "12", "34" depends on what the merge algorithm happened to find frequent, and the split is not consistent across magnitudes. Digits that should be positionally equivalent land in different chunks.

Rhyme and wordplay suffer because the model sees the end of a word only if the tokenisation exposes it.

And cost is unevenly distributed. The same paragraph in English and in a language poorly represented in the tokeniser's training data can differ by a factor of two or more in token count — which means it consumes more of the context window, takes longer to generate, and costs more per request. That is a fairness problem baked in before the model does any thinking at all.

None of this is a bug in a particular model. It is a structural consequence of the fact that text has to become integers somehow, and every scheme for doing so makes some things easy to see and other things invisible.

Why it mattered then

Before subword methods, machine translation systems had a hard vocabulary ceiling and a persistent unknown-word problem. Rare words — names, technical terms, morphologically rich forms — were replaced with a generic placeholder, and the output was correspondingly poor. The 2016 subword paper was written specifically to fix rare-word translation, and it did: it removed the open-vocabulary problem entirely, because any string can be built from smaller pieces. That unlocked training on genuinely open text corpora, which is a precondition for everything that came after.

Why it matters now

Tokenisation is the layer people skip, and then spend a week debugging. Context limits are counted in tokens, not characters. Pricing is per token. Throughput is per token. When a local model produces subtly degraded output, a mismatched tokeniser or chat template is a common cause. And it sets a hard ceiling on certain tasks: if you need reliable character-level manipulation, the right move is usually to do it in code rather than asking the model, because the model is working with the wrong primitives for the job.

The surprising detail

The tokeniser is trained separately from the model, and once chosen it is effectively frozen. Changing it invalidates every learned embedding, because the ids no longer point at the same things — so a decision made early, on a particular corpus, propagates through the entire lifetime of the model. There is also a well-documented failure mode involving tokens that appear in the tokeniser's vocabulary but almost never in the training text. Their embeddings stay close to their random initialisation, and prompting a model with them can produce strikingly erratic output. They are sometimes called glitch tokens, and they are an artefact of the tokeniser and the training corpus being built from different data.

What is disputed

The rule of thumb that one token is about four English characters is an average across ordinary prose, not a property of the system. Code, numbers, non-Latin scripts and unusual names all diverge from it substantially, and the exact ratio differs between tokenisers. Treat it as a rough budgeting aid, never as a measurement.

Remember this

Tokens are the model's alphabet, and it is not ours. Anything that depends on letters — spelling, counting, rhyme — is being done through a layer that hid them.

Test yourself

You give a model a document in English and the same document translated into a language that was thinly represented in the tokeniser's training corpus. The second one uses far more tokens. Name two distinct practical consequences, beyond simply costing more.

Go deeper

Image: Original diagram, The Daily Triptych. Licence: Original work. Source.

← Back to day 17