Why AI thinks in English and forgets in Arabic

For most of computing history, language was not a neutral layer. It was an assumption baked into infrastructure. Early digital systems were built around ASCII, a character set designed for English, and everything outside that narrow band came later, usually as an extension rather than a redesign.

When Unicode finally unified global scripts under one standard, it solved representation at the encoding level, but not at the level of tooling, layout, input methods, or developer expectations. The web that grew through the 1990s and early 2000s still assumed left-to-right text, Latin character sets, and English-centric sorting, search, and validation rules. Other scripts did not just plug in as newer batches — they had to be accommodated.

If you used Arabic or Hebrew online during that period, you didn’t need a theory of digital linguistics to understand this. You felt it. Text direction would flip unpredictably, diacritics would drop, and a form field might accept your input but display it as squares. Some systems silently stripped non-Latin characters. People developed workarounds that became normalized: transliteration into Latin letters, screenshots instead of text, avoiding punctuation that broke layout. These were not stylistic choices. They were adaptations to systems that treated your language as an exception.

That historical pattern matters because large language models did not emerge in a vacuum. They sit on top of the same digital ecosystem, the same data distributions, the same long tail of design decisions that centered English by default. When we talk about tokenization today, we are looking at a modern, mathematical expression of an older structural bias.

§Tokens are the front door to cognition

A language model does not see characters or words. It sees tokens — discrete numerical units produced by a tokenizer. The tokenizer’s job is to segment text into pieces that are both frequent in training data and efficient to process. Since the internet is heavily dominated by English and code, early tokenizers naturally aligned their vocabularies and subword patterns with English morphology. English words tended to map cleanly onto token boundaries. Many forms in morphologically rich languages, including Arabic and Hebrew, did not.

That mismatch is subtle but consequential. When a word is split into many tokens, the model has to spend more of its internal attention budget reconstructing the word before it can reason about it. That reconstruction competes directly with the resources needed for logical chains, abstraction, and long-range dependencies. Tokenization is the front door to cognition in these systems. If the front door is narrow for some languages and wide for others, everything downstream inherits that asymmetry.

For a long time, I experienced this indirectly. Arabic is my native language, and Hebrew is part of my daily environment. But when I wanted a model to reason through something complex, I would switch to English almost automatically. That felt like a habit. When I started measuring token counts, it looked more like adaptation.

The older generation of models makes this clear. Consider a multi-clause prompt about privacy regulation and AI surveillance. In English, the prompt occupies 30 tokens. In Arabic, it stretches to 118. In Hebrew, 149. That means the Hebrew version consumes nearly five times as much of the model’s context window just to express the same instruction. If you assume a fixed maximum context, the English user has far more headroom left for additional constraints, examples, or follow-up reasoning. The Arabic and Hebrew users begin the conversation already closer to the ceiling.

This pattern repeats across categories. Hebrew “Sustainability” in the older model takes 14 tokens. Arabic “Cybersecurity” takes 10. Hebrew “Algorithm” hits 10. These are not obscure words. They are common technical and abstract terms. The tokenizer was not recognizing them as cohesive units. It was fragmenting them into smaller pieces, often at character-like granularity. In effect, the model was spelling before it was reading.

Now compare those numbers with the newer generation. The same long privacy prompt remains at 30 tokens in English, but drops to 51 in Arabic and 54 in Hebrew. Arabic decreases by roughly 57 percent. Hebrew by about 64 percent. The gap does not disappear, but it shrinks from a catastrophic multiple to a manageable ratio. Instead of 4–5× English, these languages now sit at around 1.7–1.8×.

The improvements are not limited to one prompt. Hebrew “Sustainability” falls from 14 tokens to 6, a reduction of more than half. Arabic “Cybersecurity” drops from 10 to 5. Hebrew “Intelligence” moves from 13 to 6. Arabic “Architecture” decreases from 10 to 6. Across the matrix, many Semitic forms that once lived in the 8–16 token range now cluster around 2–6 tokens. French, by contrast, shows relatively modest shifts. Its token counts were already closer to English in earlier models, and they remain so.

This pattern tells us something important. The tokenizer has not simply become “more efficient” in a general sense. It has been expanded in directions where it previously lacked coverage. English remains stable, with minor improvement (which, by extension, allows for even better reasoning). French, already within the tokenizer’s comfort zone, changes little. Arabic and Hebrew, which previously triggered heavy fragmentation, show the largest gains. That is consistent with a deliberate design move toward multilingual representation rather than uniform compression.

While raw word counts vary across test cases, the transition from legacy to frontier engines reveals a massive improvement in efficiency. When running identical prompts in Arabic and Hebrew, the new architecture achieves a significant reduction in token density — effectively lowering the tax on Semitic processing.

§What that gap actually does

Character count plays a role here, but not in a simple way. Arabic and Hebrew often encode grammatical information inside word structure through prefixes, suffixes, and internal vowel patterns. A word may be longer in characters, but that does not inherently make it more expensive to process. What matters is whether the tokenizer’s vocabulary includes patterns that align with how the language builds meaning.

In older models, many of these patterns were absent, so segmentation cut across meaningful boundaries. In newer models, more of these forms appear to be captured as whole units or as better-aligned subwords. The result is fewer tokens per concept, even when character counts remain similar.

From a systems perspective, this marks a transition. Earlier models behaved like English-first cognitive architectures. Other languages were supported, but inefficiently, as if they were being translated into an internal English-shaped space, effectively pretending to understand languages. Newer models still center English in many ways, but they are moving toward a more genuinely multilingual input layer. Languages like Arabic and Hebrew are no longer processed primarily as edge cases.

This has implications beyond engineering elegance. The global user base of AI systems is not monolingual. When tokenization imposes heavy overhead on certain languages, it quietly shapes who can use these systems most effectively for complex tasks. It affects how much context a user can include, how many constraints they can specify, how far a reasoning chain can extend before the model begins to compress or simplify — or worse, hallucinate. That in turn influences which languages feel natural for analysis, design, or technical work, and which feel better suited for casual interaction. Over time, those dynamics intersect with economics, access, and power.

The numbers now suggest that one structural barrier is being lowered. English still enjoys the most efficient path through the model, but the difference is no longer so extreme that it dominates every interaction. The representational gap at the tokenization layer has narrowed significantly. That does not solve every bias or performance disparity, and token counts alone do not determine output quality. But they set the stage on which all reasoning happens.

What we are seeing is not just an incremental improvement. It is part of a longer arc in computing: from systems that implicitly assume one language, to systems that begin to take linguistic diversity as a design constraint. The web went through this shift slowly, often reactively. Language models are now going through a similar transition, but compressed into a few model generations.

For multilingual users, this may feel like a subtle change: prompts that once seemed to lose sharpness in Arabic now hold together better; Hebrew instructions no longer feel as cramped. Underneath that experience is a structural evolution. The machine used to read English fluently and everyone else with effort. It is still learning, but it is starting to read more of the world without first forcing it into an English-shaped mold.

If you’re a multilingual user of AI, do you find yourself conversing with AI models in your native language, or do you also default to English?