Claude Opus 5.5のthinkingと出力が10月1日から増えた報告
10月1日を境にOpus 5.5のthinkingが約2倍、出力が約1.6倍になったという報告がclaude-codeリポジトリに出ています。数値の中身と、effortで消費を抑える設定をまとめます。
Opus 5.5のthinkingが約2倍、出力が約1.6倍に増えたという報告が、claude-codeリポジトリのissue #98679に出ています。起票は2026年10月1日で、10月10日時点でもopenのままです。同じissueには、増えたのは出力量だけでなく判断の質も落ちたという複数の報告が続いています。Anthropicからの公式な説明は、issueには付いていません。
このissueの数値は、報告者自身のセッション記録から出した集計です。原因は特定されておらず、報告ごとに食い違う点もあります。ここでは何が測られたのか、どこまで言えるのかを順に見たうえで、手元でできる対処としてeffortの設定を扱います。
報告された数値は何を測ったのか
報告者は、~/.claude/projectsのトランスクリプトからセッションごとの指標を抜き出しました。内容は含まず、トークン数だけを使っています。対象は20リクエスト以上のセッションです。effortはすべて明示のhighで、CLAUDE.md・skills・hooksは変えていないとされています。
| 期間とモデル | セッション数 | thinkingトークン中央値/リクエスト | thinkingなしの割合 | 出力トークン中央値/リクエスト |
|---|---|---|---|---|
| Opus 5(9月4〜22日) | セッション数64 | thinkingトークン中央値/リクエスト47 | thinkingなしの割合0.41 | 出力トークン中央値/リクエスト417 |
| Opus 5.5(9月23〜30日、CLI 2.1.282〜2.1.285) | セッション数29 | thinkingトークン中央値/リクエスト67 | thinkingなしの割合0.37 | 出力トークン中央値/リクエスト447 |
| Opus 5.5(10月1日、CLI 2.1.286) | セッション数8 | thinkingトークン中央値/リクエスト126 | thinkingなしの割合0.29 | 出力トークン中央値/リクエスト711 |
9月23〜30日と10月1日の比較で、3指標ともp < 0.003 (Mann-Whitney U検定)と書かれています。表の数字から計算すると、thinkingは67から126で約1.9倍、出力は447から711で約1.6倍です。issueタイトルの「約2倍」は、9月23〜30日のOpus 5.5と比べた丸めた表現として読めます。
比較の基準を変えると倍率も変わります。Opus 5(9月4〜22日)と10月1日を比べると、thinkingは47から126で約2.7倍、出力は417から711で約1.7倍です。9月23〜30日のOpus 5.5がすでにOpus 5よりthinkingで約1.4倍(47から67)、出力で約1.1倍(417から447)だったため、基準がOpus 5だとthinkingの増え方は大きく見えます。「何倍になったか」は、どの期間を基準にしたかで読み方が変わる数字です。
注意したいのは、10月1日のセッションが8本しかないことです。しかもその日のセッションは全部CLI 2.1.286で動いていたため、日付とCLIのバージョンを切り分けられません。報告者自身も、データ上は両者が一致していると書いています。
ほかの報告者の数字は揃っていない
issueにはコメントが6件付いており、同じ現象を見たという報告が中心です。数字は報告ごとに違います。
出力量が増えなかったという報告もあります。コメントした1人は、クライアントが2.1.284のままで、リクエストあたりの出力トークンは日ごとの通常の範囲に収まったと書いています。この人は代わりに、10月1日以降のツール呼び出しの割合が下がったことや、応答の質が落ちたことを挙げています。出力量の増加は2.1.286に伴うもので、質の低下はそれと別に起きている可能性があります。
別の報告者は、サーバー側から配られるシステムプロンプトの変化を指摘しています。クライアントは2.1.283のまま、xhighで使っていた環境です。
- 10月1日8時(UTC)に始まったセッションのプロンプトは11,637文字
- 同日10時31分(UTC)に始まったセッションは12,942文字
- 差分は「Finishing work」という節の追加のみ
この節は、作業が残っているうちは手番を終えないよう促す内容だと引用されています。報告者の集計では、この節があるセッションとないセッションで、次のように違いが出ています。
| 指標 | 節なし(35セッション) | 節あり(26セッション) |
|---|---|---|
| 出力トークン/リクエスト(平均) | 節なし(35セッション)999 | 節あり(26セッション)1,616 |
| thinkingトークン/リクエスト(平均) | 節なし(35セッション)379 | 節あり(26セッション)594 |
| ツール結果の文字数/ツール呼び出し | 節なし(35セッション)1,556 | 節あり(26セッション)2,369 |
ユーザーメッセージ1件あたりのリクエスト数はほぼ変わらず、1ステップごとの量が増えたという読みです。ただし、これは時間との交絡を含む比較だと報告者自身が書いています。
さらに、別の報告者が同じ確認を自分のアカウントで行った結果は反対でした。Opus 5.5ではその節も実験キーもなく、10月1日の前後でプロンプトは1文字も変わっていません。それでも体感の悪化は起きていると書いています。サーバー側の実験で説明できる人と、できない人がいます。
手元で確認できること
報告者のうち1人が紹介した、キャッシュ済みのクライアント設定を確認するコマンドです。~/.claude.jsonを読むだけで、送信はしません。
python3 -c 'import json,os;d=json.load(open(os.path.expanduser("~/.claude.json")));\
[print(k,v.get("entrypoint"),v.get("model"),v.get("data",{}).get("experimentKey"),\
"tengu_heron_brook" in v.get("data",{})) for k,v in d.get("clientDataCacheSlots",{}).items()]'出力の最後の列がTrueなら、その節がキャッシュに入っています。この確認方法はissueのコメントで紹介された方法です。clientDataCacheSlotsのフィールドは、model-configなどの公式ページに説明がありません。設定ファイルの内部構造は変わりうるため、目安として扱います。
トランスクリプトから自分で測りたい場合は、報告者と同じく、リクエストごとの出力トークンとthinkingトークンを日別に集計し、message.idで重複を除いたメインスレッドのリクエストだけを比べる方法が使われています。バージョンの差と日付の差を分けるため、versionフィールドも並べると切り分けやすくなります。
報告者が添付したsessions.csv(gist)は、セッション1本が1行です。開始・終了時刻、CLIのバージョン、モデルごとのリクエスト数、effortごとのリクエスト数、thinkingトークンの合計と中央値、thinkingなしの割合、出力トークンの中央値、コンテキストの最大サイズが並びます。日単位の推移表ではないため、日付とバージョンの切り分けには、自分のセッションで同じ列を作るのが近道です。このCSVには、1つのセッションにmediumとhighのリクエストが混在する行や、別モデルへのフォールバックを記録する列もあります。issueの集計表がこれらをどう扱ったかは、issueに説明がありません。
effortで消費を抑える設定
Anthropicのドキュメントでは、effortはthinkingだけでなく、応答文やツール呼び出しの引数を含む全トークンに効くパラメータです。低くするとツール呼び出しも減って短くなる傾向があります。Opus 5.5の既定はmediumで、Opus 5以前のhighより1段低くなっています。
報告者はhighを明示していました。コメント側の報告ではmediumとhighの両方で症状が出ています。highを明示していても症状が出るので、effortの値は原因というより、まず意図どおりかを確かめる対象です。
各レベルの位置づけは次のとおりです。
| レベル | 位置づけ | 向く作業 |
|---|---|---|
low | 位置づけ能力を多少落として、トークンを大きく節約する | 向く作業サブエージェントなど、速度とコストを優先する単純な作業 |
medium | 位置づけ適度な節約。Opus 5.5とHaiku 5.5の既定 | 向く作業速度・コスト・性能の釣り合いが要るエージェント作業 |
high | 位置づけ必要なだけトークンを使う。ほかのモデルの既定 | 向く作業複雑な推論、難しいコーディング |
xhigh | 位置づけ長時間作業向けに能力を広げる | 向く作業30分を超え、数百万トークンの予算を持つ作業 |
max | 位置づけトークン消費に制約をかけない | 向く作業最も深い推論と網羅的な分析が要る作業 |
xhighはmaxに対応するモデルのすべてで使えるわけではありません。Opus 5.5は5段階すべてに対応しています。
Claude Codeでのeffortの決まり方は、先に当たったものが勝つ順序です。
- 環境変数
CLAUDE_CODE_EFFORT_LEVEL、起動時の--effort、セッション中の/effort - 設定ファイルに保存した、モデルごとのレベルまたは
effortLevelキー - モデルの既定値(Opus 5.5はmedium)
ここに落とし穴が1つあります。ユーザー設定ファイルの最上位にあるeffortLevelは、Opus 5.5では効きません。以前の/effortが書いていた古い形式で、Opus 5.5以降は/effortか/modelのピッカーで選び直すまで既定のmediumから始まります。プロジェクト設定・ローカル設定・管理設定、または--settingsで渡したeffortLevelは全モデルに効きます。Opus 5のときにhighを書いたまま持ち越した設定は、Opus 5.5では無視されている可能性があります。
セッション内の確認と変更は次のとおりです。
/effort status
/effort medium/effort statusで、いま有効なレベルが分かります。1回だけ下げたいときは、起動時に--effort lowを付ける方法もあります。maxは、環境変数で指定しない限りそのセッションだけの適用です。
APIで直接呼ぶ場合は、リクエストのoutput_config.effortに指定します。Opus 5.5では適応的thinkingが常に有効で、thinking: {"type": "disabled"}を送ると全effortレベルで400エラーになります。thinkingの量を減らす手段はeffortを下げることです。移行時の書き方はOpus 5.5でthinking無効のプロンプトを移行するにまとめています。
effortを下げても質の問題は直らない
effortはトークンの使い方に対する行動上の信号で、厳密な予算ではありません。ドキュメントも、低いレベルでは難しい問題で今も考えるが、同じ問題に対する量は減ると書いています。
増えた量を押し戻す手段にはなっても、判断の質が落ちたという報告への解にはなりません。issueの報告者の多くが挙げているのは、次のような症状です。
- 確認していないことを「確認した」と述べる
- 依頼の意図を取り違える
- 自分でできるはずのツール操作を試さない
- 頼まれていない作業にまで手を広げる
最後の項目を書いた報告者は、effortをxhighにしても改善しなかったと書いています。effortを下げると、コスト面は軽くなる一方で、難しいタスクの能力は落ちる側に動きます。コスト試算とeffortの関係はOpus 5.5のタスクコストを試算する方法で扱っています。
確定していないこと
issueの時点で、次の点は決着していません。
- モデル側・サーバー側の変更があったのか(報告者はAnthropicに確認と公表を求めています)
- 2.1.286のシステムプロンプトやハーネスが出力量を増やしたのか
- サーバー側の実験が一部のアカウントだけに影響しているのか
- 判断の質の低下が、量の増加と同じ原因なのか
issueのラベルはbug・area:cost・area:modelで、コメントの最後の投稿は10月4日です。Opus 5.5の長時間タスクの運用面はOpus 5.5をClaude Codeで使いこなすにあります。xhighとthinkingの組み合わせで起きる400エラーはoutput_config.effort xhighが400エラーになる条件で扱っています。
自分の環境で増えているかどうかは、日別の集計で見分けられます。消費が体感で増えたと感じたら、まず/effort statusで有効なレベルを確認し、意図した値と違えば上の順序のどこで決まっているかをたどるのが手早い切り分けです。