Ask a state-of-the-art language model a question a six-year-old can answer — how many R's are in "strawberry"? — and there's a decent chance it says two.
The answer is three. The model has read more text than any human who has ever lived. It can write working code, explain quantum mechanics, and pass the bar exam. But it trips over counting letters in a common word.
This isn't a one-off glitch, and it isn't a sign the model is "dumb." It's a direct, predictable consequence of how language models read text in the first place. Once you understand tokenization, the strawberry problem stops being funny-mysterious and becomes obvious — and you'll understand a whole category of weird LLM behavior along with it.
Here's the thing almost nobody tells you when they explain LLMs: a language model never sees the letters in a word.
Before a single layer of the neural network runs, your text gets chopped into chunks called tokens. A token might be a whole word, a piece of a word, a single character, or even just a space. The model only ever sees the token IDs — numbers pointing into a fixed vocabulary — and it reasons about those.
So when you type strawberry, the model doesn't receive s-t-r-a-w-b-e-r-r-y. It receives something more like:
["str", "aw", "berry"]
Three tokens. The letters inside each chunk are, from the model's point of view, welded together into a single indivisible unit. Asking it to count the R's is like asking you to count the number of times the letter "e" appears in a word written in a language whose alphabet you can't read. You'd be guessing from memory, not looking.
That's exactly what the model does — it guesses from statistical memory of how many R's tend to be in "strawberry," rather than inspecting the letters, because it has no letters to inspect.
See it yourself: we built an interactive tokenizer where you can type any word and watch it split into tokens in real time. Type "strawberry" and see the chunks — then watch the letters disappear into them. Try the Tokenization lab →
The obvious question: why chop words into weird pieces like str + aw + berry at all? Why not just split on whole words, or go all the way down to single letters?
Both extremes fail:
The compromise that won is called Byte-Pair Encoding (BPE), and the idea is elegantly simple. Start with raw characters. Then repeatedly find the most common adjacent pair of symbols in your training text and merge them into a single new token. Do that tens of thousands of times.
Common sequences like th, ing, the, and berry get merged early, because they appear constantly — so they end up as single tokens. Rare sequences never get merged, so unusual words stay fragmented into small pieces. The algorithm learns the vocabulary purely from frequency. No grammar, no dictionary, no rules about what a "word" is.
Watch BPE build a token: the same lab has a step-through mode — start from single characters and apply the merge rules one at a time, watching "l" + "o" become "lo", then "low". It's the whole algorithm in about ten clicks. Open the lab →
Once you see that models operate on tokens, not characters, a bunch of other "weird AI moments" line up and make sense:
Why it's bad at spelling and letter games. Reversing a word, counting specific letters, solving a word where letters are rearranged — all of these require seeing individual characters. The model sees chunks. It's working blind.
Why some languages cost more than others. English text averages roughly four characters per token because English dominated the training data, so common English sequences got their own tokens. Many other languages — and anything in a non-Latin script — fragment into far more tokens for the same meaning. Since API pricing and context limits are measured in tokens, the exact same sentence can cost several times more in one language than another. That's not a surcharge someone decided on; it falls directly out of how the vocabulary was built.
Why a leading space changes things. In most tokenizers, a space is part of the token that follows it. So "cat" at the start of a sentence and " cat" in the middle can be different tokens with different IDs. This quietly trips up prompt engineering: the same word can behave differently depending on what's next to it.
Why numbers get mangled. Long numbers often fragment into odd pieces ("1234567" might become "123" + "456" + "7"), which is part of why LLMs are shaky at arithmetic on large numbers — the digits aren't even grouped the way we'd group them.
Try the cost angle: type a sentence in the lab and watch the "characters per token" ratio. Then try a rare or technical word and watch it fragment. That ratio is, quite literally, what you're billed on. Explore it →
Partly, and in interesting ways. Some newer approaches push toward byte-level or character-aware models that don't have this blind spot. And models increasingly paper over it with tools — if an LLM can call a Python function to count letters, it'll get "strawberry" right because the code sees the characters even though the model doesn't.
But the deeper point is worth holding onto: the strawberry failure isn't a flaw in the model's intelligence. It's a window into the fact that a language model's "reality" is made of tokens, not letters — and a surprising amount of LLM behavior, from pricing to prompting quirks, follows from that single design choice.
The next time a model fumbles something that looks trivially easy, ask yourself: is this a task that needs to see individual characters? If it is, you've probably found another face of the same problem.
Want to actually see tokenization happen instead of just reading about it? The interactive Tokenization lab on BiteLrn lets you type any text and watch it split into tokens, step through the byte-pair-encoding algorithm one merge at a time, and see why "strawberry" shatters into pieces. It's free and needs no sign-up.
For the broader picture of how text becomes something a model can process, see the Tokenization topic in our open library.