Why AI Can’t Count the Letters in a Word
4 min read · updated August 3, 2026
A model that writes working code and passes professional exams will sometimes miscount the letters in a short common word. The gap is startling enough that it gets used as evidence about intelligence in general. It is evidence about the input format, and the input format is worth understanding because it predicts a whole family of unrelated-looking failures.
The failure, stated precisely
The reproducible version is narrow. Ask for the count of a particular letter in a word, and you get a confident number that is sometimes wrong — usually off by one, usually on words where the letter appears more than once, and usually stated with the same fluency as a correct answer. Ask the model to spell the word out first and the answer is typically right.
That last detail is the diagnostic one, and it rules out most of the explanations people reach for. The model is not incapable of counting; it counts fine when the letters are present as separate items. The problem is upstream of the counting.
What the model actually receives
The model does not see characters. Text is converted into tokens before it reaches the model, by a tokeniser that maps frequent character sequences to single integers. A common word is often one token. A less common one is a handful of subword pieces, split at boundaries chosen by frequency in the tokeniser’s training corpus rather than by anything to do with spelling.
So a word arrives as, say, two integers. The characters are not absent — the model can learn associations between token identities and their spellings, because spellings do appear in text — but they are not present either. There is no operation available to the model that iterates over the letters of a token, because at that layer the letters do not exist as separable things. How the tokeniser builds its vocabulary explains why the split points look arbitrary from a speller’s point of view.
The comparison that makes this intuitive: you are being asked how many times a particular stroke appears in a character of a writing system you can read fluently but have only ever encountered as whole units. You might know the answer for common ones, by memory. You cannot derive it, because you never had the parts.
Why it is hard rather than impossible
Two things follow that explain the otherwise confusing pattern of when this works and when it does not.
- Frequency matters more than difficulty. Spelling facts about very common words appear often in text — in word games, in spelling instruction, in discussions of the words themselves — so they can be memorised as associations. Rarer words have less such text, and performance degrades accordingly. A harder-looking word is not necessarily a harder case; a rarer one is.
- Making the characters explicit fixes it. Asking for the word spelled with separators before counting turns an unavailable operation into an available one: once the letters are individual tokens, counting them is ordinary sequence work. This is the same principle as showing working on arithmetic, and it is why step-by-step prompting helps on a class of tasks that look nothing alike.
It also explains the confidence. The model has no signal that this question is one it cannot compute — the token sequence looks like an easy question, so the continuation looks like an easy answer. Nothing in the mechanism produces a hedge, which is the general reason stated confidence tracks fluency rather than correctness.
The family of tasks this predicts
This is why the failure is worth understanding rather than just laughing at: the same cause produces failures that look completely unrelated to each other. Anything requiring operations below the token boundary is in the same family.
| Task | Description |
|---|---|
| reverse a string | Requires character-level ordering. Fails on unfamiliar words, succeeds on familiar ones, for the same reason as counting. |
| rhyme and syllable counting | Depends on phonetics, which is another representation the model does not receive. Works where the rhyme is attested in text, degrades on invented words. |
| acrostics and constrained writing | Anything specifying which letter a word must start with is a character-level constraint imposed on a token-level generator. |
| exact character positions | “Replace the fourth character” has no direct implementation at the token layer. |
| digit-level arithmetic | Numbers tokenise inconsistently, so digit alignment is not guaranteed. Related, and part of why arithmetic errors cluster on long numbers. |
The engineering conclusion is short: if a task needs exact operations on characters or digits, do not ask the model to perform them. Have it produce a program, or a structured output, and let ordinary code do the counting. That is not a workaround for a temporary limitation; it is the right division of labour between a probabilistic sequence model and a deterministic one.
What the failure does and does not tell you
It tells you that the input representation constrains the operations available, which is a real and general lesson. It tells you that fluency is not evidence of the answer being computed rather than recalled.
It does not tell you anything about capability on tasks that operate at or above the token level, which is nearly all of them. Using it as a general argument about reasoning makes a specific mistake: treating an input-encoding limitation as if it were a limitation of the function computed on top of that encoding. A person who cannot read a document in the dark has not thereby been shown to be illiterate.