GPT-5.6 コストガイド：prompt caching で 90% 削減、reasoning effort の影響

GPT-5.6 では、コストを左右する 2 つの要素が同時に変わった。cached input は通常の input 料金の 10% まで下がった。5.x の割引率は 50% だった。また、reasoning がデフォルトで有効になったため、50 call の検証では reasoning_effort を送らない場合の料金が none に固定した場合の 1.5 倍になった。回答は同一だった。input 側では最大 4 つの cache breakpoint を明示的に指定できる。output 側では effort の設定によって、思考処理に支払う額が決まる。gateway 経由で、リリース初日から利用できる Sol、Terra、Luna の両要素を実測した。料金はそれぞれ 1M token あたり input／output が $5/$30、$2.50/$15、$1/$6 で、すべて live の usage.cost meter と照合済みだ。 プロンプトの書き方そのものは GPT-5.6 プロンプトガイド を参照。

TL;DR

• cached input の料金は通常の input 料金の 10%。各 tier で 1M token あたり $0.10/$0.25/$0.50 だった。5.x の割引率は 50%。
• breakpoint では部分的に再利用できる。marker より後ろの block を変更したところ、2,431 token のうち再課金されたのは 1,210 token だけだった。
• 1,024 token 未満の prefix は cache されない。繰り返しでも通知なく miss することがあるため、hit rate は 100% 未満として見積もる。
• cache write は、書き込んだ token に対して 1.25x で課金される。一度も読まれない write は、cache しない場合より高い。
• 4 種類の task を使った matrix では、reasoning_effort を省略すると none の 1.5 倍になった。回答は同一だった。必ず明示的に固定する。

計測日は 2026-07-10。Synthorai gateway の OpenAI 互換 chat completions を使い、OpenAI がこの family を発表した翌日に実施した。3 model とも稼働中で、新しい caching parameter もそのまま渡せる。

1 つの generation、3 つの tier

命名規則が変わった。数字は generation を表し、Sol、Terra、Luna は従来の pro／mini／nano suffix に代わる capability tier だ。3 model とも context window は 1M token、最大 output は 128K。以下の料金はすべて、既知の token 数に対する usage.cost の計測値と完全に一致した。cached input も同様だ。

Sol は flagship で、gpt-5.5 と同額の後継 model だ。料金表も $5/$30 で変わらない。Terra と Luna は同じ generation の小規模 tier で、価格は Sol の半額と 5 分の 1。従来 mini と nano の suffix が担っていた位置に相当する。token count に関しては、3 つを同一 model と考えてよい。送信したすべての sample で count は一致した。

docs から読み解く 5.6 caching の仕組み

従来の GPT caching は単一の仕組みだった。API が 1,024 token 以上の反復 prefix を自動検出し、cached 部分を半額で課金していた。provider 別 caching 比較で GPT を「完全自動」に分類したのはこのためだ。5.6 caching guideでは、これが 2 mode の設計に変わった。

{
  "model": "gpt-5.6-luna",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "...stable system prompt, 1024+ tokens...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "the varying part" }
  ]
}

guide のうち、実運用で重要な rule をまとめる。

• breakpoint は cached prefix の終端を示す。 対象 block と、それより前のすべてが含まれる。default の implicit mode では、引き続き最新 message に breakpoint が自動配置される。explicit mode では、明示的に marker を付けた部分だけが cache される。
• 1 request あたり最大 4 回 cache に write できる。 implicit の自動 breakpoint も 1 slot を消費するため、default mode で使える明示的 marker は 3 つ、explicit mode では 4 つになる。過去の conversation turn にある breakpoint は、後続 request では read-only になる。
• 1,024 token の下限は変わらない。 marker を付けた prefix がこれを下回る場合、cache されない。
• ttl: "30m" は保証される最短 lifetime であり、上限ではない。 「少なくとも 30 分で、それ以上保持される場合もある」とされている。5.6 で deprecated になった prompt_cache_retention の後継であり、従来の 24h extended retention option も廃止された。
• 確実に match させるには prompt_cache_key を使う。 guide では、同じ cache に繰り返し request を routing できるよう、tenant または session ごとに固定 key を使うことを推奨している。1 key あたり毎分約 15 request が soft limit。cache の scope は organization 単位だ。
• 5.6 以降の cache write は input 料金の 1.25x。 新しい usage.prompt_tokens_details.cache_write_tokens field に記録される。5.x 以前は write が無料だった。

