長いコンテキストの料金階層、最大 6.7 倍でも gateway は非表示

gateway のモデルページに載っている価格は、prompt が長くなると請求額と一致しない。大手の multi-provider aggregator を使い、料金階層がある 9 モデルについて、公開済みの各文字数境界をまたぐリクエストを送った。5 モデルは最初の境界を超えるとページ表示価格のちょうど 2 倍、Alibaba の 3 モデルは最上位階層で 3 倍、3 倍、6.7 倍になった。Azure 経由の 1 モデルは境界の前後を問わず、掲載された endpoint 価格の 1.25 倍で課金され、その後さらに 2 倍になった。どれもページには記載されていない。仕組み自体は vendor が公開している。Google、OpenAI、xAI、Alibaba、ByteDance、MiniMax は、入力が 32K、128K、200k、256K、272K、512k token の境界を超えると、出力を含むリクエスト全体の単価を変更する。本稿では、実際の請求、料金階層の表、その境界を超えないための設定を順に示す。

TL;DR

• 1 つの価格しか表示しない aggregator で、料金階層がある 9 モデルは vendor の境界を超えると 1.8 倍から 6.7 倍で課金された。Azure 経由の GPT-5.6 Luna は掲載価格の 1.25 倍だった。
• qwen3.7-flash の入力単価は 100 万 token あたり $0.03 から $0.10、さらに $0.20 へ上がった。境界は 32K と 256K だった。qwen3-coder-plus は vendor の 6 倍ではなく 3 倍で止まった。
• 入力が 32K から 512k token の境界を超えると、vendor は出力を含むリクエスト全体の単価を変更する。
• 制限すべきなのは出力ではなく入力だ。Claude Code の /autocompact、Codex の model_context_window、API の compaction trigger を使う。

gateway はページに表示した価格どおりに課金するのか

prompt が長くなると、答えはノーだ。増額幅を調べるには、仲介事業者ごとに 2 種類の情報が必要になる。gateway が公開する料金 metadata と、境界の前後で実際にリクエストを送り、報告されたコストだ。

ある大手 multi-provider aggregator は、catalog に pricing.overrides 配列を公開している。base price に加え、min_prompt_tokens: 200000 のような条件と高い単価が入っている。DeepSeek と Tencent のモデルでは、off-peak 料金用の utc_start / utc_end 時間帯も定義されている。2026-09-01 に取得した catalog では、60 件の entry に override があった。対象には Gemini Pro、Grok 4.x、qwen3.7-plus、qwen3.7-flash、qwen3-coder-plus、Seed 2.0、272,000 token に境界を持つ GPT-5.6 全モデルが含まれる。モデルページに表示されるのは base price だけで、料金階層は metadata にしかない。しかも、その metadata は vendor の料金階層を完全には反映していない。qwen3-coder-plus には 32,000 と 128,000 の rule がある一方、vendor の第 4 階層である 256K には何もない。

そこで 2026-09-02 と 2026-09-03 に、その aggregator 経由で公開済みの各境界をまたぐリクエストを送った。usage accounting を有効にすると、aggregator が請求した金額が response に含まれる。実際に処理した endpoint も記録した。aggregator 上の 1 つの model id が、価格の異なる複数の upstream host を束ねており、aggregator はそれらを endpoint と呼んでいる。各点につき 2 回ずつ実行した。

請求と同日に保存したページには、見出しの価格と endpoint ごとの表があるだけで、長さによる料金階層はない。上記の請求はすべて、token 単位で metadata と一致した。9 モデルすべてが vendor の最初の境界で、vendor が定めた倍率に上がった。Alibaba の 3 モデルでは、ページにない料金階層に沿って請求が増えた。qwen3.7-flash は 32K で $0.03 から $0.10 に、256K で $0.20 に上がった。ページ表示は $0.03 のままだが、請求額は 6.7 倍になった。GPT-5.6 Luna にも同じ段階的な値上げがあり、さらに別の差額も加わった。Azure 経由の全実行で、境界の前後を問わず掲載された Azure endpoint 価格の 1.25 倍が請求された。$0.22 に対して $0.275、$0.40 と $0.44 に対して $0.50 と $0.55 だった。この surcharge はページにも endpoint metadata にもない。

料金階層が vendor の設定より手前で止まる場合もある。qwen3-coder-plus は 32K で 1.8 倍、128K で 3 倍に上がったが、276k token まで 100 万 token あたり $1.95 のままだった。一方、Alibaba の公式価格は 256K で入力 $6、出力 $60 に上がり、base price の 6 倍と 12 倍になる。aggregator の metadata には 256K の rule がないため、請求も変わらなかった。aggregator が差額を負担しているのか、別契約で仕入れているのかは外部から判断できない。確認できるのは、請求が metadata に従っており、その metadata とページが別物だということだ。

