exceeds_200k_tokensとは — 拡張コンテキストウィンドウでも200kで判定される固定しきい値

Claude Codeのstatusline stdinに含まれるexceeds_200k_tokensは、直近のAPIレスポンスにおけるトークン合計が20万を超えたかどうかを示すブール値です。公式ドキュメントは、実際のコンテキストウィンドウのサイズに関わらない固定のしきい値だと明記しています。Sonnet 5やFable 5のように100万トークン(1M)のコンテキストウィンドウを持つモデルでも判定基準は変わらず20万のままなので、statuslineやhookでこの値を「コンテキストウィンドウが埋まってきた合図」として扱うと、1Mトークンのセッションのごく序盤で誤警告を出す設計になりがちです。

exceeds_200k_tokensとは何を示すフィールドか

exceeds_200k_tokensは、直近のAPIレスポンスに含まれる入力トークン・キャッシュトークン・出力トークンの合計が20万を超えているかを示す真偽値です。stdin JSONのトップレベルに直接置かれており、context_window.used_percentageやcurrent_usageのように初回レスポンス前はnullになり得るフィールドとは違い、最初のペイロードからfalseとして存在します。

{
  "context_window": {
    "context_window_size": 200000
  },
  "exceeds_200k_tokens": false
}

このフィールドの核心は「固定」という一語です。context_window.context_window_sizeは既定で20万、拡張コンテキストウィンドウに対応するモデルでは100万になりますが、exceeds_200k_tokensはどちらのケースでも20万という同じ数字とだけ比較します。つまりこの値は「コンテキストウィンドウの何割を使ったか」ではなく、「合計トークン数が20万という固定の目盛りを超えたか」だけを答えます。

拡張コンテキストウィンドウのセッションで何が起きるか

Claude CodeではFable 5.1、Fable 5、Sonnet 5、Opus 4.6以降、Sonnet 4.6が1Mトークンのコンテキストウィンドウに対応します。対応モデルとプランごとの有効化条件はClaude 1Mコンテキストの実務活用にまとめてあるので、ここではexceeds_200k_tokensの挙動だけに絞ります。

これらのモデルがAnthropic API上で1Mのコンテキストウィンドウのまま動いているとき、Claude Codeは既定で約96.7万トークンに達するまでセッションを自動圧縮しません。つまりセッションはまだ8割近くの余白を残していても、合計トークンが20万を超えた時点でexceeds_200k_tokensはtrueに切り替わります。1Mトークンのセッションでは、序盤の2割を過ぎた時点でこのフラグは早々にtrueへ切り替わり、以後ずっとそのまま残り続けます。

具体的な数字で追うと、この乖離の大きさがわかります。次の表は、1Mトークンのコンテキストウィンドウを持つセッションでトークンが積み上がっていく様子を示す例です(実際のトークン数はセッションごとに異なるため、あくまで説明用の値です)。

used_percentageは21%から90%まで一貫して埋まり具合を反映し続けますが、exceeds_200k_tokensは21%の時点でtrueに切り替わった後、90%まで同じtrueのまま動きません。この間の約70ポイント分の変化を、exceeds_200k_tokensだけを見ているスクリプトは検知できません。

なおCLAUDE_CODE_DISABLE_1M_CONTEXT=1を設定すると、Sonnet 5やFable系のようにネイティブで1Mのコンテキストウィンドウを持つモデルも20万トークンのウィンドウとして扱われ、自動圧縮も20万の境界で発生するようになります。この設定下ではexceeds_200k_tokensと実際のコンテキストウィンドウの逼迫度が一致するため、フィールドの意味と実態がずれる問題自体が起きません。Proプランなどで1Mコンテキストウィンドウの有効化に使用量クレジットが要求される場面についてはUsage credits required for 1M contextの意味と対処で扱っています。

used_percentageとの違い — 出力トークンを含むかどうか

同じ「コンテキストの逼迫度」を示すフィールドに見えても、exceeds_200k_tokensとcontext_window.used_percentageは計算対象が異なります。used_percentageは入力トークンのみを対象に、input_tokens + cache_creation_input_tokens + cache_read_input_tokensの合計を分子に、context_window_sizeを分母に計算され、出力トークンは含まれません。一方exceeds_200k_tokensは入力・キャッシュ・出力トークンの合計を20万という固定値と比較します。current_usageオブジェクトの詳しい内訳はClaude Codeのcurrent_usageで直近リクエストの内訳を読むで扱っています。

出力トークンまで含めた合計が20万という基準値を超えたかどうかだけを知りたい場面では、exceeds_200k_tokensのほうがそのまま使えます。逆に「今どれくらい埋まっているか」を知りたいなら、モデルの実際のコンテキストウィンドウサイズを分母にしたused_percentageのほうが実態に即した数値です。

LLMゲートウェイやカスタムモデルIDでの注意点