GPT-5.5 以前に新 parameter を送ると、明確な 400 error が返る（prompt_cache_options is not supported on this model）。rollout 時は model version で分岐する必要がある。

この設計に見覚えがあるなら、その認識で合っている。content block 上の marker、4 つの breakpoint、write premium、sliding する read-only history は、Claude の cache_control が当初から採用してきた形だ。違いは TTL にある。OpenAI は最短 30 分を保証しており、Claude の default である 5 分の 6 倍だ。

meter の実測値

docs に書かれている仕様を、gateway の meter で 1 probe ずつ検証した。完全な raw record は run log にある。以下の cost はすべて、各 tier の料金と桁単位で一致した。

このうち 3 点は詳しく見ておく必要がある。

部分再利用は実際に機能し、breakpoint を採用する最大の理由になる。 固定 block A と差し替え可能な tail B を使うと、meter が再課金したのは tail だけだった。2,431 token の prompt のうち、1,212 token は cached rate で読み出され、新しい B の 1,210 token だけが write premium で書き込まれた。合計額は料金表と桁単位で一致した。system prompt、tools、documents の順に各 layer へ marker を付ける layered prefix は、Claude user が prompt を組み立てる際の基本形だ。GPT の automatic mode では、この動作を保証できなかった。ただし full repeat では、match length が mark より短くなる場合があった。ある probe では 2,422 token の write に対し 1,897 token だった。budget は正確な match 数ではなく、割引率を基準に見積もるべきだ。

下限と通知のない miss は運用上の落とし穴になる。 621 token の marked block は 2 回とも一切 cache されなかった。error はなく、usage の 0 以外に手掛かりもない。「固定 prefix」が短い system prompt なら、通常料金を払い続けても何も通知されない。miss 時に write されず、通常料金だけ発生する場合もある。request がどの経路を通るとしても、hit rate は保証値ではなく分布として扱う必要がある。本番環境では、5 分 cache の auditで行っているように cached_tokens を読み取り、alert を設定する。

write premium は実際に発生し、損益分岐点を変える。 3 tier とも、write token は input 料金の正確に 1.25x で課金された。Luna は 1M token あたり $1.25、Terra は $3.125、Sol は $6.25 で、最終 run の全 probe が桁単位で一致した。この premium を回収できるのは、prefix が少なくとも 1 回再利用された場合だけだ。1 度も hit しない write は、cache を使わない場合より 25% 高い。LangChain の記事で計測した Claude の write premium と同じ落とし穴だ。安定して見える prefix すべてではなく、繰り返されることが確実なものだけに mark を付ける。

検証した範囲では、30 分の下限は維持されていた。write から 15 分後、key を付けて再送すると、1,313 token の全量が cache から返った。料金も 10% rate と一致した。従来の in-memory cache が持続する 5～10 分を大きく超えている。同じ間隔で実施した 2 回目の keyed probe でも同じ結果だった。30 分全体の検証は行っていない。

比較用に同一 workload を GPT-5.5 で実行

公平に比較するなら、同価格帯を見るべきだ。Sol の料金表は gpt-5.5 と同じ $5/$30 で、直接対応する後継 model にあたる。Terra と Luna は、その下に位置する小規模 tier だ。表示価格は同じでも、caching の条件は大きく異なる。

同じ表示価格で、実質的な upgrade は caching 条件にある。3,000 token の prefix は、5.5 の automatic cache が hit した場合、1 call あたり $0.0075 かかる。warm 状態の Sol なら $0.0015 で、cached 部分は 5 分の 1 になる。より大きな変化は、制御と可視性だ。5.5 の hit は不透明な prefix 検出に依存し、任意に発生させることも debug することもできない。5.6 では cache する範囲を正確に mark し、prompt_cache_key で反復 request を routing し、各 write を usage で確認できる。miss も無言ではなく、自分で作った field の 0 として現れる。下位 tier への移行効果も加算される。5.5 が workload に対して過剰なら、Terra で料金表全体が半額、Luna で 5 分の 1 になり、同じ warm prefix は $0.00075 と $0.0003 まで下がる。5.5 に残る利点は optional の 24 時間 retention だ。巨大な prefix に対して 1 日 1 回 batch を実行する traffic なら、こちらが有利になる。migration では 2 つ目の調整要素が逆方向に働く点にも注意が必要だ。5.6 はデフォルトで reasoning を行う。reasoning_effort を固定せずに 5.5 の workload を移行すると、同じ料金表でも新たな output cost が加わる。

