Ask a chatbot how many r's are in \"strawberry\". It struggles because it has never seen a letter

There is a particular failure that people enjoy pointing at: a model that can walk through a proof, write working code and explain an unfamiliar area of law will confidently tell you that "strawberry" contains two letter r's. It reads as a damning gap — how can something so capable fail at a task a six-year-old can do?

The honest answer is that it is closer to asking someone to count the letters in a word they have only ever heard spoken aloud. The model is not looking at letters. It has never seen one. Understanding why explains a whole family of otherwise puzzling behaviours, and it leads somewhere more consequential than a party trick.

Text is converted before the model ever sees it

A language model does not consume characters. Before anything reaches the network, text is cut into tokens and each token is replaced by a number — an index into a fixed vocabulary of perhaps fifty thousand to a couple of hundred thousand entries.

That vocabulary is not designed by hand. It is built by a procedure, usually byte-pair encoding, run once over a sample of the training data before training begins. Start with individual bytes. Count which adjacent pair occurs most often across the corpus, and merge it into a new single unit. Repeat, tens of thousands of times. Frequent sequences get absorbed into single tokens; infrequent ones never do.

The result is a compression scheme fitted to whatever text it was shown. Common English words end up as one token each. Less common words break into two or three pieces. A rare surname or a technical term may shatter into half a dozen fragments. And crucially, the merges are frozen — the vocabulary is decided before the model learns anything, and everything the model ever experiences arrives through it.

Why that makes letters invisible

If "strawberry" arrives as a small number of opaque tokens, the model has no direct access to the letters inside them. The identity of a token is an index; the model learns what that index behaves like from context, not from its spelling.

Whatever a model knows about spelling it has learned indirectly — from text about spelling, from words being split differently in different contexts, from acronyms and wordplay appearing in its training data. That is real knowledge, and it is why models can often spell perfectly well. But it is inference about a structure it cannot inspect, which is why the reliability collapses on tasks that require actually examining characters: counting a specific letter, reversing a string, judging syllables or rhyme, or working with deliberately misspelled text.

This also explains a difficulty ordering that looks absurd from outside. Integration is well represented in text and composes nicely; counting letters requires access to something the representation discarded. The task that seems simpler to us is the one whose information was thrown away at the door.

Arithmetic has the same root

Numbers suffer a subtler version of the problem. Depending on the tokenizer, a four-digit number might be one token, or split into a two-digit and a two-digit piece, or into three chunks divided in a way that has nothing to do with place value. The same digit can sit inside completely different tokens depending on its neighbours.

Column-wise arithmetic requires digits aligned by position. A model receiving inconsistently chunked numbers must reconstruct that alignment before it can do anything, which is why long multiplication is fragile in a way that has little to do with mathematical ability.

The telling detail is the fix. Several modern tokenizers now force digits to be split individually, precisely so that place value survives into the representation — and arithmetic accuracy improves as a direct result. A problem that looked cognitive turned out to be a formatting decision made before training.

Everything a model can do is bounded by what survived the conversion into tokens. That conversion is designed once, from a corpus, and is invisible at the interface.

The token tax on Indian languages

This is where the subject stops being a curiosity, because the same mechanism produces a measurable inequity that almost nobody discusses.

Byte-pair merges are allocated to whatever appeared frequently in the corpus the tokenizer was fitted on, and those corpora have been overwhelmingly English. So English gets efficient coverage — very roughly four characters per token. Text in Devanagari, Tamil, Bengali or Telugu fragments far more aggressively: the byte sequences of those scripts were rarer, fewer merges were spent on them, and words routinely break into many small pieces, in the worst cases approaching one token per character.

The consequences are concrete rather than philosophical:

Cost. Commercial models are priced per token. The same paragraph of information costs several times more to process in Hindi than in English. An Indian-language product pays a tax on every request, for the same content.

Context. A context window is measured in tokens, so a window that comfortably holds a long English document holds a fraction as much Hindi. The practical working memory of the system is smaller for the same text.

Speed and quality. More tokens means more forward passes to generate the same output, so responses are slower. And because each token carries less meaning, the model has to spread its representation of a word across several positions, which tends to degrade performance on top of the cost.

None of this is a judgement the model is making. It is arithmetic inherited from which text the vocabulary was fitted to. The fix is known and unglamorous — extend or rebuild the vocabulary with substantial Indic data, which measurably reduces token counts and improves downstream quality — and it is the sort of infrastructure work that is far more useful than it is celebrated.

Other things this quietly explains

Glitch tokens. Some strings ended up in the vocabulary because they were frequent in the tokenizer's sample — scraped artefacts, usernames, forum fragments — but were then barely present in actual training. The model has an index for them and almost no learned behaviour, and prompting with these can produce genuinely bizarre output. They are vocabulary entries with nothing behind them.

Formatting sensitivity. A trailing space, an unusual bullet character or an unexpected line break can change how the following text is tokenised, which changes what the model receives. Prompts sometimes behave differently for reasons that are entirely typographic.

Rare names. An unfamiliar name fragments into pieces that individually carry little meaning, which is one reason such names are handled poorly — a different mechanism from the one that mangles them in speech recognition, arriving at a similar result.

What is being done

Three directions. Better multilingual vocabularies, fitted deliberately across many languages rather than fitted to English and extended afterwards. Task-aware choices such as forced digit splitting. And byte-level models that abandon a learned vocabulary entirely and operate closer to raw bytes, removing fragmentation penalties at the cost of processing longer sequences — an active research direction precisely because it would dissolve the whole class of problem rather than patching it.

Why it matters for students and researchers

The general lesson is worth more than the specific one: a representation decision made before training constrains everything the system can subsequently do, and it is invisible from the outside. Nobody using a chatbot can see the vocabulary. It nonetheless determines what the model can count, how much it can hold, and what it costs you.

The practical version for anyone building here: measure tokens per character for your actual language and content before you budget anything. A service priced on the assumption of English token counts will be wrong by a large factor in Hindi, and a context limit that seemed generous in testing will be tight in production. That is an easy measurement to take and an expensive one to skip — and it is the kind of specific, unromantic check that separates a system that works from one that was only ever tested in English.

Frequently asked questions

Why can't AI models count letters in a word?

Because they do not process letters. Text is converted into tokens — chunks of one or more characters — before reaching the model, so a word may arrive as a single unit whose internal spelling the model cannot directly inspect.

What is tokenisation?

It is the conversion of text into a sequence of units from a fixed vocabulary, usually built by repeatedly merging the most frequent adjacent byte pairs in a sample corpus. Common sequences become single tokens and rare ones break into fragments.

Why are AI models bad at long arithmetic?

Partly because numbers are split inconsistently, so digits do not align by place value in the model's input. Several newer tokenizers force digits to be separated individually, which improves arithmetic accuracy noticeably.

Why does using AI in Hindi cost more than in English?

Because tokenizer vocabularies were fitted mainly on English text, so Indic scripts fragment into many more tokens for the same content. Since pricing and context limits are measured in tokens, the same paragraph costs more and consumes more of the available window.

What is a glitch token?

It is a token that exists in the vocabulary because it appeared often in the tokenizer's sample, but which barely occurred in training. The model has an entry for it with almost no learned meaning, and prompts containing it can produce strange results.