透明性の欠如は metadata と請求の間ではなく、ページとその両方の間にある。ページ見出しの価格は、下の表にある最安 endpoint の単価であり、実際に処理する endpoint の単価とは限らない。どちらにも長さの条件は載っていない。価格が 1 つだけの model card からは、料金階層も、次のリクエストを処理する endpoint も、表示中の価格の endpoint を自分の account で利用できるかどうかも分からない。

対応は単純だ。利用するモデルの machine-readable な料金情報を endpoint 単位で読み、長さ条件を確認する。そのうえで usage accounting を有効にし、境界の前後で 1 件ずつリクエストを送り、報告されたコストを比較する。ページに書かれていない境界で請求額が上がる gateway は、vendor の rule を説明せずに転嫁している。vendor 側で単価が上がるのに gateway の請求が変わらない場合は、価格体系の異なる host から提供しているか、差額を負担している。安定して続くのは前者だけだ。

境界はどこにあり、料金階層はどう適用されるのか

6 社が長さの境界を公開しており、rule を明記する全モデルで、境界超過後の単価は出力を含むリクエストの全 token に適用される。多くの最初の境界では 2 倍だが、料金階層はさらに上がる。qwen3.7-plus は唯一の境界で 3 倍、qwen3.7-flash は第 3 階層で入力が 6.7 倍、qwen3-coder-plus は第 4 階層で入力が 6 倍、出力が 12 倍になる。価格は 100 万 token あたりで、2026-09-01 に各 vendor の料金ページから取得した。

billing code に反映すべき境界条件が 2 点ある。Google の 2 ページでは 1 token の差がある。Vertex の注記は「200K 以上」、Gemini API の料金表は「prompt が 200k token を超える場合」としている。また Alibaba は K を明確に定義している。128K は 128,000 token、256K は 256,000 tokenであり、2 の累乗ではない。

料金階層は入力長だけで決まり、出力を含むリクエスト全体に適用される。そのため、境界を越える 1 token の限界費用には、それ以前の全 token に対する追加料金が含まれる。Gemini 2.5 Pro では、199,999 token の prompt の入力料金は $0.25 だ。200,001 token では $0.50 になり、4,000 token の回答も $0.04 から $0.06 に上がる。増えたのは 1 token だが、料金は $0.27 増える。

qwen3.7-plus の増額は 3 倍だ。255,029 token の prompt は公式単価で $0.102、257,332 token では $0.309 になる。qwen3-coder-plus では同じ仕組みが 4 階層で重なるため、260k token の prompt は 30k token の prompt と比べて token 単価が 6 倍、出力は 12 倍になる。

この rule は vendor の表だけでなく、実際の請求でも確認できる。qwen3.5-plus の公式入力単価は、256K を境に 100 万 token あたり $0.40 から $0.50 になる。gateway の請求では、境界未満の 10 回（243k token）と、境界超過の 24 回（256k から 321k）を比べると、入力 1 token あたりの料金が正確に 1.25 倍だった。出力単価は変わらなかった。259k のリクエストでは、最後の 3k token だけが 1.25 倍になったのではない。全 token が 1.25 倍で請求された。

履歴が蓄積する agent では、session の途中で気付かないまま境界を越える。境界を越えた turn は、それまで保持している全 turn に対する追加料金を負担する。context を縮めるまで、以降の turn にも高い単価が適用され続ける。

能力も同じ境界で変化するのか

変化しない。この料金階層は能力の境界と誤解されやすいため、実測した。256K に境界がある 2 つの Qwen モデルで、run ごとの random code を含む 1 行の事実を 5 つの深さに埋め込んだ salted needle を使った。thinking を off にし、243k、269k、320k token で試すと、各モデルはすべて 30 回中 30 回正しく想起した。latency は段差ではなく長さに応じて増え、qwen3.7-plus の中央値は 15.2 秒、17.0 秒、20.5 秒だった。log 全体に埋めた K 個の珍しい目撃記録を数える、より難しい課題では、長さとともに性能が落ちた。qwen3.7-plus が発見した割合は 128k で 74%、192k で 60%、243k で 58%、320k で 45% だった。低下は料金境界よりかなり前から始まり、境界前後の値も同じ傾きに沿っている。

Anthropic の文書では、この緩やかな現象に名前が付いている。token 数が増えるにつれて正確性と想起率が低下し、この現象を「context rot」と呼ぶ。実際に起きるが連続的な変化であり、料金階層の境界とは無関係だ。

リクエストを境界未満に保つ方法

