GPT-5.6 Solは105万トークンなのに、Claude Codeでは20万と表示された — /context 110%の正体

結論から書く。

OpenAIの公式モデルページには、GPT-5.6 Solの仕様として 「1,050,000 context window」 と明記されている。一方、Claude Codeのハーネス上で同じモデルを動かし、/context allを実行したところ、表示は 219.7k / 200k tokens（110%） だった。

これは「GPT-5.6 Solの上限が20万トークン」という意味ではない。Claude Codeがコンテキスト管理に使う上限値と、接続先モデルが受け付けられる上限値が一致していない。

実際のセッションは、20万トークンを超えても回答を返し続けた。したがって、少なくとも次の3点は分けて考える必要がある。

• GPT-5.6 Sol本体の公称コンテキストは105万トークン
• Claude Codeは、この接続ではコンテキスト上限を20万トークンとして表示している
• 上流のGPT-5.6 Solは、Claude Codeの20万表示を超えた入力も受け付けた

OpenAI公式の記載は「1,050,000 context window」

出典はOpenAI Developersのモデル仕様ページだ。

→ GPT-5.6 Sol Model | OpenAI API

ページには、GPT-5.6 Solについて次のように記載されている。

Frontier model for complex professional work

1,050,000 context window

128,000 max output tokens

Feb 16, 2026 knowledge cutoff

つまり、公式仕様は次のとおり。

料金欄にも、長い入力を前提とした注意書きがある。

Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.

27万2,000トークンを超える入力の料金規定があることからも、モデルが20万トークンで打ち止めになる仕様ではないと分かる。

Claude Codeの実測は「219.7k / 200k、110%」

2026年7月20日、Claude Codeのハーネス上でGPT-5.6 Solを動かしていたセッションが長くなった。ステータスラインのコンテキスト表示が100%になったため、/context allを実行した。

確認時の環境は次のとおり。

/context allの結果は次のとおりだった。

Context Usage
Model: gpt-5.6-sol
Tokens: 219.7k / 200k (110%)

内訳も表示された。

内訳6項目の合計は199.6kで、ヘッダーに表示された219.7kとは一致しない（差は約20.1k）。この差の要因は今回のセッションでは特定できていない。以下の議論はヘッダーの219.7k / 200k (110%)という表示そのものを対象にしており、内訳の細目は参考情報として扱う。

Claude Codeは明確に20万トークンを分母としている。仮にOpenAI公式の105万トークンを分母にしていれば、21.97万トークンは約20.9%であり、110%にはならない。

219,700 ÷ 1,050,000 ≒ 20.9%
219,700 ÷   200,000 ≒ 109.9%

/context allの110%表示は、Claude Codeがこのモデルを20万トークンのモデルとして計算していることを示している。

API応答のusageでも20万超を確認した

/context allはClaude Code側の推定値である。そこで、セッションのJSONLに記録された直近のAPI応答も確認した。

model:                       gpt-5.6-sol
input_tokens:                765
cache_creation_input_tokens: 0
cache_read_input_tokens:     210,432
output_tokens:               1,055

現在の入力コンテキストは、入力トークンとキャッシュ読み取り分を合算する。

765 + 210,432 = 211,197 input tokens

この時点で、APIに渡された入力は21万1,197トークンだった。Claude Codeが表示する20万トークンを超えている。それでもGPT-5.6 Solは応答を返した。

/context allの21万9,700トークンと、API応答の21万1,197トークンには差がある。前者は、Claude Codeがシステムツールやメモリファイルなどを分類した推定値だ。後者は、直近API応答のusageに記録された入力値である。計測地点と集計方法が違うため、同じ数字にはならない。

20万は「モデルの物理的な限界」ではなく、Claude Code側の管理値

Claude Codeの公式ドキュメントでは、ステータスラインに渡されるcontext_windowについて次のフィールドが説明されている。

→ Customize your status line — Claude Code Docs

"context_window": {
  "total_input_tokens": 15500,
  "total_output_tokens": 1200,
  "context_window_size": 200000,
  "used_percentage": 8,
  "remaining_percentage": 92
}

公式説明では、context_window_sizeは通常20万トークン、拡張コンテキスト対応モデルでは100万トークンになる。used_percentageは、次の入力トークンを基に計算される。

input_tokens
+ cache_creation_input_tokens
+ cache_read_input_tokens

出力トークンは使用率に含まれない。

今回の/context allは、Claude Code内部のcontext_window_sizeが20万として扱われていることを、そのまま表示した結果と読める。

ただし、この値は接続先モデルが実際に受理できる限界と同じとは限らない。今回のセッションでは、上流のGPT-5.6 Solが21万トークンを超えた入力を受理している。

なぜClaude Codeは105万ではなく20万として扱ったのか

今回の構成は、Claude CodeがOpenAI APIを直接呼ぶものではない。

Claude Code
  ↓ Anthropic Messages API形式
CLIProxyAPI
  ↓ OpenAI向けの形式へ変換
OpenAI Codexバックエンド
  ↓
GPT-5.6 Sol

環境構築の詳細は、次の記事と内部作業記録にまとめている。

• OpenAIがClaude Codeで自社モデルを動かす手順を自ら公開した
• 内部作業記録: claudex-cliproxyapi-setup.md（非公開）

Claude Codeから見えるモデル名はgpt-5.6-solだが、Claude Codeが標準で持つClaudeモデルの情報には含まれない。接続先をANTHROPIC_BASE_URLで差し替えても、モデルのコンテキスト上限まで自動的にOpenAI側の仕様へ置き換わるとは限らない。

