[FEATURE] Add `thinking_language` parameter to control extended thinking output language

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Non-English speaking developers who enable verbose output (via --verbose flag or the /config setting) to monitor extended thinking face a significant cognitive burden. With Claude Opus 4.6, thinking blocks are output exclusively in English, regardless of language settings in CLAUDE.md, settings.json, or system prompts.

This is a regression from Opus 4.5, where thinking blocks naturally followed the conversation language. With Opus 4.6, the model's training pattern overrides any user-specified language preference for thinking blocks.

For non-native English speakers, the difference is critical:

• Native language: Thinking content can be scanned quickly to grasp structure and key decisions at a glance
• English: Each sentence requires deliberate reading and interpretation, consuming significant cognitive resources

Thinking blocks are not incidental output — they contain reasoning chains, decision points, and trade-off analyses that directly inform the developer's next action. When developers must spend cognitive effort decoding the language rather than evaluating the reasoning, productivity drops substantially.

This is not an issue of English proficiency. Many non-English developers are comfortable with English UIs, documentation, and error messages (short, predictable, pattern-based text). However, continuously reading large volumes of novel, dense reasoning text in a non-native language is a fundamentally different cognitive task.

Proposed Solution

Add a thinking_language parameter to the Messages API that allows users to specify the preferred language for extended thinking output.

API level

adaptive mode (recommended for Opus 4.6)

{
  "thinking": {
    "type": "adaptive",
    "language": "ja"
  }
}

enabled mode

{
  "thinking": {
    "type": "enabled",
    "budget_tokens": 10000,
    "language": "ja"
  }
}

Claude Code level

Add a thinkingLanguage setting in settings.json:

{
  "thinkingLanguage": "ja"
}

This should be an opt-in parameter. If not specified, the current behavior (English) is preserved. This allows users to make an informed trade-off between potential reasoning accuracy and readability.

Alternative Solutions

1. Telling the model "think in Japanese" at the start of each conversation works, but resets after context compaction and requires manual repetition every session.

1. Adding language instructions to CLAUDE.md affects the final output but has minimal effect on thinking blocks, as the model's training pattern dominates.

1. Disabling extended thinking and using XML-based chain-of-thought (<thinking> tags) allows language control but sacrifices the benefits of extended thinking entirely.

None of these are satisfactory long-term solutions.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

Example scenario:

1. A Japanese developer is working on a complex refactoring task using Claude Code with verbose output enabled
2. Claude generates extended thinking blocks analyzing the codebase architecture, evaluating multiple approaches, and making design decisions
3. The thinking content is entirely in English — the developer must carefully read each reasoning step to verify Claude's approach before approving changes
4. With thinking_language: "ja", the same reasoning is output in Japanese — the developer can quickly scan the thinking blocks, identify key decision points, and make informed approvals in seconds rather than minutes
5. Over a full day of pair programming, the cumulative cognitive savings are substantial

Note: For code-related reasoning specifically, the language of thinking has minimal impact on accuracy since the subject matter (variable names, function signatures, API specs, logic flow) is language-agnostic. The "Extended thinking performs best in English" guideline is most relevant for tasks where cultural/linguistic context affects reasoning quality.

Additional Context

• Regression: This behavior changed between Opus 4.5 (thinking followed conversation language) and Opus 4.6 (thinking defaults to English regardless of settings). Furthermore, even with Opus 4.6, explicitly telling the model "think in Japanese" during conversation still works — the model retains the capability for non-English thinking, but configuration-based language settings no longer reach the thinking layer. This is not a loss of capability but a loss of controllability.
• Scope: This is ultimately a model-level behavior, but the Claude Code settings layer and API parameter are the user-facing surfaces where the control should be exposed.