exceeds_200k_tokensが実態と一致するかどうかは、Claude Code側がそのモデルの実際のコンテキストウィンドウサイズを正しく認識できているかに左右されます。ANTHROPIC_BASE_URLでLLMゲートウェイを指定している場合、Claude Codeはゲートウェイの先にあるモデルが1Mのコンテキストウィンドウに対応しているかを直接確認できません。ゲートウェイ越しにSonnet 5の1Mコンテキストウィンドウを明示的に使いたいときは、モデルピッカーでsonnet[1m]を選ぶ必要があります。

Claude Codeが認識できないモデルID(ゲートウェイ独自のエイリアス等)を使っている場合の扱いは2通りです。CLAUDE_CODE_MAX_CONTEXT_TOKENSを設定していればそのIDに指定した値が使われ、未設定ならClaude Codeが想定する通常サイズのウィンドウとして扱われます。ここでCLAUDE_CODE_DISABLE_1M_CONTEXT=1を設定していても、Claude Code自身が「このモデルは1Mのコンテキストウィンドウのネイティブモデルだ」と認識できていなければ20万への強制は働かず、the 200K limit isn't enforcedという起動時警告が表示されます。この警告が出ている構成では、exceeds_200k_tokensがtrueになっても、実際にどれだけの余白が残っているかはコンテキストウィンドウサイズの設定次第で変わり、exceeds_200k_tokensだけを見て判断するのは危険です。モデルを固定する設定キーの綴りを取り違えないことも、この種の認識ズレを避ける前提になります(ANTHROPIC_MODEL環境変数でモデルを固定する方法を参照)。

exceeds_200k_tokensにはもう1つ実務上の利点があります。それはnullを気にしなくてよいという点です。context_window.used_percentageやcurrent_usageは、セッション開始直後の初回APIレスポンス前や/compact完了直後の再応答待ちの間、nullになり得ます。これらのフィールドをそのまま数値演算に使うと、nullが数値として扱われずに処理が失敗し、statusline自体が空白になることがあるため、// 0のようなフォールバックを毎回書く必要があります。一方exceeds_200k_tokensは最初のペイロードからfalseという具体的なブール値で存在し、nullになる場面がありません。単純な条件分岐だけで済ませたいスクリプトでは、この扱いやすさが実利になります。

使い分け早見表 — exceeds_200k_tokensをいつ使うか

実装例 — モデルの実際のウィンドウサイズと組み合わせて誤警告を防ぐ

exceeds_200k_tokensだけで警告を出すのではなく、context_window.context_window_sizeが20万かどうかを先に確認すると、1Mトークンのセッションでの誤警告を避けられます。

#!/usr/bin/env bash
input=$(cat)
 
WINDOW_SIZE=$(echo "$input" | jq -r '.context_window.context_window_size // 200000')
EXCEEDS_200K=$(echo "$input" | jq -r '.exceeds_200k_tokens // false')
PCT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
 
if [ "$WINDOW_SIZE" -le 200000 ] && [ "$EXCEEDS_200K" = "true" ]; then
  echo "⚠️ コンテキストが20万トークンに到達"
else
  echo "📊 使用率 ${PCT}%"
fi

このスクリプトは、コンテキストウィンドウの実サイズが20万以下のときだけexceeds_200k_tokensを警告表示に使い、1Mトークンのセッションではused_percentageベースの表示に切り替えます。手元で挙動を確かめるときは、statuslineスクリプトに直接JSONを流し込んで結果を見るのが早道です。

echo '{"context_window":{"context_window_size":1000000,"used_percentage":25},"exceeds_200k_tokens":true}' | ~/.claude/statusline.sh

よくある質問

exceeds_200k_tokensの計算に拡張思考のトークンは含まれますか

含まれます。拡張思考(extended thinking)で生成されるトークンは出力トークンの一部として課金される仕組みで、exceeds_200k_tokensは入力・キャッシュ・出力トークンの合計を対象にするため、拡張思考を有効にしたセッションでは思考トークンの分だけ合計への到達が早まります。used_percentageが出力トークンを含まない入力ベースの計算である点とあわせて押さえておくと、2つのフィールドが同じセッションでも異なるタイミングで動く理由がわかります。

まとめ

exceeds_200k_tokensは、実際のコンテキストウィンドウのサイズに関係なく常に20万トークンという固定値とだけ比較するフィールドです。200kモデルのセッションやCLAUDE_CODE_DISABLE_1M_CONTEXT=1を設定した環境ではこの固定しきい値がそのまま実態に一致しますが、Sonnet 5やFable系のようなネイティブ1Mコンテキストウィンドウのセッションでは、使用量がまだ2割を超えたばかりの段階でtrueに固定され、以降の逼迫度を反映しなくなります。statuslineやhookで「コンテキストウィンドウが埋まってきた」という判断に使うなら、context_window.context_window_sizeでモデルの実際のウィンドウサイズを先に確認するか、出力トークンを含まないused_percentageと使い分けるのが安全です。逆にnullを気にせず単純な条件分岐だけで済ませたい場面や、出力トークンまで含めた合計を基準にしたい場面では、exceeds_200k_tokensはいまも扱いやすい選択肢として残ります。