現時点では、次の説明が観測事実と最もよく合う。

1. Claude Codeは、この接続のgpt-5.6-solを20万トークンとして管理している
2. CLIProxyAPIはリクエストをOpenAI側へ転送する
3. 上流のGPT-5.6 Solは20万を超えた入力も受け付ける
4. その結果、Claude Codeの表示は110%になっても応答は返る

ここで「Claude Codeが未登録モデルを必ず20万に固定する」とまでは断定できない。今回確認できたのは、この環境・このバージョン・この接続経路で20万と表示された事実である。

Claude Codeの1M指定はClaudeモデル向け

Claude Codeには、モデル名へ[1m]を付けて100万トークンの拡張コンテキストを選ぶ仕組みがある。

→ Model configuration — Claude Code Docs

公式ドキュメントの例は次のとおり。

/model opus[1m]
/model sonnet[1m]
/model claude-opus-4-7[1m]

これは対応するClaudeモデル向けの設定である。gpt-5.6-sol[1m]のように付ければ第三者モデルの上限が自動設定される、という記載は確認できなかった。

そのため、GPT-5.6 Sol本体が105万トークンに対応していても、Claude Codeのコンテキスト管理が同じ値へ切り替わるとは限らない。

自動コンパクションはまだ実行されていなかった

/context allの末尾には次の警告が出た。

Context is 110% full
Autocompact will trigger soon, which discards older messages.
Use /compact now to control what gets kept.

しかし、セッションJSONLを確認した時点ではcompact_boundaryが0件で、フルコンパクションは一度も実行されていなかった。

Claude Codeの公式説明では、コンテキストが上限に近づくと、まず古いツール出力を消し、その後、必要に応じて会話を要約するとされている。

→ When context fills up — Claude Code Docs

Claude Code manages context automatically as you approach the limit. It clears older tool outputs first, then summarizes the conversation if needed.

設定ファイルも確認した。自動コンパクションを明示的に無効化する設定や、PreCompact hookは見つからなかった。それでも、20万を超えた時点では実行されていない。

似た現象は、Claude CodeのGitHub Issuesにも利用者報告がある。

→ Auto-compact never triggers despite statusline reporting “100% context used” — GitHub Issue #63015

このIssueは、Claude Opus 4.7の20万トークンモードで報告されたものであり、今回のGPT-5.6 Sol＋CLIProxyAPI環境とは異なる。また、未解決の利用者報告であって、Anthropicが原因を確定した記録ではない。今回と原因が同じだとは判断できない。ただし、「100%表示後も自動コンパクションが動かない」という症状は一致する。

この時点で確定していること

事実として確認できたものをまとめる。

一方、次はまだ確定していない。

• Claude Codeがカスタムモデルを20万として扱う正確なコード経路
• コンパクション判定も20万を使っているのか、表示だけが20万なのか
• CLIProxyAPI経由でGPT-5.6 Solの105万トークンをどこまで実際に利用できるか
• 20万超でも自動コンパクションが発動しなかった直接原因

同じ現象を確認する手順

Claude Codeで第三者モデルやLLMゲートウェイを使っている場合は、モデルの公称値だけで判断せず、次の3段階で確認する。

1. Claude Codeが認識する上限を見る

/context all

冒頭の表示を確認する。

Model: gpt-5.6-sol
Tokens: 219.7k / 200k (110%)

分母の20万が、Claude Code側のcontext_window_sizeに相当する。

2. API応答のusageを見る

Claude Codeのセッションは~/.claude/projects/配下のJSONLに保存される。直近のassistantメッセージにあるmessage.usageから、次を確認する。

input_tokens
cache_creation_input_tokens
cache_read_input_tokens
output_tokens

入力コンテキストは、最初の3項目の合計で見る。

3. コンパクション履歴を見る

セッションJSONLでcompact_boundaryを確認する。0件なら、少なくともフルコンパクションはまだ実行されていない。

巨大なJSONLを全件表示する必要はない。該当フィールドだけを小さく抽出した方が安全である。

今回の教訓

モデルのコンテキスト上限と、ハーネスが管理するコンテキスト上限は同じとは限らない。

GPT-5.6 SolをCodexで使う場合、Codexがコンテキスト管理を担う。Claude Code上で使う場合は、生成モデルがGPTでも、会話履歴・ツール結果・自動コンパクションを管理するのはClaude Codeである。

今回のようなゲートウェイ構成では、次の3つを別々に確認する必要がある。

• モデル提供元が公表する上限
• ハーネスが認識している上限
• 実際のAPI応答で受理された入力トークン数

gpt-5.6-solというモデル名だけを見て「105万トークン使える」と判断すると、Claude Code側では20万で100%警告が出る。逆に、/contextの20万だけを見て「モデル本体も20万が限界」と判断すると、OpenAI公式仕様と実際の応答を見誤る。

このセッションでは、手動の/compactを使うのが安全である。今後、Claude Code側で第三者モデルのコンテキスト上限を宣言できる仕組みが追加されるか、ゲートウェイがモデル能力を伝えられるようになれば、この表示差は解消できる可能性がある。

出典

• OpenAI Developers — GPT-5.6 Sol Model
• Claude Code Docs — Customize your status line
• Claude Code Docs — Model configuration
• Claude Code Docs — When context fills up
• Claude Code Issue #63015 — 100%表示でもauto-compactが発動しない利用者報告