The Model Knew Everything Except What Language It Was Speaking

A model was given an English forum post and asked to summarize it in the original language. It understood the post perfectly. It identified the user’s plan, the exhausted weekly quota, the request for a courtesy reset, and the question about higher tiers. It returned valid JSON matching a strict schema.

It wrote the summary in Japanese.

{"summary":"20xプランの有料利用者が通常のソフトウェア開発でCodexの週間上限に達し、特別な上限リセットの可否や、より利用枠の多い上位プランについて情報を求めている。"}

The model was gpt-5.6-sol at medium reasoning effort. The source contained no Japanese. Every natural-language field in the request was English. The instruction was explicit:

Use the original language of the text.

This was not a streaming bug. The completed API event contained the intact Japanese string. It was not a malformed-output problem either: the response was valid JSON and semantically excellent. The model had solved the summarization task and failed what looked like its easiest constraint.

That combination was too strange not to reproduce.

Reproducing the failure

I ran the same source and substantially the same instructions through gpt-5.6-sol-medium four more times. Three summaries came back in Chinese. One came back in English.

A representative failure:

{"summary":"一名使用20x付费计划进行专业软件开发的用户已耗尽每周Codex配额，询问能否申请临时重置额度，或升级至提供更高使用上限的套餐。"}

Again, the content was right. A paid 20x-plan user had exhausted the weekly Codex quota doing professional software development and wanted to know about resets or plans with larger limits. Wrong language, flawless summary.

Across the original report and my reproductions, the same English source produced Japanese, Chinese, and English. This did not look like the model consistently misclassifying the text as one particular language. It looked more like an unstable choice of linguistic mode.

There is an important methodological caveat. The original result came from an OpenAI Responses API request using priority service and strict JSON-schema output. My 25 follow-up trials used the ChatGPT OAuth route through term-llm, with the same model family and medium effort but without API-enforced schema validation. The failure therefore crosses two serving paths, but the trial groups are not perfectly identical.

The obvious fixes

First I replaced the ambiguous language-preservation instruction with an explicit one:

The source text is English. The summary MUST be in English. Do not translate it.

All three trials returned English.

Then I removed the language instruction entirely. Since the prompt and source were English, the model naturally answered in English in all three trials.

Hard-coding English works if every source is English. It is not much use for a forum containing posts in dozens of languages. Detecting the language in application code and injecting its name would be robust, but it adds another classifier and another moving part.

There was a more interesting option: ask the model to spend thought on the thing it was getting wrong.

“Think carefully” helps, but does not solve it

I added one sentence:

Think carefully before responding.

Four of five outputs were English. The fifth was Chinese.

That is better than the original result, although the sample is far too small to assign a reliable improvement percentage. More importantly, it exposes the limitation of generic reasoning prompts. “Think carefully” gives the model no information about where care is needed. It may inspect the summary’s factual coverage, word count, tone, JSON syntax, or any of a dozen other constraints that were already working.

The model had no shortage of intelligence. It had a problem allocating that intelligence.

Directed deliberation

The next instruction kept the requirement dynamic—no language was hard-coded—but turned language preservation into a small procedure:

Before answering, think carefully about which language the source text is written in, then verify that the summary uses that same language. Do not include your reasoning or language identification in the response.

Five of five outputs were English.

I then made the procedure more explicit:

First silently identify the source language from the actual conversation text, not names, metadata, or the discussion title. Only then compose the summary in the identified language and check it before returning.

Another five of five outputs were English.

Ten successes do not prove the bug is gone. They do show a sharp difference between asking a model to think and telling it what decision deserves thought.

The prompt I would ship is:

Use the original language of the conversation text.

Before answering:
1. Silently identify the language used by the conversation text.
2. Compose the summary in that language.
3. Verify that the summary language matches the conversation language.

Do not output the language identification or your reasoning.
Return only the requested JSON object.

For a high-stakes or high-volume system I would still validate the output language and retry on mismatch. Directed deliberation improves the generation path; validation gives you an actual reliability boundary.

How can such a smart model make such a stupid mistake?

“Smart” is not one scalar property. The model performed the difficult semantic work correctly and failed an early control decision: which linguistic register to enter.

After emitting:

{"summary":"

the next token effectively chooses a language basin. If the model emits a Chinese character, the following token probabilities strongly favour grammatical Chinese. Once it starts down that track, continuing coherently is easier than stopping to reconsider why it chose Chinese. A tiny routing error becomes a fluent, confident, internally consistent answer.

The phrase “use the original language” may activate a learned multilingual summarization pattern: infer the source language, activate that language, summarize. Nothing guarantees that the first step is implemented as a robust, explicit language detector. It may be an implicit choice distributed through the same activations doing everything else. Names, metadata, formatting, and multilingual training examples can perturb that choice without affecting semantic understanding.

There is another clue in the original API response: despite medium reasoning effort, it reported zero reasoning tokens. The task looked easy, so the model answered directly. It apparently never formed an explicit checkpoint resembling:

Source language: English
Required output language: English

The directed prompt creates that checkpoint without requiring the reasoning to be exposed.

Strict JSON schema does not help. It can guarantee that summary is a string. It cannot guarantee that the string is in the source language. Structural correctness and semantic instruction-following are different layers, and the response was perfect at one while plainly wrong at the other.

The useful lesson

The usual debate about prompting reasoning models is framed too crudely: should we tell them to think, or should they already know when thinking is necessary?

This experiment suggests a better distinction:

• Generic deliberation: “Think carefully.”
• Directed deliberation: “Identify this specific latent variable, use it when generating, then verify it.”

The first is encouragement. The second is a program.

Models like gpt-5.6-sol already have extraordinary capability. The practical problem is often not adding more intelligence, but routing existing intelligence toward the fragile step. A three-line internal checklist fixed a failure that more general exhortation only reduced.

The model did not need to think harder about the summary. It needed to notice that language selection was part of the task.