Why LLMs Cannot Spell or Count Letters

Ask a language model how many times the letter "r" appears in "strawberry," and for a surprisingly long stretch of frontier-model history you would get a confidently wrong answer. Not because the model cannot count, but because it was never shown the letters to count in the first place.

The model never sees characters

Once a word is tokenised, the model's input is a sequence of integer token IDs, each looked up in an embedding table to produce a vector. The string "strawberry" might arrive as one or two token IDs depending on the vocabulary. Beyond that lookup, the model has no direct access to the literal characters that made up the original string, only whatever the embedding vector happens to encode. Some spelling information does leak in indirectly, through co-occurrence with related tokens, dictionary text, or spelling-focused content in training data, but there is no built-in mechanism for the model to inspect the sequence of letters inside a token the way a human eye scans a printed word.

Contrast with what the model is good at

This is not a general reasoning failure, it is a representational one, which is exactly why a model that misspells or miscounts letters can still reason well about a word's meaning and usage. It also explains a counterintuitive correlation: a rare word that gets split into many small, near-character-length pieces gives the model more direct access to its spelling than a common word compressed into one or two large tokens. Common words, precisely because the tokeniser compresses them efficiently, are the ones the model has the least direct spelling access to (see byte-level-bpe and tokenisation-bpe for why compression varies by frequency).

Why bigger models don't automatically fix it

Scaling parameters or training data does not remove the representational bottleneck. Spelling information about a rarely-decomposed token is either present in training data often enough to be memorised indirectly, or it is not; the fix has to happen at the tokeniser or architecture level (character or byte-level access, an explicit spelling tool, or a training objective that forces character-level supervision), not simply through more compute. Some production systems sidestep the problem by giving the model an explicit tool call to count characters programmatically rather than relying on the forward pass alone.

When it falls down (misconceptions this corrects)

• It is not evidence the model "doesn't understand" the word. Semantic understanding and character-level access are separate capabilities that draw on different information in the token representation.
• Prompting tricks help by working around the tokeniser, not fixing it. Asking a model to "spell it out letter by letter" improves accuracy because it forces each character to become its own output token the model can then attend to, not because it grants new access to internal structure (see chain-of-thought).
• The bottleneck generalises beyond spelling. Any task needing sub-token structure, counting characters, reversing a string, certain kinds of arithmetic, inherits the same limitation (see tokenisation-and-arithmetic).

Further reading

• Sennrich, Haddow, Birch, 2016, Neural Machine Translation of Rare Words with Subword Units - why subword units, and their compression tradeoffs, exist in the first place.
• Radford et al., 2019, Language Models are Unsupervised Multitask Learners (GPT-2) - the byte-level tokeniser whose compression choices shape this effect.