output_config.effort xhighが400エラーになる条件と修正済みバージョン

"output_config.effort 'xhigh' is not supported when thinking is disabled"とは何のエラーか

Claude Codeでeffortをxhighにした状態でリクエストを送ると、次の400エラーが返ることがあります。

API Error: 400 output_config.effort 'xhigh' is not supported when thinking is disabled on this model. Use effort 'high' or below, or enable thinking.

このエラーはGitHub issue #76689で2026年7月11日に報告されました。初報の環境はVS Code版Claude Code 2.1.205〜2.1.207・Claude Opus 4.8で、報告者はalwaysThinkingEnabled: trueをsettings.jsonに設定済みでした。thinkingを有効にしているはずなのに、リクエストは「thinkingが無効」として拒否されていました。同じissue内では、CLI版2.1.219・Opus 5でも同じエラーが100%の確率で再現したという報告があります。

このエラーはClaude Fable 5・Mythos 5系で起きる「thinking.type.disabled」エラーとは別物です。あちらは常時thinkingのモデルに無効化リクエストそのものを送ったときの拒否で、モデル区分の問題です。今回のエラーはOpus 5・Opus 4.8のようにthinkingを選べるモデルで、特定のリクエストだけthinking無効のまま送られてしまう、Claude Code側の組み立てに起因する症状です。

結論から言うと、この不具合はClaude Code v2.1.221とv2.1.251で修正済みです。以下で条件を整理し、当時の回避策と現在確認すべきことをまとめます。

Opus 5は「thinking無効はeffort high以下」に仕様が変わった

このエラー自体は、Opus 5の正規の仕様です。公式のthinkingトラブルシューティングは、Opus 5の制約を表の注として次のように記しています。

Claude Opus 5 accepts "disabled" at effort high or below; combining it with effort xhigh or max returns a 400 error. This restriction is enforced on each request.

Opus 4.8まではthinking無効とeffort xhigh/maxを同時に指定でき、Opus 5ではこの組み合わせ自体が拒否されるようになりました。検証はリクエストごとに独立して行われるため、同じ会話の途中でも条件を満たさなければ毎回400になります。

ただし、issue #76689の初報はこの制約が入る前のOpus 4.8(2.1.205〜207)で起きています。公式の表でもOpus 4.8が拒否するのはenabledだけで、disabledとxhigh/maxの組み合わせは対象外です。初報の環境と仕様書の記述はこの点で食い違ったままで、原因がクライアント側の別の不具合なのか、Opus 4.8の実際の挙動が仕様書と異なる場面があったのかは、issue上でも切り分けられていません。このissueはクローズされておらず、openのままです。

effortの公式ドキュメントも同じ制約を「On Claude Opus 5, thinking cannot be disabled at xhigh or max effort」と記載しており、Opus 5固有の制約であってSonnet 5には及びません。Opus 5.5とSonnet 5.5は別の仕様です。disabledそのものが、effortを問わず400になります。effortレベル自体の使い分けはClaude effortの使い分けガイドで扱っています。

Claude Code側のどこが無効な組み合わせを作っていたか

仕様自体は正しくても、ユーザーが明示的にthinkingを無効化していないのに400になるなら、原因はクライアント側にあります。issueのコメント欄では、少なくとも2つの経路が指摘されています。以下はコメント投稿者によるコード読解で、Anthropicの原因説明ではありません。

WebSearchなどサーバー側ツールのサブリクエストは、thinkingConfig: { type: "disabled" }をハードコードしたまま、effortValueだけをセッションの設定(xhigh)から無条件に引き継いでいました。ユーザーのメインループがthinkingを有効にしていても、WebSearchの裏側では常に無効な組み合わせのリクエストが組まれていたことになります。エラーはツール結果の中に埋め込まれて返るため、isApiErrorMessageのようなフラグに現れず、リサーチ用エージェントは検索1系統が丸ごと欠けたまま処理を続けていました。あるコメントはこの実害を「Tier 3: not collected — WebSearch tool API error (effort setting), fully unavailable this session」と記録しています。

メインループ側では、セッション内のappState.thinkingEnabledがTabキーのトグルや/config操作で切り替わり、settings.jsonとは独立に管理されていました。この状態は新しいセッションを開始するまで設定ファイルと同期されないため、/config表示は「thinking mode: true」のままでも、実際に送られるリクエストはdisabledになり得ました。

