GPT-6.1 Sol のコンテキストウィンドウ：1,050,000トークン、922,000ライン、そして272,000の崖

のベンダーのモデルページは、GPT-6.1 Sol2026年10月7日に確認したところ、1,050,000トークンのコンテキストウィンドウと128,000トークンの最大出力を記載している。同じページは、そのURLに.mdを付加して得られる機械可読形式では、レンダリングされたページには決して表示されない第三の数値を載せている。つまり、最大922,000の入力トークンである。GPT-6 Solは、6.1が2026年9月29日に後継としてリリースされたモデルであり、自身のページで同一の上限数値のペアを公開しており、自身のMarkdown形式でも同じ922,000の行を掲載している。私たち自身のopenai/gpt-6-solのモデルカードは、ウィンドウを1,050,000トークン、出力上限を128,000と報告し、その最初のものをスペックストリップに「1M」と表示し、同じページのさらに下にある比較表では同じモデルについて「1.1M」と記載している。

つまり、ページは確かに食い違っている。そして、どのように食い違っているかを正確に述べる価値がある。ベンダーのレンダリングされた仕様ストリップには、ウィンドウと出力上限があり、入力上限がない。同じモデルについてのベンダーのMarkdownドキュメントには、その3つすべてがある。レンダリングされたページを基にリクエストを見積もる人は、ベンダーが公開した制約より1つ少ない制約で作業しており、欠けているその制約は、リクエストが収まるかどうかを決める数値なのだ。

三つの数字、三つの情報源、そして誰も書き留めない一つの引き算

以下が各番号とその出典文書です。いずれも2026年10月7日に閲覧したものです。

• 1,050,000 コンテキストウィンドウ — ベンダーの gpt-6.1-sol のモデルページに、レンダリングされた仕様ストリップとその Markdown 形式の両方で記載されており、gpt-6-sol のページにも同じ数値があります。これはまた、当社のカタログが openai/gpt-6-sol と openai/gpt-6-luna に対して返す値でもあり、このフィールドは丸めた値ではなく 1,050,000 として入力されています。

• 最大出力トークン数 128,000 — 同じページ、同じ2つの形式、両方の世代で。カードのフィールドには128,000と表示されており、その表示は「128K」に丸められます。

• 最大入力トークン数922,000 — ベンダーのgpt-6-solモデルページおよびそのgpt-6.1-solページのMarkdown形式です。どちらのページのレンダリングされたストリップにも含まれておらず、当社のこのモデル用カタログフィールドにも含まれていません。そのフィールドはウィンドウと出力上限で止まっています。

三つの数字は互いに算術的に整合している。922,000 に 128,000 を足すと、ちょうど 1,050,000 になる。ベンダー自身の推論ガイドは、モデルページで実際に足し算をすることなく、この一致を意味あるものにする仕組みを説明している。それによれば、推論トークンは「依然としてモデルのコンテキストウィンドウ内のスペースを占め」、生成されたトークンが「コンテキストウィンドウの上限、または設定した max_output_tokens の値に達する」と、応答は不完全とマークされて返ってくる。入力されるものと出力されるものの間で共有されるウィンドウとは、入力の上限がウィンドウから出力用の予約分を差し引いたものになるウィンドウである。

その解釈は裏付けられてはいるが、証明されてはいない。両者は切り分ける価値がある。文書化されているのは、1,050,000 のウィンドウ、128,000 の出力上限、922,000 の最大入力だ。推測されているのは、それらのうちどれが最初に発動する制約かである。この推論は、出力の許容量を丸ごと確保するすべてのリクエストには当てはまるが、そうしないリクエストには当てはまらない。max_output_tokens を 4,000 に設定し、入力が 1,046,000 トークンであっても、明らかに拒否されるわけではない。ベンダーが、その数値が載っているページにこの減算を明記するまでは、この組み合わせは厳格な受け入れ規則ではなく予算の形として扱い、ブログ記事ではなくカウント用エンドポイントに対して検証すること。

コンテキストは価格ではない——272,000トークンという一歩

