Why the model can't count the letters in a word

You asked how many r's are in "strawberry" and it said two. You asked for exactly 100 words and got 137. You asked for a limerick and the last line did not rhyme, it only looked like it should. Each reads as carelessness — a model that could do better if it paid attention.

None of them is carelessness. They are one fact wearing different costumes, and the fact is that the model never saw the word. By the time anything you would call thinking happens, "strawberry" is no longer ten letters. It is a handful of numbers, and the boundaries between them were set by a procedure that has never heard of spelling.

Every vendor documents tokens, because tokens are the unit they bill in. None connects that unit to the failures it causes. This page is the connection.

The model never receives your letters

The conversion happens before the model, and it is not a step you can opt out of. Anthropic's glossary is blunt about what the model's world is made of: "Tokens are the smallest individual units of a language model, and can correspond to words, subwords, characters, or even bytes (in the case of Unicode)."

Read smallest literally. Below the token there is nothing to inspect. Google names the two halves of the same machinery: "Long words are broken up into several tokens. The set of all tokens used by the model is called the vocabulary, and the process of splitting text into tokens is called tokenization."

So counting the r's in a word asks for detail thrown away at the door. The model can answer, because it has read a great deal about spelling and can produce something plausible. It cannot look. Only one of those is reliable.

The split was learned from frequency, not from spelling

The vocabulary is not a dictionary somebody wrote. It was built by scanning an enormous pile of text and keeping whatever sequences turned up often. OpenAI's description gives the mechanism and an example in one breath: "Tokens represent commonly occurring sequences of characters. For example, the string " tokenization" is decomposed as " token" and "ization", while a short and common word like " the" is represented as a single token."

That is the whole thing. Common strings survive intact; uncommon ones shatter into whatever common fragments they contain. Where the cuts fall correlates loosely with morphemes, because frequent sequences often are prefixes and suffixes, but that is a side effect. Nothing in the procedure knows what a syllable is, or that "berry" sits inside "strawberry".

The rules of thumb fall out of this. A token averages around four English characters, and roughly 100 tokens carries 60–80 English words — so "how many words is 1,000 tokens" answers to about 600 to 800, never exactly. (Checked 23 August 2026 — treat any such figure as an average that moves with the model and the text.) An average is the wrong instrument for every question on this page, because they are all about single characters.

The same word is not always the same tokens

Two things change the split without changing the meaning, and both surprise people.

The first is whitespace. OpenAI notes that in running text the first token of a word typically starts with a space, which is why the example above quotes " tokenization" with a leading space. A word at the start of a line and the same word mid-sentence are not the same input. The second is casing: an unusual capitalisation is an unusual string, and unusual strings shatter.

The third is language. Anthropic's glossary puts the caveat beside the number — a token is roughly 3.5 English characters, though the exact count varies with the language. A sentence in a script that is thin in the training corpus can cost several times its English translation, for the same meaning. That is a bill as well as an accuracy problem, and the bill is a separate mechanism.

The tokenizer is itself a choice the vendor revisits. Anthropic warns that "Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer. The same input text produces approximately 30 percent more tokens than on earlier models." (Checked 23 August 2026 — a vendor figure, and the sort that moves at the next model release.) Nothing about your prompt changed. The ruler did.

Counting letters, and reversing strings

Fingerprint: a confident, specific, wrong number with no hedging. Ask again and you get the same wrong number or a different one, and neither reads as uncertainty.

The tell that proves the mechanism is the fix people stumble on by accident: space the word out — s t r a w b e r r y — and the answer often comes right. You did not make the model smarter. You forced a different split, one where each letter stands alone as its own token, and the thing being counted became something the model can see.

Reversal is the same failure. Reversing a string means addressing characters by position, and positions below the token do not exist. The fingerprint is distinctive: the first few characters come out right and the middle degrades, because the model is reconstructing a plausible reversal rather than performing one. Anagrams, substitution ciphers, acrostics and "remove every vowel" break the same way.

"Write exactly 100 words", and the 280-character tweet

Fingerprint: close but never exact, and the miss grows with the target. Ask for 50 words and you get 44 or 61. Ask for 1,000 and you can be out by a hundred. Ask the model to check its own count and it reports, confidently, the wrong number.

Nothing in the generation loop counts words. The model emits tokens, and a token is neither a word nor a character. It has a learned sense of how long "about a paragraph" feels, which is why answers land in the right neighbourhood and never on the mark.

Character limits are worse. "Fit this in 280 characters" is expressed in a unit the model has no access to at all, so the result is a guess usually a little over — the direction that breaks a publish button. Notice which way the tooling runs: vendors ship endpoints that count the tokens in what you send, and nothing that counts the words in what comes back.

Rhyme, syllables, and anything that has to be heard

Fingerprint: eye-rhymes and near-rhymes. "Though" paired with "through". A haiku with eleven syllables in the middle line. A word that "rhymes with orange", asserted rather than admitted.

Rhyme is a property of sound, and the model has neither sound nor the letters that would let it infer sound. It has a vast memory of which words appeared as rhyme pairs in poems — beautiful on common pairs, collapsing on anything the corpus did not already rhyme for it. Syllable counting fails harder, because syllable boundaries and token boundaries are unrelated ways of cutting a word.

