How Many Languages Does an LLM Actually Support Well

A model that produces grammatical text in a hundred languages is not a model that supports a hundred languages, and the vendors mostly agree — their own model cards commit to far shorter lists than their models can visibly do. The gap between the two numbers is where production failures live.

Three different numbers, routinely conflated

Any claim about language support is one of these three, and they differ by an order of magnitude at each step:

• Languages it can emit. Any language with meaningful presence in web-scale pretraining — well over a hundred. The output is grammatical and often fluent. Nothing was verified.
• Languages officially supported. The list on the model card. This is a commitment: the vendor evaluated these and will answer for them. Typically eight to thirty.
• Languages with published benchmark results. Where a number exists that you can read. Usually a subset of the supported list, and often a different subset per benchmark.

The first number is the one that appears in marketing and in casual testing, because it is the one you observe by typing. It is also the least informative, since fluency and correctness are separate properties — a model producing confident, well-formed, factually wrong text in a low-resource language is exhibiting the first without the third, and it is precisely the pattern described in why low-resource languages hallucinate more.

What model cards actually commit to

The interesting evidence is that vendors themselves draw the line much lower than observed fluency would suggest. Meta’s Llama 3.1 model card states that the model officially supports eight languages — English, German, French, Italian, Portuguese, Hindi, Spanish and Thai — while acknowledging that the model was trained on a broader collection and can produce text in more. The card is published in Meta’s llama-models repository. That is a lab with every incentive to claim a large number choosing to claim eight, and it is the single most useful data point on this question.

Cohere’s Command R family and Alibaba’s Qwen models similarly publish supported-language lists in the tens rather than the hundreds, and OpenAI’s GPT-4 technical report, published in March 2023, reported results on MMLU translated into 26 languages — an evaluated set, again in the tens.

Read the wording on these lists carefully, because it is doing work. “Officially supported” means evaluated and committed to. “Trained on” means present in the data. “Optimised for” usually means instruction-tuned in that language, which is a stronger claim than pretraining exposure and a weaker one than benchmarked. A card that lists a language only under “trained on” is telling you the model has seen it, and nothing else.

What the benchmarks cover

The published multilingual evaluation sets set an upper bound on what anyone can report:

• FLORES-200, released by Meta with the No Language Left Behind work in 2022, provides professionally translated parallel sentences across 200 languages. It is a translation benchmark, so it measures whether meaning survives — not reasoning, not instruction following.
• Belebele, released by Meta in 2023, is a reading-comprehension benchmark spanning 122 language variants, built on FLORES passages. It is the broadest comprehension benchmark available.
• Translated MMLU variants cover knowledge and reasoning in the tens of languages, not the hundreds.
• Instruction-following and safety evaluations are the narrowest of all, and are frequently English-only. This is the gap that matters most in production, because it is the capability your application depends on, and it is discussed in benchmark coverage gaps across languages.

The shape of that list is the answer to the title question. Coverage narrows as the capability being measured gets closer to what an application actually needs. Two hundred languages for translation, a hundred-odd for comprehension, tens for reasoning, and a handful for instruction adherence and safety.

A threshold you can apply yourself

“Supports well” needs a definition or the question has no answer. A workable one, stated as four conditions that must all hold for your task:

1. Output is grammatical and idiomatic to a native reader — not merely parseable. One native reviewer detects this in twenty samples.
2. Instructions are followed as reliably as in English. Run the same structured task in both languages and compare schema adherence, not answer quality. This degrades before fluency does and it is the most common production surprise.
3. Factual accuracy does not drop. Ask the same verifiable questions in both languages. A widening gap indicates the model is drawing on thinner knowledge, not just expressing it differently.
4. Refusal behaviour is consistent. Safety tuning is the most English-centric layer in the stack, so a model can be simultaneously more permissive and more prone to false refusals in a second language. Both directions are problems and neither shows up in a quality review.

Apply that and the practical answer for most frontier models is somewhere between five and fifteen languages for a demanding application, twenty to thirty for tolerant ones, and the long tail usable only for tasks where a fluent guess is acceptable.

What to ask before shipping a language

The published numbers cannot answer the question for your task, because none of the benchmarks is your task. What they can do is tell you where to spend your evaluation effort: a language on the official list needs a sanity check, and a language off it needs a real evaluation set of your own before it goes to users.

Build that set from your own traffic — fifty to a hundred real inputs per language with expected outputs is enough to separate “works for us” from “emits fluent text”. It is a day of work per language and it is the only measurement that answers the question you have.