より大きなウィンドウは容量についての主張である。コストについての主張ではなく、このファミリーでは、その2つは文書化された境界線で分かれる。ベンダーの料金ページは、そのルールを一文でこう述べている。272K を超える入力トークンを含むプロンプトには、リクエスト全体に対して、入力料金とキャッシュ料金の2倍、出力料金の1.5倍が適用される。同じページにおける2つの列の定義そのものは、「短いコンテキスト：入力トークン ≤272K。長いコンテキスト：入力トークン >272K。」である。

「full」という単語を注意深く読んでください。この階層は、その線を超えたトークンに課税するのではなく、最初のトークンを含むすべてを再価格設定します。そして、これは 6.1 の変更ではありません。同一のしきい値を持つ同一のルールが GPT-6 Sol にも適用されます。だからこそ、この崖はリリースではなく階層に帰属させなければならないのです。

1件のロングコンテキストジョブを両方の側で処理し、GPT-6.1 Solの公表料金を用い、プレフィックスがすでにキャッシュに常駐している状態で、キャッシュ書き込み料金が比較を濁さないようにしてください：

• 入力トークン240,000（うちキャッシュ済み200,000、新規40,000）、出力6,000 — 新規入力40,000は100万トークンあたり$2.00で$0.080、キャッシュ済み入力200,000は$0.10で$0.020、出力6,000は$10.00で$0.060。合計$0.160。

• 入力トークン 300,000（キャッシュ済み 260,000、新規 40,000）、出力 6,000 — リクエストがしきい値を超えたため、すべての料金が変わります：新規入力 40,000 は $4.00 で $0.160、キャッシュ済み入力 260,000 は $0.20 で $0.052、出力 6,000 は $15.00 で $0.090。合計は $0.302。

入力トークンが25パーセント増えると、請求額は89パーセント大きくなる。同じペアをGPT-6 Solで実行すると、その形はより急な傾きで保たれる — 線の下では$0.180、線の上では$0.354になる。旧カードの$0.20というキャッシュ料金が、6.1の長文コンテキストのキャッシュ料金と同じ位置にあるからだ。境界を越えることは傾斜ではなく段差であり、それを確かめる最も安い方法は、ほんのわずかに越えることだ。完全に未キャッシュの、出力トークン1,000の271,000トークンリクエストは$0.552かかるが、273,000では$1.107かかる。入力トークンが0.7パーセント増えると、金額は2.01倍になる。そのリクエストから2,000トークンを削れば、請求額は$1.107から$0.552に下がる — 入力の1パーセント未満で、費用は半分になる。

このセクションの話は、GPT-6.1 Sol のウィンドウが大きいということではありません。ウィンドウが、その大きさで得られるものを上回るコストがかかる境界に到達できるほど大きい、ということです。

実際に1,050,000トークンを埋めているのは何なのか

コンテキスト予算は6つの要素から成り、それらは等しくキャッシュ可能なわけではありません。例示的な240,000トークンのエージェント型リクエストにおけるおおよその割合。割合は当社独自のもので、キャッシュ可否のルールはベンダーのもので、同日に読んだ同社のプロンプトキャッシュガイドによるものです。

• プロバイダーが注入するシステムコンテンツとリクエストのフォーマット — あなたのメッセージより前にレンダリングされ、入力として課金され、最小キャッシュ可能長から明示的に除外されます。あなたが制御できるものでも、削減できるものでもありません。

• 開発者およびシステムの指示、約6,000トークン。キャッシュ可能。これはプレフィックスの先頭部分であるため、ここを変更すると後ろのすべてが無効になります。

• ツール定義とスキーマ、ホスト型ツールサーフェスとあなたの関数を合わせて約14,000トークン。キャッシュ可能であり、プレフィックスの中でも最も脆い部分です。ガイドでは、ツール名、説明、スキーマ、順序、ツール固有の指示が、プレフィックスの境界を動かすものとして挙げられています。

• 取得されたコーパス、約18万トークン。キャッシュ可能で、群を抜いて最大の行です。呼び出し間でバイト単位で安定している場合にのみキャッシュする価値があります — リクエストごとに再構築されるコーパスは、フルプライスのコーパスです。

• 蓄積されたトランスクリプト — 以前のターンとツール結果 — 約30,000トークンで、増加中。最新の変更まではキャッシュ可能です。このターンで届いたツール結果は、フルレートの新規入力です。