Alliteration holds up better, and instructively so: the first token of a word usually starts with the word's first letter, so a first-letter constraint is nearly visible where an internal one is not.

Rare words, other alphabets and long numbers

Fingerprint: a name that comes back subtly misspelled. A product code with one character changed. A sixteen-digit number with a digit dropped or duplicated. A non-Latin script mangled in a way ordinary English never is.

The same split at its worst. Common strings are single tokens and survive transcription intact; a rare surname, an SKU, a hash or an unusual script becomes a long run of small fragments, and every fragment is another chance to reassemble it wrong. Anthropic's glossary names the trade-off: large tokens are used where possible for efficiency, and small ones exist so the model can cope with uncommon or never-before-seen words. Coping is not copying.

Long numbers add a twist — digits are grouped into tokens in ways that have nothing to do with place value. The model is not reading a number. It is reading chunks made of digits.

The test: does this task need the model to see characters?

The rule is one question.

If changing a single character would change the correct answer without changing the meaning, the task is below the model's resolution.

Letter counts, character counts, reversals, rhymes, syllables, exact word counts, checksums, acronyms built from initials, "does this fit in 280 characters" — all fail it. Summarising, classifying, translating, rewriting and reasoning all pass, because the answer depends on meaning, and meaning is what tokens preserve.

Notice what the test does not ask. It does not ask whether the task is hard. Counting letters is the easiest thing on this page and the one the model cannot do; drafting an argument is the hardest and the one it does well.

Ask for the program, not the answer

Once you know the resolution is the problem, the fix writes itself: hand character-level work to something built out of characters.

"How many r's in strawberry" is the wrong request. "Write and run a line of Python that counts them" is the right one, and both major vendors ship the sandbox that makes it real. OpenAI's: "The Code Interpreter tool allows models to write and run Python code in a sandboxed environment to solve complex problems in domains like data analysis, coding, and math." Anthropic's equivalent covers the same ground — Claude "can analyze data, create visualizations, perform complex calculations, run system commands, create and edit files, and process uploaded files directly within the API conversation."

Python sees characters, so the model need not. You also get more than an answer: a program you can read, re-run and point at the next input.

One catch belongs to a different mechanism. Having the tool available is not the same as the model choosing to use it, and a model that answers from memory while a sandbox sits idle is a decision problem, not a tokenization one. Say "run code to check" rather than hoping.

Give the constraint to something that can enforce it

Where you cannot run code, move the constraint out of the prose.

If a length matters, count it yourself afterwards and trim or reject. If a shape matters, put it in a schema rather than a sentence — that is what structured output is for, and OpenAI lists the benefit exactly this way: "Simpler prompting: No need for strongly worded prompts to achieve consistent formatting." A schema is checked by software. A sentence in your prompt is a request.

If you are budgeting rather than formatting, use the counters vendors ship: token counting "lets you determine how many input tokens a request will use before you send it to the model" — a measurement rather than an estimate you did in your head.

And where approximate length will do, ask for structure instead of a number. "Three short paragraphs, one per point" is a constraint the model can hold, because paragraphs are things it emits as it goes. "Exactly 100 words" it can only estimate. Swap the unit and the instruction starts working.

The honest limit: it can spell now, and nothing was fixed

Try the strawberry question today and it will very likely be right. That is real, and it is not what it looks like.

Two things changed, neither the tokenizer. Character-level exercises became common in training data, so the famous cases are memorised like any other fact. And reasoning models spend their scratch work writing the word out one letter per line first — the spacing trick, performed internally. That works, and whether a task has a middle worth reasoning over decides whether it happens at all.

Both train around a symptom; the perception limit is architecture. So the failure returns where memorisation does not reach: a made-up word, a rare surname, a script the model has seen little of, a count long enough that writing it out is itself error-prone. Test with a nonsense string you invented, never with "strawberry" — the famous example is the one that has been trained on.

One more caution. A single success is a single sample, and the same prompt does not give the same answer. Run it three times before trusting it.

The decision list

For any task, in this order:

1. Ask the resolution question. Would changing one character change the right answer while leaving the meaning alone? If yes, the model cannot see what you are asking about.
2. Never accept a count you did not verify. Letters, characters, syllables, items in a list you asked to be exactly twelve long. This class of answer is confident by default, and confidence is not evidence.
3. Ask for the program rather than the result, then run it. A five-line script beats a number, because you can check it and reuse it.
4. Say "run code to check" out loud. Availability is not use.
5. Enforce hard limits outside the model. Truncate, validate, reject. A character cap belongs in your code, never in your prompt.
6. Trade length constraints for structural ones. Paragraphs and bullets are units the model controls. Words and characters are not.
7. Probe with a string nothing has memorised. A made-up word, a rare real name, a language you rarely use. That is where you learn what the model can do rather than what it was taught to say.
8. Repeat before believing. Three runs, then a conclusion.

Models will keep getting better at the famous examples, and the label on the failure will keep moving. The mechanism will not. Text becomes tokens before anything else happens, and no capability underneath that step restores the detail the step removed.