出力ではなく入力を制限する。料金階層はリクエストの入力長で決まるため、出力上限である max_tokens を変えても効果はない。調整すべきなのは、client が送る量を制限する設定だ。設定箇所は 4 つの layer に分かれる。

以下は、layer ごとに prompt を制限する設定だ。「料金境界に対応」には絶対 token 数を指定でき、価格境界の直前に設定できるものを示した。window に対する相対値しか指定できない設定は、モデルの context window 内に収めるだけだ。context window と価格境界は別の値である。

この表から 2 点が分かる。料金階層があるモデルを coding agent で使う場合、価格の段差を要約に置き換える設定は compaction window だ。1M の window に対する割合ではなく、境界の直前に絶対 token 数で設定する必要がある。また、よく使われる 2 つの safety 設定、Responses の truncation: "auto" と aggregator の middle-out は window guard にすぎない。料金階層がある Gemini と GPT-5.6 のモデルでは 1M の model window で動作し、価格が変わる 200,000 や 272,000 token では動作しない。リクエスト失敗は防げるが、料金境界の超過は許してしまう。

境界未満に収める手段として cache を当てにしてはいけない。 Prompt caching は料金を下げるが、Google のモデルでは料金階層を回避できない。cache read にも同じ長さの料金階層が適用されるためだ。cache 済みの 150k prefix と新しい 60k context は、合計 210k の prompt として 1 件分請求される。Provisioned capacity ではこの問題自体がなくなる。provisioned throughput unit（PTU）は token 数に関係なく時間単位で課金されるためだ。境界を越える価値がある場合は、意図的に越えるべきだ。上記の測定では、境界でモデル性能は悪化していない。判断材料は、追加 context に対してリクエスト全体の 2 倍、3 倍、最上位では 6.7 倍という料金を払う価値があるかだけだ。

Synthorai での扱い

長さによる料金階層は rate condition なので、gateway でもそのまま rate condition として扱う。モデルの price card には、入力 token の境界を key とする料金階層の list を設定できる。各リクエストでは、自身の prompt 長で選ばれた階層を全 token に適用する。vendor と同じ課金方法だ。前述の qwen3.5-plus の請求も、この仕組みで処理された。usage record には、prompt token 数と price version を計算済みコストと一緒に保存する。そのため、請求を「このリクエストが境界を越えた」ところまで分解できる。リクエストに適用した料金階層は、料金表だけでなく usage record からも確認できる。

FAQ

長いコンテキストの高い単価は、境界を超えた token だけに適用されるか

いいえ。rule を公開しているすべての vendor が、リクエスト全体の単価を変更する。Google は「すべての token（入力と出力）に長い context の単価が適用される」、OpenAI は「リクエスト全体」、xAI は「リクエスト内のすべての token」、Alibaba は「リクエスト内のすべての token は、該当する階層の単価で請求される」と明記している。prompt が 1 token だけ境界を超えても、それ以前の全 token に追加料金がかかる。

API gateway は長いコンテキストの料金階層を転嫁するか

今回の測定では転嫁していた。ある大手 aggregator では、1 つの価格しか表示しないモデルページにもかかわらず、料金階層がある 9 モデルが vendor の境界を超えると vendor の高い単価で請求された。料金階層はページではなく gateway の料金 metadata にある。metadata から vendor の階層が抜ける場合もある。qwen3-coder-plus では 256K より上の階層が欠落していた。

max_tokens で料金境界を超えないようにできるか

できない。max_tokens が制限するのは出力で、料金階層は入力長で決まる。必要なのは prompt を制限する設定だ。agent の compaction window や token limit（Claude Code の /autocompact、Codex の model_context_window）、API の compaction trigger、リクエスト送信前の client-side truncation が該当する。

料金境界でモデルの品質も落ちるか

今回の測定では落ちなかった。料金階層がある 2 つの Qwen モデルで、needle recall は 256K の境界の両側で全問正解だった。counting task の性能は長さとともに徐々に低下したが、境界での段差はなかった。料金階層は business rule だ。長さによる性能低下は実在するが、連続的に起きる。

価格と適用方法は 2026-09-01 に取得した vendor の料金ページから引用した。agent と API の設定は 2026-09-02 時点のリンク先文書に基づく。請求測定は 2026-09-01 から 2026-09-03 に実施し、thinking を無効化した salted prompt を使い、aggregator の各測定点で 2 回ずつ実行した。価格は変動する。billing code に境界を組み込む前にリンク先を確認してほしい。

関連記事：課金単位のフィールドガイド（本稿で詳しく扱った modifier layer）、token 使用量の内訳、prompt caching の仕組み、cache の最小条件を実測。

← ブログに戻る