• 推論トークン — 生成されるがキャッシュはされず、出力として課金されます。コンテキストウィンドウを消費し、レスポンス本文には表示されません。

そのリストから、運用上の注意点が2つ直接導き出されます。1つ目は、キャッシュエントリは個々のマシン上に保持されるという点です。ガイドによれば、リクエストがプレフィックスを再利用できるのは「一致する未失効のエントリを保持しているマシンに到達した場合に限られ」、オーバーフロー ルーティングはおよそ毎分15リクエストを超えると開始されます。コード内で安定しているプレフィックスでも、本番環境ではミスする可能性があります。2つ目は、キャッシュ可能な最小プレフィックスは可視入力トークン1,024個であり、非表示のシステムトークンはこれにカウントされません。したがって、周囲のリクエストがどれほど大きくても、小さなシステムプロンプトはキャッシュ可能なプレフィックスにはなりません。

出力上限は別個の予算であり、おかわりではない

128,000 の最大出力トークンは、128,000 トークン分の回答を意味するものではありません。推論ガイドには、max_output_tokens がモデルが生成する合計量を上限設定し、それには「推論トークン、可視出力トークン、非可視フォーマットトークンが含まれる」こと、また推論トークンは出力として課金されつつ、ウィンドウ内のスペースを占めることが明記されています。

つまり切り捨ては、エッジケースではなく設計上の判断になる。それは失敗の仕方ゆえだ。生成が上限に達すると、応答はステータス incomplete、理由 max_output_tokens とともに返される。そしてガイドは、これが「可視の出力トークンが生成される前に発生する可能性があり、つまり可視の応答を受け取ることなく、入力トークンと推論トークンのコストを負担する可能性がある」と警告している。ウィンドウ全体を入力に費やし、出力用の取り分を運任せにする予算は、完全なロングコンテキストのリクエストを課金しながら、呼び出し側が解析できるものを何も返さない可能性がある予算だ。ベンダー自身の最初の推奨は、プロンプトが実際に何を必要とするかをまだ測定している間は、推論と出力のために少なくとも25,000トークンを確保することだ。

GPT-6.1 Sol はこれを際立たせており、今回のリリースで真に 6.1 固有と言える数少ない記述の一つです。その推論エフォートの段階は low、medium、high、xhigh、max で、none と minimal の設定はサポートされていません。GPT-6 Sol は六つすべてを受け入れます。したがって 6.1 には推論消費をオフにする設定はなく、デフォルトは medium で、予算の出力側が無料になることは決してありません。

キャッシュ入力の半減——ウィンドウが最も広いところで読み取る

GPT-6.1 Sol のカードで、GPT-6 Sol に対して変動した唯一の料金はキャッシュ入力です。100万トークンあたり $0.20 から $0.10 へ下がっており、モデルページでは非キャッシュ入力料金の5%と表現され、ベンダーのキャッシュガイドでは、GPT-5.6以降のほとんどのモデルが適用される0.1xに対して0.05xのケースとして明示的に挙げられています。入力、キャッシュ書き込み、出力は両カードで同一で、ロングコンテキスト倍率も同一です。

まさにこのページが対象としているワークロードでは、動かすべきメーターはそれで正しく、その理由は長いリクエストのサイズではなく構成にある。上の300,000トークンのジョブでは、入力トークンのうち260,000個はキャッシュ済みプレフィックスだ — リクエストが送信するすべてのものの87パーセントに当たる。したがって、請求の中で最大の単一の入力メーターはキャッシュ行であり、これはロングコンテキスト処理に一般的な性質だ。使うウィンドウが長くなるほど、そのうちすでに送信したプレフィックスの割合が大きくなる。そのメーターを半減させることは、そのリクエストで$0.052の価値がある。

