Claude Codeでmax effortの3.5倍警告が繰り返し出るときの対処
Max effortで「3.5×以上の使用量」警告が何度も出る報告の状況と、いま取れる回避策をまとめます。effortまわりの設定に警告を消す項目は無く、effortを下げるのが現実的です。
Opus 5.5をmax effortで使っていると、入力欄の上に「Claude thinks longer with Max effort and can consume 3.5× or more usage than Medium.」という帯が出ます。閉じても戻ってくる、という報告がclaude-codeリポジトリのissue #100278に集まっています。
結論から書くと、この警告だけを止める設定は、effortまわりのドキュメントに載っていません。使える手は、effortの水準を下げるか、max を選べないように上限を張るかの2つです。
警告はどこに出て、何が起きているのか
問題の文言は、issueのタイトルでは「Claude thinks longer with Max error and can consume 3.5 or more usage than medium.」と書かれています。コメントで引用された正確な文面は、先頭の英文のとおりです。
issueは2026年10月7日に起票され、ラベルは bug / platform:windows / area:tui / user-experience です。報告者の環境は次の通りです。
- 起票者: Windows 11、Opus 5.5をMaxで数分使うと、約2分おきに入力欄の上へ通知が出る
- 追記1: WindowsのClaudeデスクトップアプリ（Codeタブ）で、セッションごとに帯が出る。Xで閉じても戻る
- 追記2: macOSのデスクトップアプリ（Codeタブ）でも同じ症状が出る
コメントを読むと、「2分おき」の正体は時間ではなく再表示の条件にあるようです。追記1の報告では、帯を閉じたあと別セッションへ移って戻るだけで、同じセッションでも帯が復活します。セッションを頻繁に行き来する使い方だと、数分おきに見えることになります。
つまり症状は「警告が出る」ことより、「閉じた状態が保持されない」ことです。
デスクトップアプリ側の表示である可能性が高い
issueのコメントには、症状の出る場所を絞る材料が3つあります。
- 追記の報告者がいずれもデスクトップアプリのCodeタブで確認している
- 別のissue（#100676）に、帯は
max-effort-warning-bandという名前で、閉じた状態がメモリ上にだけ保持されるらしい、という解析が書かれている - macOSの報告者が、帯はデスクトップアプリ自身の画面部品で描かれており、Claude Codeのプラグインやmodからは隠せない、と述べている
ただし、2と3は利用者が配布物から読み取った推測で、Anthropicからの確認ではありません。issueにはAnthropic側の返信も修正バージョンも付いておらず、状態はopenです。
一方で、起票者のプラットフォーム欄はターミナルの記載（Terminal.app）もあり、CLI側でも出るのかはissueから切り分けられません。ターミナルの claude で同じ帯を見た場合は、バージョンと環境を添えてissueへ報告すると切り分けが進みます。
同じmodel・effortのセッションだけを使うと再表示は減るか
#100676の解析が正しければ、閉じた状態はサーフェス（Codeタブなどの画面種別）、model、effortの組をキーにメモリー上だけで持たれます。別のmodelやeffortの入力欄が開いた時点でその記録は消えるので、再起動のたびに戻るのも、セッション切り替えで戻るのも同じ仕組みで説明がつきます。
この解析を前提にすると、次の推測が立ちます。デスクトップアプリで、同じmodel・同じeffortのセッションだけを行き来すれば、別の組の入力欄が開かない分だけ再表示は減るかもしれません。ただし、これは配布物を読んだ利用者の解析から導いた推測で、動作として確かめられた手順ではありません。アプリを再起動すればメモリーごと消えるため、再起動をまたぐ効果は期待できません。
警告だけを消す設定キーは用意されていない
model-configのeffort節、settings-referenceの effortLevel / maxEffortLevel / modelSettings の項には、この警告を扱う記述がありません。「今後表示しない」設定も、環境変数もありません。issueのコメントでも、利用者が求めているのは「閉じた状態の保存」か「無効化の設定」で、どちらも現状は要望です。
そのため、現実的な対処は帯の原因であるmaxを使わない、または使う場面を絞ることになります。
対処1: effortをmax以外にする
max はセッション限りの設定です。環境変数 CLAUDE_CODE_EFFORT_LEVEL で指定した場合を除き、Claude Codeは max を現在のセッションにだけ適用し、次回の既定値としては保存しません。設定ファイルの effortLevel や modelSettings にも max は書けません。
つまり、新しいセッションを開くたびに、/effort で max を選び直している場合は、その選び直しが帯を呼び戻している可能性があります。
水準は次の順で下げられます。
| 水準 | ドキュメント上の位置づけ |
|---|---|
xhigh | ドキュメント上の位置づけより深い推論を、より多いトークンで行う水準 |
high | ドキュメント上の位置づけ検証が重要な作業や、エッジケースが出やすい作業向け |
medium | ドキュメント上の位置づけOpus 5.5・Sonnet 5.5・Haiku 5.5の既定値 |
Opus 5.5は何も指定しなければ medium で始まります。ドキュメントは max について、収穫逓減になりやすく考えすぎの傾向もあるため、広く採用する前に試すよう書いています。
デスクトップアプリでは Cmd Shift E でeffortのメニューが開きます。ターミナルでは /effort でスライダーを開くか、/effort xhigh のように水準名を直接指定します。
/effort xhighOpus 5.5などでは、セッション途中でeffortを変えてもプロンプトキャッシュは保たれます。確認なしで次のリクエストから新しい水準が適用されるので、途中で max から xhigh に落としても、履歴の再計算コストは増えません。この挙動はAPIキーまたはClaudeのサブスクリプションで使う場合で、次の場合は対象外で、変更すると履歴を読み直すことになります。
- Amazon Bedrock、Google CloudのAgent Platform、Claude apps gatewayを経由している
- 環境変数
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETASを設定している - 組織がHIPAA構成になっている
キャッシュを保つ対象にはFable 5.1も含まれます。ただしv2.1.260より前では、Fable 5.1でもeffortの変更でキャッシュが無効になっていました。古いClaude Codeを使っている場合は、maxから下げる操作が履歴の再計算につながる点に注意してください。
対処2: maxEffortLevelでmaxを選べなくする
自分で max に上げてしまうのを防ぎたい場合や、チームで上限をそろえたい場合は maxEffortLevel が使えます。指定した水準より上は、/effort や --effort で選んでもその水準で動きます。Claude Code v2.1.267以降が必要です。
{
"maxEffortLevel": "xhigh"
}この設定は、モデルごとにも書けます。modelSettings の該当モデルのエントリーに入れると、そのモデルだけ上限が変わります。書き方はmodelSettingsのeffortをモデル別に直接編集する方法にまとめています。
注意点が2つあります。"max" を指定すると上限なしの扱いになり、何も制限されません。また、この設定はターミナルのClaude Codeが読む設定ファイルの話です。デスクトップアプリの帯が、この上限で消えるかどうかはドキュメントに記載がありません。上限を張ったあとで帯が出なくなったかは、手元で確かめてください。
対処3: 深く考えさせたいターンだけultrathinkを使う
セッション全体を max にしなくても、1ターンだけ深い推論を頼む手段があります。プロンプトのどこかに ultrathink を含めると、そのターンだけ追加の指示が入ります。APIに送られるeffortの水準は変わらず、セッションの設定にも触りません。
この関数の競合状態を洗い出してください。ultrathinkthink や think hard などの語は、通常のプロンプトの文字列として扱われ、キーワードとしては認識されません。ultrathink はeffortの水準を上げる操作ではないので、max用の警告の対象かどうかは分かりません。帯が出なければ、普段は medium や high で走らせ、必要なターンだけ ultrathink を足す使い方に置き換えられます。
どのくらい下げると使用量が変わるか
帯の文言は、maxがmediumの3.5倍以上の使用量になりうる、と読めます。この倍率が何を基準にした数値なのかは、issueにもドキュメントにも説明がありません。数字そのものは目安として受け取る程度にとどめてください。
手元の消費を確かめるなら、同じ作業を水準を変えて走らせ、使用量を比べるのが確実です。ローカルの記録からトークンとコストを集計する方法はccusageの記事、/usage でループごとの内訳を見る方法はLoopの内訳の記事にあります。水準ごとの効き方の比較はTerminal-Bench 3.0で見るeffortの効き方が参考になります。
帯が出るときの切り分け早見表
| 状況 | 取れる手 |
|---|---|
| デスクトップアプリでmaxを使い続けたい | 取れる手帯は閉じて待つ。警告を恒久的に消す設定は無いので、issueに反応を付けて要望を伝える。同じmodel・effortのセッション内に留めると再表示が減る可能性がある（推測） |
| maxは特に必要ない | 取れる手/effort xhigh か medium に下げる |
| 誤ってmaxに上げたくない | 取れる手maxEffortLevel を xhigh などに設定する |
| 1ターンだけ深く考えさせたい | 取れる手プロンプトに ultrathink を入れる |
| ターミナルで同じ帯が出る | 取れる手バージョンと環境を添えてissueに報告する |
修正を待つ間の見方
issueを追う場合は、#100278と、帯の閉じた状態を保存する案を挙げた #100676の2本を見ると、対応が入った時点がつかめます。いずれも利用者の報告が中心で、Anthropicのコメントは付いていません。
修正が入るまでは、maxを常用するか、使う場面を絞るかの選択になります。深い推論が効く作業は、障害調査や設計判断のように範囲が限られます。ドキュメントでは、範囲の明確な日常の実装は medium、検証が重要な作業は high が目安とされています。帯を機に水準の使い分けを見直す手があります。Opus 5.5とSonnet 5.5の水準ごとの違いはOpus 5.5とSonnet 5.5の違いで比較しています。