Why an LLM cannot count the letters in “strawberry”

Ask a language model how many times the letter R appears in “strawberry” and there is a decent chance of being told two. The same model will, in the next breath, write a working parser or explain a subtle bug in your code.

This is one of the more revealing failures in machine learning, because the obvious diagnosis — that it is bad at reasoning, or careless — is wrong. The model is not making a mistake about the letters. It is not looking at letters.

Models read tokens, not characters

Before any text reaches a model it goes through a tokeniser, which chops it into pieces from a fixed vocabulary of perhaps a hundred thousand entries. Those pieces are usually not words, and they are almost never individual letters. Common words are single tokens. Rarer ones are split into fragments that appeared often enough in training to be worth an entry.

“strawberry” might arrive as two or three chunks — something like straw and berry. What the model actually receives is not a spelling. It is a couple of integers, each pointing at a vector.

From there, the letters are gone. The model has never seen an S followed by a T followed by an R. Asking it to count Rs is asking it to report on a level of structure that was discarded before it got the input.

That it often gets close is the surprising part, not that it sometimes fails. Correct answers come from having read text about spelling during training — which is knowledge about words, not perception of them.

Why it looks like stupidity

Because the task is trivial for us. We see letters, so we assume the model does, and when something that can discuss Gödel’s incompleteness theorems miscounts letters in a fruit, the natural conclusion is that the intelligence is fake.

The more accurate conclusion is narrower: the interface is different from what you assumed. Ask a person to name the third phoneme in a word they have only ever read and they will also struggle. Not because they are unintelligent — because they encoded it in a form that does not make the answer available.

What else tokenisation explains

Once you have this, several other oddities stop being separate mysteries:

• Reversing a string is unreliable for the same reason. There are no characters to reverse.
• Rhyme and syllable counting are shaky, especially for uncommon words. Rhyming is a claim about sounds, reached through a spelling the model cannot see, guessed from a chunking that ignores both.
• Arithmetic on long numbers goes wrong in a distinctive way. Digits get grouped into tokens, and the grouping does not align with place value, so the model is doing arithmetic on chunks that cut across the columns the algorithm needs.
• Some languages cost several times more than others. Tokenisers are trained on corpora that are heavily English, so English gets efficient single-token words while other scripts get split into many small pieces. The same sentence in Hindi or Thai can consume several times the tokens of its English translation — which means more expense, more of the context window used, and effectively less room to work in. It is one of the less visible ways the technology is unevenly distributed.
• A trailing space can change the output. It may alter which token the next word becomes, and the model is sensitive to that in ways nothing in the interface suggests.

Why it gets fixed, and why that is not the same as solved

Newer models handle “strawberry” more often, and it is worth being clear about where the improvement comes from.

Some is training: the failure became famous, so examples of careful letter counting are now well represented in training data. Some is reasoning — a model that works step by step can spell the word out one letter per step, which converts a perception problem into a manipulation problem it can do. And some is tools: allowed to run code, the model writes a one-line count and reads the answer, which is what a sensible person would do.

None of those give the model characters. They route around the missing level. Which means the class of failure is still there, showing up wherever a task depends on sub-token structure and nobody thought to check.

The useful takeaway

Character-level questions are the model’s blind spot, and the blind spot is architectural rather than a gap in ability.

If you need one answered exactly — counting, spelling, string manipulation, anything positional — have it write code rather than answer directly. Not because the model is unreliable in general, but because you would be asking it about something it was never given.