LLM の token 使用量：4 token の回答で 217 token が課金される理由

GPT-5.6 に 1 行の算数問題を解かせると、出力料金の 88% はユーザーから見えない reasoning に消える。見える回答は 10 token だが、課金対象は 81 token だ。しかも、GPT-5.6 はまだ軽いほうである。同じ問題に対して、GLM 5.2 は 4 token の回答で 217 completion token、Qwen3.7-max は同じ回答で 1,104 token を計上した。これは異常ではない。reasoning model は設計上、このように課金される。多くのコストダッシュボードが内訳を表示しない token 区分は、ほかにもある。この記事では、実際の usage object を区分ごとに分解し、実測値とともに確認する。

TL;DR

• GPT-5.6 のデフォルト設定では、10 token の回答に 81 token が課金され、88% を reasoning が占めた。GLM 5.2 は 98%、Qwen3.7-max は 99.3% だった。
• Claude Sonnet 5 は thinking parameter を送っていないにもかかわらず、5 token の回答に 114 thinking token を計上した。
• thinking なしでは 5 系統が誤答した（399、400、427、466、467）。thinking なしで正解したのは GPT-5.6 だけで、reasoning を実行したすべての run は 401 と答えた。
• 1,181 token の Claude cache を write してから read したところ、料金は $0.01246 と $0.00566 になり、公開価格と完全に一致した。

テスト条件

この記事の測定では、すべて同じ single-turn prompt を使った。表で明記していない限り、各 model のデフォルト設定で送信している。

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

正解は 401 である。3 の倍数が 333 個、5 の倍数が 200 個、重複して数えたものが 66 個なので 467 個。そこから 15 の倍数 66 個を除くと 401 個が残る。この問題を選んだ理由は明確だ。見える回答が短く、どの tokenizer でも 3〜4 token に収まる。正解が 1 つしかないため、thinking に効果があったか検証できる。さらに、model が thinking を使いたくなる程度には難しく、今回調べたい挙動に合っている。

課金される 5 種類の token

現在の completion では、最大 5 種類の token が 4 種類の単価で課金される。単一の「使用 token 数」だけを見ても、内訳は分からない。

上のフィールド名は OpenAI-compatible 形式である。Claude にも同じ 5 区分があるが、名前は異なる。input_tokens と output_tokens を使い、thinking は output_tokens_details.thinking_tokens に記録され、output として課金される。cache write は cache_creation object で TTL ごとに分かれ、ephemeral_5m_input_tokens は 1.25x、ephemeral_1h_input_tokens は 2x になる。構造は同じでもラベルが違う。この parsing の問題は後のセクションで改めて扱う。

5 種類の区分と価格倍率。OpenAI-compatible と Anthropic のフィールド名も併記している。88% は、上の例で実測した GPT-5.6 の reasoning 比率である。

冒頭の数字の元になった実際の object を示す。GPT-5.6 がデフォルト設定でテスト問題に回答したときの値だ。

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

課金の計算はこの object から行う。受け取った回答の token 数は、completion_tokens から reasoning_tokens を引いた値だ。81 − 71 = 10 token で、「401」とその formatting が該当する。残りの 71 token は chain-of-thought で、すべて通常の output 単価で課金される。出力料金の 88% を占めるが、GPT-5.6 では内容を一切読めない。この記事にある「見える回答」の数値は、すべて同じ方法で算出している。ほかの model では差がさらに大きい。GLM 5.2 は同じ問題に対して、4 token の回答で 217 completion token を使った。completion_tokens を「model が発言した量」と解釈するコストモデルは、GPT-5.6 では 8 倍、GLM 5.2 では 54 倍もずれる。

Reasoning が予算を左右し、parameter で調整できる

調整可能な 3 系統について、対応するすべての thinking 設定で同じ 1 行の問題を実行した。gateway は同一で、測定日は 2026-07-13/14。各系統の行は reasoning の少ない順に並べている。残る系統の flagship のデフォルト値は次のセクションに掲載する。

この表から分かる点は 4 つある。

• 効く場合の差は大きい。 reasoning_effort: none は $0.000062 で正解し、luna のデフォルトより 8.5 倍安かった。より難しい task では、GLM 5.2 で 20 倍の差も測定している。tier の選択も同じ調整手段になる。GPT-5.6 の flagship は、この問題にデフォルトで reasoning を使わず正解した。次のセクションで示すように、thinking が不要な大型 model のほうが、thinking を必要とする小型 model より安くなる場合もある。
• 効かない model ではほとんど変わらない。 parameter の効き方は系統ごとに異なる。Sonnet 5 では単調に変化し、84 から 249 token まで増えて料金差は 5 倍になった。GPT-5.6 では差が小さく、順序も一定ではない。Qwen3.7-max ではほぼ変わらず、low でも 974 reasoning token を使い、デフォルトは 1,096 token だった。DeepSeek V4 Pro でも 267 対 269 で、実質的に差がなかった。
• ラベルどおりに単調増加するとは限らず、デフォルト設定も決定的ではない。 今回の GPT-5.6 では、high の token 数が medium より少なかった。以前の記事では、GLM の low が high より多く消費した。Sonnet 5 は thinking parameter を一切送っていない request でも 114 token を thinking に使った。同じ GLM のデフォルト request でも、ある run では 213 reasoning token、別の run では 1,312 token と 6 倍の差が出た。ラベルを信用せず、実際の workload で parameter の効果を測る必要がある。
• 安くした結果、誤答するパターンが繰り返し見られる。 ここで thinking なしにした 2 系統は、どちらも誤答した。GLM は 399、Sonnet 5 は 467 だった。5 系統すべての結果は次のセクションに示す。reasoning は正解率のための予算であり、削減する価値があるかどうかは model ではなく task によって決まる。