もう一つの要因は、既存の再試行機構(tengu_effort_unsupported_retry)が新しいエラー文言にマッチしなかったことです。旧来のマッチャーは"extra inputs are not permitted"のような文字列を探していたため、Opus 5の新しいエラー文には反応せず、400がそのままユーザーに届いていました。

自分のログでこの400を見つけにくい理由

WebSearchが原因だと指摘したコメントは、同じセッション・同じクエリ文字列・30秒差という条件でeffortだけを変えて再現しています。

再起動もモデル変更も無く、effortの値だけが変数でした。この結果は、WebSearchのサブリクエストがセッションの現在のeffort値をそのまま引き継ぎつつ、thinkingは無効固定で送っていたことを裏付けています。

厄介なのは、この失敗がセッションのトランスクリプトから見つけにくい点です。最初の報告者は"isApiErrorMessage":trueのフラグとisSidechain:false(メインループ)だけを条件にログを検索し、「サブエージェントでは起きていない」と結論していました。しかし別のユーザーが指摘したとおり、WebSearch経由の失敗はツール結果の本文に埋め込まれるだけでisApiErrorMessageが立たず、しかもサブエージェントのトランスクリプトは~/.claude/projects/<proj>/<session-id>/subagents/という1段深いパスに保存されるため、浅いglobパターンでは検索対象に入りません。別のユーザーが自分のトランスクリプトを走査したところ、27件中25件がisApiErrorMessage: nullだったという報告もあり、フラグだけに頼った集計は実際の発生件数を大きく下回ります。

もう一つの報告は、/configの表示・設定ファイルの中身・APIの応答という3つの情報源が食い違う状態を記録しています。

alwaysThinkingEnabledキーが設定ファイルに存在しないこと自体は、thinkingが無効化されている証拠にはなりません。それでもこの報告では、APIは無効として扱ったリクエストを送っていました。報告者は~/.claude.jsonのthinkingMigrationComplete: trueという別のフラグが関係している可能性を挙げていますが、これは検証されていない仮説として提示されており、断定はできません。

修正が入ったバージョンの経緯 — v2.1.221からv2.1.282まで

この不具合への対応は1回のパッチでは終わらず、4つのバージョンに分かれて入りました。

WebSearchのサブリクエストとメインループは、issueのコメントでは別経路として説明されています。changelogでも、WebSearch側の修正はv2.1.221、メインループ側にあたる修正はv2.1.251と、別のバージョンに載っています。

v2.1.282の修正は、同じ組み合わせが別の場面で出たものです。このとき出るのは、APIの文言ではありません。Claude Code自身の「Effort 'xhigh' isn't available with thinking turned off」というメッセージです。モデル切り替えの直後に出た場合は、output_configではなくこちらの文面を手がかりに探すことになります。

v2.1.289で確かめるeffortの値と手元のバージョン

effortの指定そのものは、claude --helpから確認できます。v2.1.289では次の表示でした。

claude --help | grep -A1 -e "--effort"

  --effort <level>                      Effort level for the current session
                                        (low, medium, high, xhigh, max)

存在しない値を渡したときの挙動も、--versionと組み合わせればモデルを呼ばずに確かめられます。

claude --effort bogus --version

Warning: Unknown --effort value 'bogus' — ignoring it and using the default effort. Valid values: low, medium, high, xhigh, max.
2.1.289 (Claude Code)

未知の値は400にならず、警告を出して既定のeffortに戻ります。一方、有効な値でもモデルが対応していなければ、Claude Codeは対応する最も高いレベルまで落として使います(Opus 4.6ではxhighがhighとして動きます)。今回の400は、モデルがxhigh/maxを受け付けるのに、thinkingの無効化とぶつかったときの拒否で、これらとは別物です。

まとめ — 見かけたらバージョン、effort、thinkingの順に切り分ける

claude --version

/effort high

更新後もeffort xhighとthinking: {type: "disabled"}を意図的に組み合わせたい場合、Opus 5ではその組み合わせ自体が仕様として拒否されます。Fable 5・Mythos 5系で発生するthinking無効化そのものの拒否については、「thinking.type.disabled」エラーの解説記事を参照してください。Claude Code側のthinkingパラメーター周りでは「thinking.type.enabled」が拒否される別の不具合も報告されており、エラー文言が似ているため切り分けの際は文面を確認することをおすすめします。