effort cannot change when thinking is disabledの400エラーと直し方
Sonnet 5.5のbetween_toolsやHaiku 5.5のdisabledで、メッセージ単位のeffortを変えると返る400エラー。messages.Nの意味と3つの直し方を示します。
Claude APIで次のメッセージが返ったら、原因は「thinkingを止めたまま、会話の途中でeffortを変えようとした」ことです。
messages.N: output_config.effort 'low' differs from the 'high' in effect before it; effort cannot change when thinking is disabled on this model. Use effort 'high', or enable thinking.このエラーが出るのは2つの組み合わせだけです。Claude Sonnet 5.5でthinking: {"type": "between_tools"}を使っているとき、またはClaude Haiku 5.5でthinking: {"type": "disabled"}を使っているとき。どちらもメッセージ単位のoutput_config.effortが、その時点で有効なeffortと違う値になった瞬間に400で落ちます。
直し方は3つあります。per-message effortを外す、いま有効な値に揃える、thinkingを省いてadaptiveに戻す。
このエラーが出る条件
エラー文の「thinking is disabled」は、リクエストに"disabled"を送ったという意味とは限りません。Sonnet 5.5のbetween_toolsは最初にまとめて考える段階を持たないため、メッセージ上は「disabled」と表現されます。
| モデル | 送っているthinking | 引っかかる操作 |
|---|---|---|
| Claude Sonnet 5.5 | 送っているthinking{"type": "between_tools"} | 引っかかる操作メッセージ単位のeffortが、有効なレベルと違う |
| Claude Haiku 5.5 | 送っているthinking{"type": "disabled"} | 引っかかる操作同上 |
Sonnet 5.5は"disabled"そのものを400で拒否するモデルです。thinkingを止めたい場合の入口がbetween_toolsなので、Sonnet 5.5でこのエラーに出会う人は実質between_tools利用者です。ツール呼び出しの合間の短い進捗メモは、thinkingブロックとして返り続けます。
逆に、同じSonnet 5.5でもthinkingを省くかadaptiveにしていれば、メッセージ単位のeffort変更は通ります。Opus 5.5やFable 5.1などの対応モデルも同様です。
messages.Nは何を指すのか
エラー文のmessages.Nは、新しいeffortを設定したメッセージの位置です。messages配列の先頭を0として数えた添字なので、そこが犯人のrole: "system"メッセージになります。
メッセージ単位のeffortは、contentが空のsystemメッセージにoutput_config.effortを載せる形で送ります。betaヘッダーmid-conversation-output-config-2026-07-01が必要です。次のリクエストは、トップレベルがhighのままmessagesの途中でlowに下げているため、between_toolsと組み合わせると失敗します。
{
"model": "claude-sonnet-5-5",
"max_tokens": 4096,
"thinking": {"type": "between_tools"},
"output_config": {"effort": "high"},
"messages": [
{"role": "user", "content": "移行計画を3ステップで書いてください。"},
{"role": "assistant", "content": "1. データを書き出す。2. スキーマを作る。3. 取り込んで検証する。"},
{"role": "system", "content": [], "output_config": {"effort": "low"}},
{"role": "user", "content": "計画を一文に要約してください。"}
]
}これは公式のeffortページのメッセージ単位の例を、Sonnet 5.5とbetween_toolsの組み合わせに置き換えた形です。この例なら添字は2なので、エラー文はmessages.2: ...の形で返ると読めます。
エラー文の'low' differs from the 'high' in effect before itは、前者が新しく送った値、後者が直前まで有効だった値です。数値の添字が大きい長い会話では、どのsystemメッセージが原因か探すときの手がかりになります。
直し方は3つ
エラーを消す3つの手
- 1
メッセージ単位のeffortを外す
該当の
systemメッセージを削除します。effortはトップレベルの値のまま変わらず、between_toolsも維持できます。 - 2
有効なレベルと同じ値にする
エラー文の末尾にあるとおり、いま有効なレベル(上の例なら
high)をそのまま指定します。値が変わらなければ拒否されません。 - 3
thinkingを省いてadaptiveに戻す
effortを可変にしたい場合の正規ルートです。
thinkingフィールドを省くか{"type": "adaptive"}を送ります。エラー文の「enable thinking」はこの操作を指します。
Sonnet 5.5は"enabled"を400で拒否するため、「enable thinking」を{"type": "enabled"}と読んではいけません。Haiku 5.5も同じ文言で、thinkingをadaptiveにすればターンごとにeffortを変えられます。
3つ目を選ぶ場合は、between_toolsの利点を手放すことになります。Sonnet 5.5のthinkingはもともと既定でオンのモデルで、between_toolsは最初の思考を省くための低い設定です。ターンごとにeffortを動かしたいなら、思考の入口はadaptiveに任せ、深さをlow〜maxで調整するほうが設計として噛み合います。
どんな実装で踏みやすいか
このエラーを踏むのは、たいてい次のようなパイプラインです。
- ルーティング層が「簡単な質問は
low、調査はhigh」とターンごとにeffortを切り替える - コスト削減のため
between_toolsを試したあとも、切り替えコードをそのまま残した - Opus 5.5やFable 5.1向けに書いたeffort切り替えのクライアントを、Sonnet 5.5に差し替えた
3つ目は移行時に起きやすい型です。モデルIDだけを変えても、thinkingの指定がbetween_toolsのままだと、同じコードがSonnet 5.5でだけ400になります。移行の全体像はClaudeモデルの移行ガイドにまとめています。
Haiku 5.5では別の条件も重なる
Haiku 5.5のdisabledは、effortまわりで制約が2つあります。どちらも400ですが、原因が違います。
disabledをxhighかmaxのeffortで送る: 「effort level is not supported when thinking is disabled」型のエラー。high以下に下げるdisabledのまま、メッセージ単位のeffortを有効なレベルと違う値にする: 本記事のエラー。adaptiveにするか値を揃える
前者はリクエスト全体の組み合わせの問題で、後者は会話の途中で値が動いたことの問題です。Opus 5もdisabledをhigh以下に限って受け付けますが、公式のトラブルシューティングページで「メッセージ単位のeffortが違うと400」と明記されているのはHaiku 5.5とSonnet 5.5です。Opus 5では、制約はリクエストごとに判定されると書かれています。
エラー文のUse effort 'high', or enable thinking.の'high'には、そのとき有効なレベルが入ります。公式の例ではトップレベルのhighがそのまま入っており、文面の値が揃えるべきレベルを示します。
似た名前のエラーとの見分け方
Sonnet 5.5のbetween_toolsには、同じ「thinking is disabled」を含む別のエラーもあります。違いは「何を変えたか」です。
| メッセージの特徴 | 原因 | 直し方 |
|---|---|---|
output_config.effort 'xhigh' is not supported when thinking is disabled on this model | 原因between_toolsをxhighかmaxで送った | 直し方effortをhigh以下にするか、adaptiveにする |
effort cannot change when thinking is disabled on this model(先頭にmessages.N:) | 原因メッセージ単位のeffortが有効なレベルと違う | 直し方本記事の3手 |
messages.N.output_config: Extra inputs are not permitted | 原因betaヘッダーを付けずにsystemメッセージのeffortを送った | 直し方mid-conversation-output-config-2026-07-01を付ける |
output_config.effort requires a model that supports per-turn effort; this model does not | 原因betaヘッダーはあるが、モデルがメッセージ単位のeffortに未対応 | 直し方対応モデルに替えるか、トップレベルのeffortで運用する |
最初の行はxhighやmaxの単純な指定ミスで、会話の途中かどうかは関係しません。xhighが400になる条件はClaude Code側の話も含め、output_config.effort xhighが400エラーになる条件で扱っています。
そもそもeffortを変えてもthinkingの深さが変わらない、という別の症状は、effortを変えてもthinkingの深さが変わらないときの原因切り分けが受けます。
プラットフォームとキャッシュの注意
メッセージ単位のeffortはベータ機能です。Claude APIとGoogle managedのClaude Models on Google Cloudでは、Sonnet 5.5とHaiku 5.5を含む6モデルで使えます。Amazon Bedrockの対応モデルとして挙げられているのはFable 5.1、Mythos 5.1、Opus 5.5で、Sonnet 5.5とHaiku 5.5は一覧にありません。
つまりBedrock経由でSonnet 5.5を使っている場合、そもそもメッセージ単位のeffortを送る前提が成り立ちません。そのときのエラーは本記事のものではなくExtra inputs are not permittedになります。
キャッシュにも違いがあります。メッセージ単位のeffortは、それまでのメッセージを書き換えないため、キャッシュされたプレフィックスが一致し続けます。一方、トップレベルのoutput_config.effortを次のリクエストで変えると、プレフィックスが変わりキャッシュが作り直されます。
effortを変える2つの方法
メッセージ単位(beta)
between_toolsやdisabledのままでは使えません。adaptiveにすれば使えます。
トップレベルを次のリクエストで変更
どのモデルでも使えます。ただしbetween_toolsでトップレベルを変えた場合の挙動は、公式のトラブルシューティングページに記載がありません。
キャッシュ全般が崩れる条件は、Claude APIのキャッシュが壊れる変更は、compactionの直後に入れるも参考になります。
再発を防ぐための事前チェック
エラーが出てから直すより、リクエストを作る側で弾くほうが運用は安定します。thinking設定がeffortの可変性を決めるので、次の順に確認します。
- 使うモデルがSonnet 5.5か、Haiku 5.5か
thinkingがbetween_tools(Sonnet 5.5)またはdisabled(Haiku 5.5)か- 該当するなら、
messagesの中にoutput_configを持つsystemメッセージを入れていないか - 入れるなら、その値がトップレベル(または直前のメッセージ単位)のeffortと同じか
モデルがdisabledやbetween_toolsを受け付けるかは、Models APIのcapabilities.thinking.types.disabled.supportedとcapabilities.thinking.types.between_tools.supportedで、リクエストを送る前に読めます。モデル別のthinking値の対応はExtended thinkingとAdaptive thinkingの違いの表が一覧です。
Opus 5.5でthinking disabledが400になる件は別の問題で、Opus 5.5のthinking disabledは400エラーに移行手順があります。
まとめ
このエラーは、effortが固定の設定とeffortを動かす設定を同じリクエストに入れたことで起きます。Sonnet 5.5のbetween_toolsとHaiku 5.5のdisabledは前者に属します。ターンごとにeffortを動かす設計なら、思考設定の側をadaptiveに寄せるのが筋で、between_toolsを残したいなら、effortは最初に決めた値から動かさない運用になります。