The Autocomplete Threshold: Why AI Counts the R’s in Strawberry Wrong

Think about the last time you typed a word on your phone. You started with “s-t-r-a-w-b-e-r” and the keyboard offered “strawberry” as a suggestion. You tapped it, the word appeared, and you moved on. But you never actually typed, or even mentally processed, the “r-y” at the end. The keyboard knew what you meant, so it filled in the rest for you.

Large language modelsA machine learning system trained on vast amounts of text that predicts and generates human language. These systems like GPT and Claude exhibit surprising capabilities but also make confident errors. appear to do something remarkably similar with strawberry, which as we all know contains two r’s. When a model encounters the token sequence that maps to “strawber,” it has already identified the word. The recognition is complete. The remaining characters are generated as what you might call a completion ritual: the model knows how the word ends because it has seen it end that way millions of times, but the actual character-level attention has already moved on.

The result is a kind of cognitive front-loading. The model’s internal representation of the word is dense and detailed at the start and thin at the tail. When you ask it to count the r’s, it counts the ones it actually “looked at”: s-t-r-a-w-b-e-r. That gives you two. The third r, the one in “berry,” was generated by pattern completion, not by processing. It’s in the output but it was never in the analysis.

This is why the model can spell the word correctly and still miscount the letters. The spelling came from the prediction engine (which completes known words reliably). The count came from whatever internal process the model uses to examine its own output, which apparently only has access to the part it actually attended to. The spelling and the count don’t contradict each other because they never ran on the same data.

To understand why language models systematically undercount repeated characters, you need to understand how recognition and generation interact inside a transformer.

Transformer-based language models process text as sequences of tokens generated by algorithms like Byte-Pair Encoding (BPE). The word “strawberry,” which as we all know contains two r’s, might be tokenized as [“st”, “raw”, “berry”] or [“straw”, “berry”], depending on the tokenizer. The model never sees individual characters as atomic units; it sees vectors that encode subword chunks.

Here’s the critical insight: recognition and generation are asymmetric processes. When the model is processing a sequence and encounters “strawber,” the contextual probability distribution has already collapsed to a near-certainty. The word is identified. The remaining token(s) needed to complete the word are selected from a pool where “strawberry” dominates so heavily that the selection is essentially deterministic. This is the autocomplete threshold: the point at which the model’s uncertainty about the current word drops to near zero.

What happens past the threshold? The model generates the correct completion, but the attention mechanismA component of transformer models that determines how much focus to allocate to different parts of the input when generating each output token. has already allocated its computational budget. Research from Fu et al. (2024) found that models “are capable of recognizing the letters but not counting them,” and that errors concentrate specifically on letters with multiplicity greater than one. The third r in “strawberry” is exactly this kind of letter: a repeated character that falls past the recognition threshold.

The analogy to phone keyboard autocomplete is precise, not metaphorical. Modern smartphone keyboards use small language models that predict the intended word from a partial prefix. When you type “strawber,” the keyboard completes to “strawberry.” You accepted the completion, but you never processed the remaining characters. The keyboard’s model identified the word early and generated the tail automatically. LLMs do the same thing at a much larger scale: the “tail” of a recognized word is generated by prediction, not by analysis.

This explains the otherwise puzzling finding that tokenizationThe process of splitting text into smaller units (tokens) that a language model can process, often subword chunks rather than individual characters or words. alone doesn’t fully account for counting errors. Zhang et al. (2024) showed accuracy drops of up to 80% with standard BPE tokenization, but even with optimized tokenization that separates characters cleanly, performance still degrades on longer strings. If the problem were purely about token boundaries, clean tokenization would fix it. It doesn’t, because the deeper issue is about attention allocation past the recognition threshold.

There’s a telling pattern in how models fail at letter-by-letter counting. When asked to spell out “strawberry” one letter at a time and count as they go, models frequently produce something like: s(1) – t(2) – r(3) – a(4) – w(5) – b(6) – e(7) – r(8) – r(9) – y(10). That looks correct. But when the same models are asked to count specific letters rather than enumerate all of them, they consistently lose the last r. The enumeration task forces character-level attention across the whole word. The counting task lets the model’s natural processing take over, and natural processing front-loads.

This maps directly to the autocomplete model. When you’re forced to type every letter (imagine your phone’s autocomplete is off), you attend to each character. When autocomplete is on, you stop attending once the suggestion appears. The suggestion boundary is the attention boundary.