実運用では、reasoning_tokens を独立した主要コストとして扱う必要がある。output 単価で課金され、見える回答よりはるかに大きくなることが多い。parameter で調整できるが、実際にどの程度効くかは測定しなければ分からない。GPT-5.6 では料金ルールも変わっている。GPT-5.6 のコストガイドで write の割増料金と cache-key の要件を解説している。

課金された内容を実際に読めるのか

「回答とは別枠」でも、必ずしも非表示とは限らない。usage だけでなく、実際の response body も確認した。

• GLM 5.2、DeepSeek、Qwen3.7-max、MiniMax は、回答と並ぶ reasoning_content フィールドに reasoning の全文を返す。 今回の文字数は、それぞれ 3,987、1,604、2,509、581 だった。developer は課金されたすべての token を読める。end user に表示されるかどうかは application の実装次第で、多くの application は表示しない。
• GPT-5.6 は生の chain of thought を公開せず、取得できるのは最大でも要約までだ。 response に model が生成した reasoning.summary を含めることはできる。今回は 359 文字だった。ただし、課金された 91 token は要約ではなく、非公開の生テキストに対するものだ。そのテキストに最も近いのが reasoning.encrypted_content である。multi-turn の連続性を保つために送り返せる暗号化 blob だが、復号はできない。料金を支払った token が自分の response body に入っていても、内容は読めない。
• Claude は request の指定方法で変わる。 adaptive-thinking を使った Sonnet 5 の呼び出しでは、thinking block の text が空なのに thinking_tokens は 114 と記録された。thinking したことは分かるが、内容は読めない。Fable 5 の always-on デフォルトでも同じで、59 token が課金され、block は空だった。一方、同じ Sonnet 5 に明示的な reasoning budget を指定すると、実際の thinking text が返った。73 token が課金され、text も取得できた。見える内容は request の指定方法で決まる。

課金の仕組みは共通だが、内容を確認できるかどうかは model ごとに異なる。どの系統も reasoning を output 単価で課金する。しかし、購入したテキストを監査できる範囲は「全文」から「要約のみ」、「署名付きの空 block」まで幅がある。

text が返る場合は、機械的に評価できる。この問題には固定された 5 つの中間結果（333、200、66、467、401）があり、返された reasoning text にはすべて含まれていた。GLM 5.2、DeepSeek V4 Pro、Qwen3.7-max、Kimi K2.7 Code、MiniMax M3 は完全な導出過程を返し、low-effort variant ではそれぞれ 1 step ずつ省略された。答えだけでなく過程も必要なら、違いは明確だ。reasoning_content があれば、料金を支払った内容を検証できる。要約や空 block しかなければ、model を信用するしかない。見えない Token と見える請求は、この説明責任の欠落を定式化している。PALACEは、外部から隠れた reasoning を推定する手法を扱っている。

各系統の最上位 model で同じ問題を実行

前の表では、parameter の違いを示すために特定の tier を使った。次は、各系統の最新 flagship をデフォルト設定で同じ問題に回答させた結果である。

同じ問題に対する flagship ごとの課金対象 output token。斜線入りのオレンジは reasoning の割合、緑は見える回答を示す。MiniMax のアスタリスクは、usage に reasoning count がないことを表す。割合は差し引きで再構成し、返された reasoning text と照合した。GPT-5.6 sol のチェックマークは、reasoning なしで正解した唯一の run を示す。Gemini 3.5 Flash のバツ印は、flagship で唯一の誤答（466）を示す。

1 つの chart に、各社の reporting 方式の違いがすべて表れている。

• 8 つの flagship のうち 7 つが正解したが、同じ 401 にかかった料金は大きく異なる。 Qwen3.7-max は reasoning に 1,096 token、処理に 22 秒、料金に $0.0084 を使った。GPT-5.6 の flagship は reasoning をまったく使わず、料金は $0.00031 だった。同じ正解でもコスト差は 27 倍、latency 差は 7 倍になる。reasoning budget の影響がそのまま表れている。
• MiniMax は reasoning text を返すが、token count は返さない。 completion は 260 token で、見える回答は 3 token だった。response の reasoning_content には導出過程の全文が入っているが、completion_tokens_details に reasoning の項目はない。count がない場合は差し引きで再構成できる。completion から見える token 数を引いた値が、非表示 output の token 数になる。
• Gemini 3.5 Flash は例外だった。 flagship で唯一の誤答（466）で、completion は 3 token、reasoning count はどこにもなかった。同系統の 2.5 Flash は以前、bill に理由を示す項目がないまま、3 token の 401 を生成するのに 12.5 秒かかった。再実行では 427 と誤答した。
• 誤答は小さい tier や thinking を無効にした設定で発生している。 GLM は thinking off で 399、Sonnet 5 は disabled で 467 と答えた。旧 qwen3-max は reasoning をまったく使わず、3 token で 400 と答えた。reasoning channel がない Kimi K2.5 は、見える出力として課金される 144 token を使って reasoning を書き、本文中では 401 を導出したのに、結論は 400 だった。5 系統で 5 種類の誤答が出た。399、400、427、466、467 である。reasoning なしで正解したのは GPT-5.6 だけだった。

