ChatGPT still cannot reliably count the three R's in strawberry. Not because it is dumb, but because it never sees the word as letters. As of 2026 this is a GPT-specific failure: GPT-5.2 still reports two R's, while Claude, Gemini, and Grok now count three correctly, partly due to different tokenizers and partly because they spell the word out internally before answering. ChatGPT reads strawberry as numbered chunks called tokens, and those chunk boundaries hide the letters you asked it to count. Feed strawberry to the tokenizer behind ChatGPT (GPT-3.5 and GPT-4) and it does not split into the intuitive straw and berry. It splits into three tokens: str, aw, and berry. The model sees IDs 496, 675, and 15717, not s-t-r-a-w-b-e-r-r-y. Two of the three R's sit inside chunks the model treats as single atomic units, so they are gone before counting can start.
An AI can write a sonnet but stumbles on the R's in strawberry for the same reason it forgets the details of your life: it never sees the letters, only the chunks.
How many R's are in strawberry? Three
Strawberry contains three R's. One in str at the front, two in the rr near the end. Humans count this by scanning ten characters left to right. A language model cannot scan characters it was never given. The input layer of a modern LLM converts text into tokens first, and only the tokens reach the network. The letters are gone from the input before any layer runs.
This is why strawberry became a viral stress test in summer 2024: trivial for a child, hard for a frontier model. The difficulty is not intelligence. It is input format.
What tokenization actually does to strawberry
A popular explanation says strawberry splits into straw plus berry. It does not. You can verify that in seconds with the official tokenizer. The exact split depends on which tokenizer the model uses, and none of the real splits match the myth.
- These are the exact numbers the model sees instead of letters.
- cl100k_base (GPT-3.5 and GPT-4): strawberry becomes str + aw + berry, token IDs 496, 675, 15717.
- o200k_base (GPT-4o family): strawberry becomes st + raw + berry, token IDs 302, 1618, 19772.
- With a leading space, strawberry collapses into a single token in both tokenizers, IDs 73700 and 101830. The whole word is one indivisible chunk, one number.
- Not one of these splits is straw + berry.
Run it yourself: cl100k_base turns strawberry into str + aw + berry, not straw + berry. The most-repeated explanation online is factually wrong.
These chunks are not arbitrary. They come from Byte Pair Encoding, a compression method adapted for language by Sennrich, Haddow, and Birch in 2016. BPE starts from individual characters and repeatedly merges the most frequent adjacent pair into a new symbol. Common sequences like berry and aw get promoted to single tokens because they appear constantly in text. The goal was to handle rare words efficiently in translation, not to preserve spelling. Character identity was never the design target.
A worked example: watch the count slip step by step
Trace what the model actually receives. You type strawberry. The tokenizer hands the network three integers: 496, 675, 15717. The network never sees ten letters. To answer your question it has to recall, from training, that token 496 (str) spells s-t-r and carries one R, that token 675 (aw) carries none, and that token 15717 (berry) spells b-e-r-r-y and carries two. Then it has to add 1 + 0 + 2. Every one of those steps is a memorized association, not a lookup. If the model under-recalls the rr inside berry as a single R, it reports two. That is the exact wrong answer that went viral, and it comes from a single slipped association inside one token, not from broken arithmetic.
Now change one thing. Type the word with spaces: s t r a w b e r r y. The tokenizer can no longer merge the letters, so each character becomes its own token. The R's are now visible as separate units, and the same model that failed a moment ago usually counts three. Nothing about the model changed. Only the input format did. That single contrast is the whole thesis of the strawberry problem in one experiment you can reproduce in any chat window.
The deeper mechanism: the embedding layer under-encodes the letters
Here is the part almost nobody knows: splitting the word is only the first leak. Even inside a single token, the model does not cleanly store its own letters. Each token becomes a vector in the embedding layer, and that vector does not faithfully carry the token's spelling. Hiraoka and Inui showed that the embedding layer does not fully encode character-level information, especially beyond the first character of a token. The model can often recover the first letter of berry, but the embedding alone does not cleanly hold the second R.
So how do models spell at all? They reconstruct character information later. Hiraoka and Inui found that LLMs rebuild spelling knowledge in the intermediate and higher Transformer layers, where a measurable jump in spelling accuracy appears. Spelling is an indirect, learned reconstruction, not a direct read of the input. The embedding alone does not cleanly hold the second R, so the count slips during this imperfect rebuild.
The letters are not lost at the split. They are also under-stored in the embedding, then partially rebuilt deeper in the network. Counting fails at both stages.
Why this breaks counting, math, and string edits too
This is also why AI fumbles simple arithmetic, cannot reliably reverse a string, and breaks on rhymes. Same root cause: the letters and digits are trapped inside tokens. A study of tokenization constraints found that token structure can cause reasoning to fail even with step-by-step prompting, while formats that align tokens to the problem's atomic units restore strong generalization.
This is why the same models that ace abstract reasoning fumble character-level edits like deleting, inserting, or substituting a single letter. Xiong and colleagues traced these failures directly to tokenization and showed that decomposing a word into explicit per-character subtasks, then reconstructing the token, sharply improves accuracy without any retraining. The fix works because it hands the model the characters the tokenizer hid.
- Counting letters in a word like strawberry is hard for AI because the letters sit inside multi-character tokens the model treats as single units.
- Reversing a string: requires per-character access the embedding does not cleanly provide.
- Multi-digit arithmetic: BPE chops numbers into inconsistent chunks, so digit positions blur.
- Rhyme and syllable tasks: depend on sound and spelling structure that tokens compress away.
Why reasoning models like o1 mostly get it right now
By 2025 the strawberry question stopped reliably tripping the newest models, and the reason is instructive. Reasoning models do not see letters any better than GPT-4 did. They route around the gap by spending hidden steps to spell the word out, list the characters, and count them one at a time before answering. OpenAI's o1 family bills this hidden work as reasoning tokens, counted as output tokens you pay for even though you never see them. The model is doing in private the same letter-by-letter trick you can force by hand with spaces.
Xu and Ma studied this directly and reached a pointed conclusion: the counting failure is not as inherent as the tokenization-only story implies. They found that engaging explicit reasoning is the most reliable and efficient way to get accurate answers, more so than finetuning or in-context examples. The token gap is real, but reasoning can paper over it at the cost of time and compute. A correct answer now can cost many times the tokens of the wrong one models gave in 2024.
Reasoning models did not learn to see letters. They learned to spend extra hidden tokens spelling words out, the same workaround you trigger by typing s t r a w b e r r y.
Letters versus tokens: the same word, two different views
| Aspect | How a human reads it | How an LLM receives it |
|---|---|---|
| Unit of input | 10 individual letters: s t r a w b e r r y | 3 tokens: str / aw / berry (cl100k_base) |
| R's visible | All 3, counted by scanning | Hidden inside str and berry chunks |
| Spelling access | Direct, every character is present | Reconstructed in deeper layers, imperfect |
| Counting method | Sequential scan, fully reliable | Statistical recall of a learned fact, error-prone |
| What it optimizes for | Reading and meaning | Compression and frequency, not spelling |
Want a correct count from an AI? Ask it to spell the word out one letter at a time first, or insert spaces (s t r a w b e r r y). That forces per-character tokens and the R count usually comes out right.
What to do about it: four practical fixes
You cannot patch the tokenizer from a chat box, but you can sidestep it. These work today, ordered from least to most involved.
- Insert spaces between letters. Typing s t r a w b e r r y forces single-character tokens and gives the model direct access to each R. The fastest fix, no extra cost.
- Ask for explicit spelling first. Prompt the model to list every letter on its own line, then count. This is the same per-character decomposition Xiong and colleagues showed restores accuracy without retraining.
- Use a reasoning model for character tasks. o1-class models do the letter-by-letter work internally, trading tokens and latency for correctness. Reach for them when the answer must be right, not when speed matters.
- Hand the job to code, not the model. For exact counts, have the AI call a tool or write one line like word.count('r'). Deterministic counting belongs in a function, not in statistical recall.
There is also a research-grade answer: drop tokens entirely. Byte-level and character-level models such as ByT5 read raw bytes instead of merged chunks. Xue and colleagues reported that these token-free models do better on tasks sensitive to spelling and to noise, exactly the family the strawberry problem belongs to. The trade is speed: byte-level sequences are far longer, so the same text costs more compute. That is why production chat models still ship with BPE, and why the strawberry bug is a deliberate engineering trade-off, not an oversight.
The bigger pattern: compression always drops structure
Strawberry is a tiny window into a general rule. Whenever a system compresses information to make it tractable, it trades away fine structure. BPE compresses characters into tokens and loses the individual letters. The same trade governs an LLM's memory of you. Compression buries the specifics, the names, the dates, the one preference you mentioned last week, in weights and a limited context window, the same way the second R falls out of a token. The mechanism differs, but the principle is identical: compression keeps the shape and drops the grain.
AI loses structure whenever it compresses. The R it cannot count and the detail of your life it cannot recall are the same failure wearing two masks.
Where an external memory layer fits
You cannot teach the model to count the R. But you can stop trusting its lossy internal memory with the details that actually matter to you. That is the job of an external memory layer: a store the AI can look up verbatim instead of hoping the facts survive compression.
MemX is built around that idea. It is a personal retrieval layer over your own notes, screenshots, and documents, stored outside the model. When you ask a question, MemX fetches the exact source and grounds the answer in it. The honest framing: tokenization is a model-internal problem, memory loss is a retrieval problem, and MemX addresses the second one. It will not teach a tokenizer to count R's, but it does keep the specific facts you care about from becoming casualties of compression.
Sources
Primary sources for the claims in this article, each linked to the specific finding it supports.
01How many R's are in strawberry, and why does AI get it wrong?
Strawberry has three R's. AI gets it wrong because it reads the word as tokens, not letters. In GPT-3.5 and GPT-4 it splits into str, aw, and berry, so two R's are hidden inside chunks the model treats as single units.
02Does strawberry split into straw and berry inside ChatGPT?
No. That common claim is wrong. The cl100k_base tokenizer splits strawberry into str, aw, and berry. The o200k_base tokenizer used by GPT-4o splits it into st, raw, and berry. You can confirm both with OpenAI's tiktoken.
03Why can reasoning models like o1 count the R's now?
They do not see letters any better. They spend hidden reasoning tokens spelling the word out and counting one letter at a time before answering. OpenAI bills those reasoning tokens as output, so a correct answer costs more time and compute than the old wrong one.
04Can I make ChatGPT count letters correctly?
Often yes. Ask it to spell the word one letter at a time, or type the word with spaces between letters like s t r a w b e r r y. That forces single-character tokens, giving the model direct access to each letter and usually a correct count.
05Why does AI forget details of my life if it can write essays?
Both are forms of lossy compression, by different mechanisms. Writing relies on broad patterns the model kept. Specific facts about you get compressed into weights and limited context and fall out, much like individual letters drop out of a token. The detail is the first thing lost.