2 つ目の調整要素：reasoning effort

caching は input 料金を制御する。reasoning_effort は output 側を制御する。reasoning token は output rate で課金され、prefix と違って cache できないためだ。GPT-5.6 の全 tier で none から xhigh まで指定できる。launch post では Sol 用の max effort も紹介されているが、chat completions では利用できない。Sol と Terra のどちらでも 400: 'reasoning_effort' does not support 'max' with this model になる。そのため、gateway や SDK が使う API path では xhigh が実質的な上限だ。

50 call の matrix を実行した。4 種類の task、review の classify、log line からの field 抽出、複数 step の算数文章題、小規模な code generation を用意し、none から xhigh までの 6 setting と parameter 省略時を比較した。Terra と Luna を中心に、Sol でも spot check した。50 件すべて、全 setting で正解だった。変わったのは料金だ。visible token が数十程度の短い output の call なので、output rate で課金される数十個の reasoning token が total cost の大部分を占める。ratio 列は call 全体の cost を比較している。

結果は 3 点ある。第 1 に、5.6 は自動的に処理量を調整する。単純な 2 task では、どの setting でも reasoning token は 1 つも使われず、設定による追加 cost はなかった。第 2 に、math や code のように思考が必要そうな task では、結果が変わらなくても default で reasoning が動く。Luna の math と code、Terra の math では、parameter 省略時の cost が none の 2.5x～3.5x になった。Terra の code run では、たまたま default でも token を消費しなかった。回答はいずれも同じだった。Terra と Luna の grid 全体を合計すると 1.5 倍だった。第 3 に、中間 setting は連続的な dial ではなく、ばらつきが大きい。表には載せていないが、Terra の math run では reasoning token が low で 19、medium で 0、high で 21、xhigh で再び 0 だった。Luna の code run では high の 41 に対して、xhigh で 101 だった。設定名は budget ではなく intent を表す。GLM 5.2でも同じ挙動を確認している。

すべての call で reasoning_effort を明示的に送り、default を none にする。 classification、extraction、routing、短い transform にはこれでよい。task が難しそうだからという理由ではなく、eval で高い setting が結果を変えると確認できた call site だけ引き上げる。今回の 4 task は短い output の API workload だ。本当に難しい multi-step task なら reasoning cost に見合う場合もあるが、判断は計測結果に基づくべきだ。

2 つの要素は重なって効く。prefix が warm になると、Luna call の input 側は定価の 10 分の 1 になる。一方、短い task では reasoning の default が残る最大の cost 項目になる。Luna の math call は none なら合計 $0.00007、parameter 省略時は $0.00025 だった。reasoning の default だけで $0.00018 増え、調整済み call 全体の 2 倍以上を追加している。effort を固定せずに cache だけ導入すると、反対側から節約分が流出する。

workload 別の推奨設定

選択肢が明確に分かれるため、gateway customer には次のように案内している。

workload の形にかかわらず、tenant または session ごとに固定の prompt_cache_key を送る。docs では、確実に match させるための基準として key を挙げている。各 marked layer は 1,024 token の下限を超えるようにする。通知のない miss があるため、cached_tokens も監視する。cache は model ごとに分かれる。tier をまたぐ A/B test では、両側とも cache をゼロから warm にする必要がある。同じ commit でもう一方の設定も行う。上の matrix に従って reasoning_effort を固定し、eval で必要性が確認できない限り none にする。

tier 選択では、tier の差より 90% 割引の方が計算に大きく影響する。3,000 token の prefix を繰り返す workload では、warm な Luna traffic なら 1,000 call あたり約 $0.30、warm な Sol なら $1.50 かかる。cached 部分における tier 間の差は output token の差より小さい。output の品質と価格で tier を選び、caching で input 側を平準化する。gpt-5.5 から移行する場合、Sol は同じ料金表のまま cache read が 5 分の 1 になり、cache が発生する箇所も制御できる drop-in upgrade だ。小さい tier でも品質を維持できると eval で確認できれば、Terra または Luna に下げる。料金表はそこからさらに半額または 5 分の 1 になる。

tokenizer は変わっていない

