Why Your LLM Still Thinks in English: The Multilingual Reasoning Gap That Will Limit Your Global AI Deployments

Enterprise AI deployments rarely fail loudly. They fail quietly, in ways that surface months after launch as user drop-off in specific markets, support ticket spikes in non-English regions, or a persistent quality gap that nobody can quite explain. One of the most common and least examined causes is a structural property of modern reasoning models: regardless of the language a user writes in, the model reasons internally in English before translating back to a response. That internal detour is not a minor implementation detail. It is a source of systematic quality degradation that scales with your international user base.

Companion piece to our broader work on LLM behaviour across languages and deployment contexts. See Why Your LLM Behaves Differently Across Languages and Model Versions for what engineering leaders must know before deploying globally.

The Mechanism Behind English-Centric Reasoning

Most reasoning models are trained on a chain-of-thought paradigm, where the model generates intermediate reasoning steps before producing a final answer. The problem is that the overwhelming majority of reasoning supervision data is English-only (Mofakhami et al., arXiv 2026). When a model receives a prompt in Japanese or Arabic, it has learned to reason in English because that is where its structured, step-by-step problem-solving signal comes from.

The consequence is a translation pipeline embedded inside the model's own inference process. The model maps the non-English prompt into an English reasoning chain, performs deduction in English, then maps the conclusion back to the target language. Each of those translation steps introduces the possibility of semantic loss, particularly for concepts, idioms, or domain-specific terminology that do not map cleanly across languages.

This is not a hypothetical edge case. Research from Cohere Labs confirmed that even models that respond fluently in non-English languages conduct their internal reasoning in English, regardless of the prompt language (Mofakhami et al., arXiv 2026). Fluent output is not the same as in-language reasoning, and conflating the two leads to deployment decisions that look sound on surface benchmarks but fail under real-world usage conditions.

Why This Creates Silent Quality Degradation at Scale

The failure mode is particularly difficult to catch because standard evaluation pipelines do not expose it. If you benchmark a model on English reasoning tasks and separately test its translation quality, both can look acceptable. The degradation occurs in the interaction between the two, in the semantic fidelity of the reasoning chain itself.

Consider a multilingual customer-facing application where users submit complex queries in their native language. A model reasoning internally in English may misattribute the intent of culturally specific phrasing, lose precision in technical or legal terminology, or produce answers that are grammatically correct in the target language but logically derived from a subtly different question. Users experience this as the model feeling slightly off, and they stop trusting it.

At scale, that erosion of trust is a commercial problem. If your AI product serves markets in German, Korean, and Portuguese, and each of those user populations is receiving reasoning derived from an English interpretation of their input, you are not deploying one product. You are deploying a product that performs differently for different users in ways your internal metrics are unlikely to catch.

What the Data Mixing Research Tells Us

The most actionable finding from recent research is that in-language reasoning does not require reasoning supervision in every target language. Mofakhami et al. (arXiv 2026) demonstrated that a model can generalise reasoning behaviour to held-out languages through careful data mixing during supervised fine-tuning, combining a strong English reasoning backbone with broad multilingual non-reasoning data. Their Tiny Aya L2-Thinker model achieved an in-language reasoning rate above 93% across 60 languages without requiring native reasoning examples for each one.

This matters for engineering teams because it changes the feasibility calculus. Building multilingual reasoning capability does not require constructing reasoning datasets in dozens of languages from scratch. It requires deliberate data composition strategy at the fine-tuning stage, with sufficient language coverage and a strong enough English reasoning foundation to generalise from.

The implication for model selection is equally direct. If a vendor cannot describe the data mixing strategy used during fine-tuning, and cannot provide in-language reasoning rate metrics across your target languages, you do not have enough information to assess whether the model is fit for your deployment context.

Evaluation Criteria for Global Deployments

When assessing a reasoning model for multilingual production use, the evaluation framework needs to go beyond accuracy on translated benchmarks.

In-Language Reasoning Rate

This is the proportion of reasoning chains the model generates in the same language as the prompt. A model can score well on a multilingual benchmark while still reasoning in English internally. Ask vendors for this metric explicitly, and test it yourself using chain-of-thought outputs where the reasoning trace is visible.

Cross-Lingual Intent Fidelity

Design evaluation sets that include prompts where the correct answer depends on culturally or linguistically specific interpretation. If the model consistently defaults to the English-language interpretation of an ambiguous term, that is a signal of English-centric reasoning regardless of what language the final answer appears in.

Performance Variance Across Language Families

Aggregate accuracy metrics mask distributional variance. A model may perform well on European languages and degrade significantly on languages with different morphological structures or writing systems. Evaluate across typologically diverse languages that reflect your actual user base, not just the languages that happen to appear in standard multilingual benchmarks.

What Engineering Leaders Should Act On

The first step is reclassifying multilingual capability as a deployment risk category rather than a feature checklist item. Language support listed on a model card tells you nothing about in-language reasoning quality. Treating it as a binary check creates false confidence in deployments that will underperform in non-English markets.

The second step is building evaluation infrastructure that can surface this failure mode before it reaches production. That means logging and inspecting reasoning traces in non-English sessions, running structured red-teaming exercises in your target languages, and establishing baseline metrics for in-language reasoning rate that you can track across model versions.

The third step, if you are fine-tuning your own models, is treating data mixing strategy as a first-class architectural decision. The research evidence suggests that broader language coverage in non-reasoning data, combined with a strong English reasoning backbone, is a more efficient path to multilingual reasoning generalisation than attempting to source reasoning supervision data in every target language (Mofakhami et al., arXiv 2026). That finding should directly inform how you allocate data engineering effort.