Why AI Can't Count: The Popular Explanation Is Only Half Right

By Derek Rousseau · September 14, 2026

Ask an assistant how many times the letter r appears in “strawberry” and there is a decent chance it says two. Ask it how many items are in a list you pasted, or how many characters are in a headline, and it will give you a number with the same untroubled confidence.

This is a strange failure. These systems can draft a contract clause and then miscount a five-letter word. It is worth understanding, because the tasks it ruins at work are more common than the party trick suggests.

The failure is real and it is not rare

CharBench, presented at AAAI-26, is a benchmark A fixed set of test questions everyone runs their model against, so results can be compared. Size matters more than it sounds: a small benchmark can be passed by luck or by having seen similar questions before, and it cannot tell you which properties of a question predict failure. CharBench is described by its authors as two orders of magnitude larger than what existed before, which is roughly a hundred times, and that is what makes it able to answer the question in this post rather than just report a score. built specifically for character-level tasks. Across a range of leading open and proprietary models, it reports an average accuracy of 43.6%, falling to 32.3% on some tasks.

On a category of question a nine-year-old gets right every time, some of the most capable software ever built is performing at roughly a coin flip.

The explanation everyone gives

The standard answer, which you will find in every thread on the subject, is tokenization Before a model sees your text, the text is chopped into chunks called tokens, often word fragments rather than letters, and each chunk is swapped for an ID number. The model works on those numbers. Models are built this way because letter-by-letter input would make every sequence several times longer, and the cost of processing a sequence grows faster than its length, so you would pay that penalty on every task you ever run in order to fix a narrow one. .

The argument is as follows: if “strawberry” reaches the model as two or three chunks rather than ten letters, then the letters are simply not there to be counted. The model is recalling what it has read about the word rather than looking at it.

That story has real support. The Strawberry Problem, an oral paper at EMNLP 2025, analyzes exactly this and finds that character-level ability “emerges suddenly and only late in training,” which is what you would expect if the model has to infer spelling indirectly rather than read it off.

A bigger benchmark says it is not the main cause

Here is where the that argument runs into trouble.

CharBench set out to test whether tokenization explains these failures, and on counting it found that tokenization properties correlate only weakly with accuracy. What predicted whether a model got a count right was something much simpler: the length of the word being asked about, and how large the actual count was.

Tokenization did matter, but for a different job. On tasks about where a character sits rather than how many there are, performance fell as tokens got longer, and the authors conclude that longer tokens obscure character position. So the paper’s finding is split: tokenization substantially impairs positional reasoning, and is a minor factor in counting.

The two papers are not really in conflict, because they ask different questions. One studies how character knowledge gets learned during training, where the token boundary genuinely is the obstacle. The other measures what predicts a wrong answer at the moment you ask, across models that have already finished training. Both can hold. But the popular version, that tokenization is why it miscounts, is the second question wearing the first question’s answer.

What actually predicts it, and why that is worse for you

Strip out the mechanism and keep the finding: errors rise with the length of the thing and the size of the number.

This is worse news than the tokenization story.

If tokenization were the cause, the problem would be narrow. It would live in letter puzzles and words like strawberry, safely away from your actual job.

Length and size are not narrow. Longer text and bigger numbers are what real work is made of. So the error is smallest on a five-letter word, where you would spot it at once, and largest on a long document, where you will never check. That is the same trap as the errors that survive a review.

The counting you actually ask for

The strawberry example makes this sound like a curiosity. Look at what it covers in an ordinary week:

“How many characters is this?” for a subject line, a meta description, an ad headline, a field with a hard limit.
“How many items are on this list?” after pasting something long.
“How many of these are still outstanding?” across a status column.
“How many times does this appear?” in a transcript, a log, a policy.
Any total it produced by adding up things it read rather than things it calculated.

None of those look like letter puzzles. All of them are the same operation, and all of them get a confident number back with no signal attached about whether it was counted or estimated.

Make it write the counter, not do the counting

The fix is the same one this site reaches for whenever arithmetic is involved, and it works because it moves the job out of the part of the system that is guessing.

Ask for the formula or the code, not the number. In a spreadsheet that means asking for a COUNTIF rather than a total, which recalculates and can be audited. Outside a spreadsheet, ask it to write a few lines that count, and run them.
Use the tool that has a counter in it. Your editor has a word count. Your browser has find-on-page with a match count. These are exact and free.
If you must ask it directly, ask it to list before it totals. Making it enumerate the items first turns one opaque guess into something you can check at a glance, and it tends to improve the count as a side effect.
Treat any number it read rather than computed as unverified. That includes counts inside otherwise excellent prose, which is where they hide.

A useful rule: if you would not accept the number without a source from a colleague, do not accept it here because it arrived in a fluent sentence.

The takeaway

Models fail at counting far more often than their general fluency suggests, and the tidy explanation you have probably heard does not survive the largest test of it.

Do not ask AI to count. Ask it to build the thing that counts. The error rate climbs with length and with the size of the number, which means it is mildest on the examples people use to demonstrate the problem and worst on the real documents where nobody is checking.

Sources: the accuracy figures and the finding that tokenization correlates only weakly with counting are from Omri Uzan and Yuval Pinter, “CharBench: Evaluating the Role of Tokenization in Character-Level Tasks” (opens in a new tab) (AAAI-26; arXiv 2508.02591, August 2025, revised April 2026). The training-time analysis and the quoted phrase about capabilities emerging late are from Adrian Cosma, Stefan Ruseti, Emilian Radoi and Mihai Dascalu, “The Strawberry Problem: Emergence of Character-level Understanding in Tokenized Language Models” (opens in a new tab) (EMNLP 2025 main conference, oral). I have read both abstracts and neither full paper, so the account of how the two fit together is my reading of what each one reports rather than anything either set of authors claims about the other. Both test specific models at a moment in time and this behavior can change with a release. The argument that length and magnitude make this a work problem rather than a curiosity, and the four habits, are mine.

Related: AI for Spreadsheets: Let AI Write the Formula, Not the Answer is this fix worked through properly on the place it matters most. Why AI Makes Things Up: It Was Trained to Guess is the other confident-and-wrong failure, which has a different cause and a different check.