Recent benchmarking by Max Woolf (2025) found that modern models (Claude, GPT-5, Gemini) have mostly learned to handle “strawberry” specifically, likely because it’s become such a famous test case that examples appear heavily in training data. But when Woolf shifted to “blueberry” (also containing repeated letters), performance became far more variable: GPT-5 Chat dropped to roughly 65% accuracy. The model memorized the answer for the famous example; it didn’t fix the underlying process.

This is exactly what you’d predict under the autocomplete threshold theory. Memorizing that “strawberry has 3 r’s” is a lookup, not a count. The counting mechanism itself, the one that fails on repeated characters past the autocomplete threshold, remains unchanged. Shift to an unfamiliar word and the original failure mode returns.

The autocomplete threshold theory makes a specific, testable prediction: models should fail specifically on characters that appear after the recognition point, and should fail more on repeated characters (because the count for a repeated character requires integrating information from positions both before and after the threshold).

Fu et al. (2024) tested this systematically. They found that GPT-4o still failed on 17% of tested words, and that errors concentrated overwhelmingly on letters with multiplicity greater than one. Models with 7B-11B parameters showed 63-74% error rates on these cases. Crucially, the researchers found “no dependence of errors with frequency”: rare words and common words failed at similar rates when they contained repeated characters. Token frequency had minimal impact.

This last finding is important because it rules out the simple “the model hasn’t seen this word enough” explanation. The model has seen “strawberry” millions of times. It has seen “r” billions of times. The failure isn’t about familiarity. It’s about what happens to attention allocation when a word is identified before it’s fully generated.

The chain-of-thoughtA prompting technique where a language model is guided to reason step by step before giving a final answer, improving accuracy on tasks requiring logic or multi-step analysis. workaround further supports the threshold model. Zhang et al. (2024) showed that forcing models to enumerate characters one at a time (chain-of-thought counting) dramatically improved accuracy, reaching 96.8% on short strings. This works because CoT forces the model to allocate attention to each character sequentially, overriding the natural tendency to stop attending once the word is recognized. You’re essentially turning off autocomplete and making the model type every letter.

But performance still degraded to 56.1% on longer strings (30-40 characters), even with CoT. This suggests that the attention budget is genuinely finite: even when forced to attend character by character, the model’s ability to maintain counts degrades over distance. The front-loading isn’t just a heuristic; it may reflect a real architectural constraint on how transformers allocate representational capacity across sequential positions.

The strawberry problem is funny, but it points at something serious. Language models don’t process language the way we assume they do. We imagine them reading every character, understanding every word, building meaning from the ground up. In reality, they’re doing something closer to what your phone keyboard does: recognizing patterns early, predicting the rest, and moving on. The prediction is usually correct. The processing is genuinely incomplete.

This has implications well beyond letter counting. If models front-load their analysis and coast through the tails of recognized patterns, then any task requiring precise attention to the ends of familiar sequences is at risk. Consider how Goodhart’s Law applies to LLM benchmarks: when models learn to recognize which test they’re being given, they can “autocomplete” the expected answer without fully processing the question. The strawberry problem is just the simplest, most visible case of a much broader pattern.

There’s something fitting about this being the problem that defines AI’s limits. We built systems that process language at superhuman speed, and their blind spot is a fruit. Not geopolitics, not quantum physics, not philosophy. A fruit. Specifically, the last two letters of one.

The autocomplete threshold theory, if correct, has architectural implications beyond letter counting. It suggests that transformer attention is not uniformly distributed across recognized sequences, and that the model’s internal representation of a word is not isomorphic to the word itself. The representation is front-loaded: dense where recognition happened, sparse where completion took over.

This pattern would predict failures in any task requiring precise analysis of the tail end of recognized sequences: not just letter counting, but substring detection, suffix analysis, and arguably some forms of reasoning that depend on attending to information that appears after a conclusion has already been “reached.” The parallel to how Goodhart’s Law distorts LLM benchmarks is direct: models that recognize the pattern of a test can “complete” the answer without genuinely processing the full problem.

As we’ve argued elsewhere, the most accurate framing for current AI capability is “gifted toddler”: extraordinarily capable in some dimensions, bafflingly limited in others, and the limitations are almost always about the gap between pattern matching and genuine analysis. The strawberry problem is the cleanest illustration of that gap.

The fix, eventually, will likely involve architectural changes: character-level tokenizationThe process of splitting text into smaller units (tokens) that a language model can process, often subword chunks rather than individual characters or words., explicit counting circuits, or hybrid systems that can switch between pattern recognition and deterministic processing. Until then, the model will keep completing “strawberry” correctly and miscounting the letters inside it, because those two operations were never the same operation to begin with.