Cache token：方向が 2 つあり、単価差は 12 倍

prompt caching では、input がさらに 2 種類に分かれる。この区分が必要なのは、両者の料金差が大きいためだ。Claude の write は input 単価の 1.25x、1 時間の TTL では 2x で課金される。read は 0.1x だ。1,181 token の cached system prompt を使って Opus 4.8 を 2 回呼び出したところ、write は $0.01246、続く read は $0.00566 だった。どちらも公開価格と小数点以下 6 桁まで一致し、input 側の料金は 2 回目の呼び出しで約 11 分の 1 に下がった。ここで重要なのは会計上の区分である。cache_creation_input_tokens と cache_read_input_tokens をまとめて「input token」と扱うと、割引が正しいか検証できない。cache が何らかの理由で効かなくなっても気づけない。実際、docs から想像するより頻繁に cache は外れる。cache の実測調査では、有効になる threshold が文書上の最小値より 1.4〜2.4 倍高かった。prompt caching ガイドでは、provider ごとの仕組みを詳しく解説している。

ローカルの見積もりと請求が一致しない理由

tokenizer library を使って client 側でコストを見積もり、後から実績と照合する実装は多い。しかし、数字が一致しない理由が 3 つある。

• tokenizer は vendor ごとに異なる。 Claude に送る text を OpenAI の tokenizer で数えるのは、違う物差しで測るようなものだ。同じ文字列でも、系統ごとに tokenization の結果が異なる。
• 自分の message 以外にも課金される。 system prompt と tool schema は、それを含むすべての request で input token になる。ローカル見積もりから漏れやすい項目だ。
• response が返るまで reasoning の量は分からない。 model が thinking に使う token 数は client 側では予測できない。返された usage を見て初めて分かる。

返された usage object は upstream 自身の課金記録である。正確かつ最も低コストな集計方法は、見積もりをやめてこの値を読むことだ。ただし、provider ごとに形式が異なる。cached token だけでも、系統によって cached_tokens、prompt_cache_hit_tokens、total_cached_tokens、cache_read_input_tokens のいずれかで返される。

detail object も固定 schema ではない。OpenAI の referenceには、completion 側の 4 フィールドが記載されている。reasoning_tokens、audio_tokens、Predicted Outputs 用の accepted_prediction_tokens と rejected_prediction_tokens だ。rejected prediction token は output に現れないが、completion token として課金される。prompt 側では、同じ形式に cached_tokens と並んで text_tokens、audio_tokens、image_tokens が追加される。GPT-5.6 には cache_write_tokens があり、実環境では video_tokens も確認している。vendor は自由に拡張する。Kimi K2.7 は undocumented の completion_tokens_details.text_tokens を返した。Gemini は thinking と tool-use の token を別々に集計するが、独自のフィールド名を使う。parser は未知の detail フィールドが来る前提で実装し、フィールドがなければ 0 だと決めつけてはいけない。audio フィールドには独自の料金体系がある。専用 ASR model 7 種類について、課金対象の audio minute あたりの音声文字起こしコストを別途測定している。

ここで gateway が役に立つ。Synthorai は OpenAI、Anthropic、Gemini、open-weight 系統の各形式を 1 つの object に正規化し、reasoning_tokens と 2 方向の cache フィールドを埋める。parser を 1 つ実装すれば、route 先のすべての model に対応できる。

可視化から制限へ

内訳を読むだけでは不十分で、予算超過を可視化するだけでなく、そもそも発生できないようにする必要がある。月末の dashboard で異常に気づいても、すでに料金は発生している。retry loop に陥った agent が dashboard を確認することもない。gateway では各 key に quota を設定し、used_quota と RPM 上限を追跡して request 時に強制適用する。予算を使い切った key は、3 週間後に高額な invoice を出すのではなく、次の request で明示的な error を返す。request ごとの帰属情報も同じ response envelope に含まれる。どの key か、どの model か、BYOK か platform billing かを取得できるため、feature ごとのコストは再構築せず group-by だけで算出できる。

測定結果から導かれる手順は明確だ。最初に reasoning_tokens と cache フィールドを確認する。次に task ごとに reasoning parameter を調整する。そして、loop が起こり得るすべての key に hard quota を設定する。model と token 区分の組み合わせが実際の利用量でいくらになるかは、コスト optimizerで計算できる。この記事と同じ token 単価を使っている。

← ブログに戻る