output_config.effort xhighが400エラーになる条件と修正済みバージョン
Claude Codeでeffort xhigh指定時にthinkingが無効だと400エラーになる条件をissue #76689の調査から整理し、修正済みバージョンと当時の回避策をまとめる。
"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移行ガイドが明記する正規の仕様です。Opus 5移行ガイドは次の破壊的変更を挙げています。
Disabling thinking is capped at
higheffort: You can still turn thinking off withthinking: {type: "disabled"}, but only at an effort level ofhighor below. A request that combinesthinking: {type: "disabled"}with effortxhighormaxreturns a 400 error. Claude Opus 4.8 accepts this combination, so audit requests that disable thinking before you migrate.
要するに、Opus 4.8まではthinking無効とeffort xhigh/maxを同時に指定できましたが、Opus 5ではこの組み合わせ自体が拒否されるようになりました。検証はリクエストごとに独立して行われるため、同じ会話の途中でも条件を満たさなければ毎回400になります。
ただし、issue #76689の初報はこの仕様変更前のOpus 4.8(2.1.205〜207)で起きています。移行ガイドはOpus 4.8がこの組み合わせを許可すると明記しており、初報のバージョン・モデルと仕様書の記述はその点で食い違ったままです。原因がクライアント側の別の不具合なのか、Opus 4.8の実際の挙動が移行ガイドの記述と異なる場面があったのかは、issue上でも明確には切り分けられていません。
| モデル | thinking無効 × effort xhigh/max |
|---|---|
| Claude Opus 4.8 | thinking無効 × effort xhigh/max許可(旧仕様) |
| Claude Opus 5 | thinking無効 × effort xhigh/max拒否(400エラー) |
| Claude Sonnet 5 | thinking無効 × effort xhigh/max許可(effortに関係なく無効化できる) |
effortの公式ドキュメントも同じ制約を「On Claude Opus 5, thinking cannot be disabled at xhigh or max effort」と記載しており、Opus 5固有の制約であってSonnet 5には及びません。effortレベル自体の使い分けはClaude effortの使い分けガイドで扱っています。
Claude Code側のどこが無効な組み合わせを作っていたか
仕様自体は正しくても、ユーザーが明示的にthinkingを無効化していないのに400になるなら、原因はクライアント側にあります。issueのコメント欄では、少なくとも2つの経路が特定されました。
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だけを変えて再現しています。
| 手順 | 状態 | WebSearchの結果 |
|---|---|---|
| 1 | 状態セッションのeffortをxhighのまま呼び出し | WebSearchの結果400エラー |
| 2 | 状態frontmatterでeffort: highのスキルを読み込む | WebSearchの結果― |
| 3 | 状態読み込み後、同じクエリで再実行 | WebSearchの結果成功 |
再起動もモデル変更も無く、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つの情報源が食い違う状態を記録しています。
| 確認箇所 | 内容 |
|---|---|
/configのThinking mode表示 | 内容true |
設定ファイル(settings.jsonなど) | 内容alwaysThinkingEnabledキー自体が存在しない |
| APIのエラー応答 | 内容thinking is disabled |
alwaysThinkingEnabledキーが設定ファイルに存在しないこと自体は、thinkingが無効化されている証拠にはなりません。それでもこの報告では、APIは無効として扱ったリクエストを送っていました。報告者は~/.claude.jsonのthinkingMigrationComplete: trueという別のフラグが関係している可能性を挙げていますが、これは検証されていない仮説として提示されており、断定はできません。
修正が入った3つのバージョン — v2.1.221・v2.1.243・v2.1.251
この不具合への対応は1回のパッチではなく、3つのバージョンに分かれて入りました。
| バージョン | 公開日 | 内容 |
|---|---|---|
| v2.1.221 | 公開日2026-08-04 | 内容thinking無効時のeffort xhigh/maxでWebSearchが400になる不具合を修正 |
| v2.1.243 | 公開日2026-08-25 | 内容エラーメッセージを改善(レベル名・原因の設定・/effort highという対処法を明示) |
| v2.1.251 | 公開日2026-08-28 | 内容メインループでeffort xhigh/max×thinking無効になった場合、effortを自動でhighに落として送信するよう修正 |
WebSearchのサブリクエストとメインループのeffort解決は、issue内のコメントで別経路として組まれていることが特定されており、修正もその経路ごとに入っています。v2.1.221がWebSearch側の無効な組み合わせを止めても、メインループ側の解決処理は変わらないままで、v2.1.251まで残っていました。
まとめ — このエラーに遭遇したときに確認すること
このエラーを今見かけたら、まずバージョンを確認します。
claude --versionv2.1.251より古い場合は更新すれば、メインループとWebSearchの両方でこの400を回避できます。更新できない事情がある場合、issueで確認された回避策は次の2つです。
- セッション全体のeffortはそのままに、WebSearchを呼ぶスキルやサブエージェントのfrontmatterにだけ
effort: highを指定する /configでThinking modeがオフになっていないか確認し、オンに戻すか/effortをhigh以下へ下げる
/effort high更新後もeffort xhighとthinking: {type: "disabled"}を意図的に組み合わせたい場合、Opus 5ではその組み合わせ自体が仕様として拒否される点は変わりません。Fable 5・Mythos 5系で発生するthinking無効化そのものの拒否については、「thinking.type.disabled」エラーの解説記事を参照してください。Claude Code側のthinkingパラメーター周りでは「thinking.type.enabled」が拒否される別の不具合も報告されており、エラー文言が似ているため切り分けの際は文面を確認することをおすすめします。