そして、同じリクエストで、崖は半減が与える以上を取り戻す。短コンテキスト料金で価格付けされていればライン以下で支払っていたはずの、GPT-6.1 Solでの同じ30万トークンのジョブは、$0.302ではなく$0.166になる——境界越えのコストは$0.136、つまりこのリリースで変更されたただ一つの課金メーターの価値の約2.6倍だ。ライン以上ではキャッシュ料金は$0.20と表示されるが、これはこのファミリーにとって新しい数字ではない。6.1カードの見出しの2倍であり、このリリース以前にGPT-6 Solがライン以下でのキャッシュ読み取りに対して課していた額そのものだ。長コンテキストのキャッシュ済みワークロードは、見出しの変更を受け取り、それを境界で返上する。そして原因はモデルではなく、境界にある。

コンテキストバジェットのサイズを決める方法

手順として、制約が拘束する順序で：

• リクエストは数えてください。推定しないでください。正確なペイロード — ツール、画像、ファイルなどすべて — を Responses API の入力トークン数エンドポイントに POST してください。ガイドはその理由を率直に述べています。このカウントには、メッセージのロールと境界のための書式設定トークンが含まれており、それらはローカルでトークン化できるテキストには決して現れません。また、「文字数÷4」のようなローカル推定は、画像、ファイル、スキーマに対して不正確です。

• まず出力側を確保してください。 max_output_tokens を選ぶ際は、それが推論、可視出力、フォーマットをまとめて含むことを念頭に置き、ゼロからではなくベンダーの25,000トークンのバッファから始めてください。入力予算は、ウィンドウからその予約分を差し引いたものであり、922 という数値は同じ引き算のベンダー版です。

• 送信する前に、272,000の両側でリクエストの価格を見積もってください。このステップは十分に大きいため、ラインのすぐ下に収まるように設計されたリクエストと、すぐ上に収まるように設計されたリクエストは、別の製品になります。

• プレフィックスは安定性の順に並べる。まず指示、次にツールスキーマ、次にコーパス、最後にトランスクリプト。呼び出しごとに変化するものは末尾に置く。そこではキャッシュ全体ではなく、プレフィックスの一致が損なわれるだけで済む。

• キャッシュを期待する前に、1,024個の可視入力トークンを超えてください。この最小値を下回ると何もキャッシュされず、非表示のプロバイダートークンはこれにカウントされません。

• 再利用が妥当かどうかを確認します。 プレフィックスは、30分間のキャッシュ存続期間内に再利用されなければならず、またそのエントリを保持しているマシンに到達しなければなりません。どちらもガイドで説明されており、いずれもあなたのコードの特性ではありません。

• モデルや設定を変更した後は、必ず再測定してください。GPT-6.1 Sol へ移行すると reasoning-off の位置がなくなり、推論トークン数が変わるため、予算の出力側が変わります。また、推論エフォート、ツール、構造化出力スキーマ、コンテキスト管理の変更もプレフィックス境界を動かし、キャッシュ料金を完全に失う可能性があります。

• ジョブが縮まない場合にどうなるかを決める。 コンパクションが文書化された逃げ道だ。Responses リクエストでは context_management に compact しきい値を設定でき、サーバーは以前の会話内容を、より少ないトークンで重要な状態を引き継ぐ不透明なコンパクション項目に置き換える。これは無料の切り詰めではなく予算の判断である。ガイドはコンパクションについて「最初に変更されたトークン以降の再利用を妨げる可能性がある」と記しているためだ——コンパクションを 1 回実行すると、その背後にあるプレフィックスが無効化される。

このページの計算は、GPT-6.1 Solが置き換える世代から始まっており、その段階こそが今日呼び出せるものです。openai/gpt-6-solの当社カードは、1,050,000トークンのコンテキストウィンドウと128,000トークンの最大出力を報告していますOpenAIのリスト料金のまま、マークアップ0%で — ベンダーの価格がそのままページ上の価格であり、ベンダーの価格変更は更新時ではなくその当日に反映されます。当社のカードには独自の最大入力フィールドがないため、そのモデルの922,000トークンという数値はベンダー自身のドキュメントに拠るほかなく、このページでは一貫してそうしてきました。このカードが役立つのはサイジングです。カードが実際に公開しているウィンドウと出力上限は、上記の予算手順が互いに差し引く2つの数値であり、6.1がまだ新しいうちに実際にその手順を当てはめられるのは、その1つ下の段階です。それは https://www.orcarouter.ai/models/openai/gpt-6-sol にあります。