24 個の sample を比較した。9 言語の narrative passage、そのうち 6 言語の technical 版と news 版、Python function、JSON tool-call を使った。完了したすべての比較で、GPT-5.5、Sol、Terra、Luna の count は一致した。5.5 を基準に調整した token budget と cache 下限の見積もりは、そのまま使える。言語別の挙動は言語別 tokenizer の記事にまとめており、5.6 にもそのまま当てはまる。

結論

• cache の割引率が 50% から 90% に上がり、30 分の TTL が保証されたことが、この release における実質的な値下げだ。tier 価格が注目されるが、実際の請求額には caching 条件の方が大きく効く。
• layered prompt には explicit breakpoint を採用する。部分再利用は理論上の話ではなく、実測で確認できた。Claude の考え方をそのまま適用できる。
• 1,024 token の下限を守り、prompt_cache_key を送り、cached_tokens を監視する。通知のない miss と、通知なく一切 cache されないケースの両方がある。
• reasoning_effort を明示的に送り、default を none にする。管理しない default は matrix 全体で 1.5 倍、単一 task では最大 3.5 倍になった。回答は同一だった。
• 利用可能な上限は xhigh。chat completions で max を送ると 400 になる。5.5 から tokenizer の基準を取り直す必要はない。

FAQ

GPT-5.6 は Claude のような explicit prompt caching に対応していますか？ 対応している。prompt_cache_options: {"mode": "explicit"} と、content block 上の prompt_cache_breakpoint marker を使う。1 request あたり最大 4 回 write できる。implicit mode では automatic breakpoint が 1 slot を使うため、明示的に使えるのは 3 つだ。OpenAI 互換 gateway で計測したところ、mark を付けた 3,012 token の prefix は最初の call で write され、2 回目は全量が cached rate で読み出された。

GPT-5.6 の cached input はいくらですか？ input 料金の 10%。3 tier すべてで実測し、1M token あたり Luna が $0.10、Terra が $0.25、Sol が $0.50 だった。GPT-5.x では cached token が input の 50% で課金されていたため、5.6 の cached-token rate は 5 分の 1 だ。

GPT-5.6 の caching は GPT-5.5 より優れていますか？ 割引率と制御性では優れている。cached rate は 50% から 10% に下がり、任意に発生させることも debug することもできない automatic 検出のみの方式から、4 つの explicit breakpoint を使える方式になった。lifetime も 5～10 分の best effort から、keyed cache で最短 30 分の保証に変わった。5.5 に残る利点は optional の 24 時間 retention tier で、5.6 では廃止されている。

GPT-5.6 の cache はどのくらい保持されますか？ docs では少なくとも 30 分が保証されている。ttl: "30m" が唯一受理される値で、それ以上保持される場合もある。この option は deprecated になった prompt_cache_retention に代わるもので、従来の 24 時間 extended tier も含めて置き換える。今回の probe では、write の 15 分後に keyed re-read すると全量 hit した。30 分全体の検証は行っていない。

prompt_cache_key は必要ですか？ 送るべきだ。docs では、5.6 で確実に match させるための基準として、tenant または session ごとの固定 key を挙げている。soft limit は 1 key あたり毎分約 15 request。追加 cost はなく、cached_tokens の監視と組み合わせることで、割引が実際に適用されているか確認できる。

reasoning_effort は GPT-5.6 の cost をどの程度変えますか？ 50 call の matrix で計測した。4 種類の task、6 setting、Terra と Luna を使い、すべての setting で正解が得られた。parameter を省略した場合、全体では none の 1.5 倍、算数 task では最大 3.5 倍になった。単純な classification と extraction では、どの setting でも reasoning token を消費しなかった。none に固定し、eval で必要性が確認できた場合だけ引き上げる。

GPT-5.6 Sol で最大の reasoning effort を使えますか？ chat completions 経由では使えない。Sol と Terra のどちらでも reasoning_effort: "max" を送ると、none から xhigh までを示す 400 が返る。

API workload ではどの GPT-5.6 tier を使うべきですか？ Sol は gpt-5.5 と同価格の後継 model で、料金表は同じ $5/$30、cache read は 5 分の 1 になる。Terra と Luna は小規模 tier で、それぞれ半額と 5 分の 1。prefix が安定し、key を付けていれば、90% の cache 割引によって input 側の差は小さくなる。output 品質の eval で許容できる範囲まで tier を下げ、output 価格を調整する。

この series で実測した関連 cost guide：7 つの ASR model を比較した音声文字起こしコスト、画像生成コスト、GPT Realtime 音声料金。

← ブログに戻る