LLMのtoken使用量を料金区分から読み解く

LLMの料金を読むとき、総token数だけを見ても請求額は再現できません。
少なくとも通常のinput、cached input、cache write、output、tool料金を分ける必要があります。
reasoning tokenも、画面に表示された最終回答の文字数とは別に記録される場合があります。
さらに、ChatGPTのサブスクリプションとAPIの従量課金は別の経路です。
このノートでは、usageレスポンスを料金表へ対応させる調べ方をまとめます。
まず認証と課金の経路を分ける
Codexを例にすると、ChatGPTサインインを使う経路とAPIキーを使う経路があります。
前者は契約プランの利用枠に関係します。
後者はAPIの従量課金に関係します。
Codexの認証資料と料金資料を、同じusageとして集計しません。
モデルの単価を調べるときは、model ID、単位、確認日を最初に記録します。
usageを5つの区分で読む
| 区分 | 含まれるもの | 料金計算での扱い |
|---|---|---|
| input | 指示、履歴、tool定義、添付内容 | 通常の入力単価 |
| cached input | 再利用された入力の一部 | cached input単価 |
| cache write | 明示的cacheへ書き込む入力 | cache write単価 |
| output | 最終回答、tool call、推論を含む出力 | 出力単価 |
| tool | Web検索など外部ツールの利用 | toolごとの料金 |
cached inputは、通常のinputへ追加された別のtoken群とは限りません。
多くのAPIでは、input_tokensの内訳としてcached tokenが示されます。
一方、cache writeの計上方法やフィールド名はAPIとモデルで異なります。
usageレスポンスの合計関係を確認せず、同じtokenを通常inputとcached inputへ二重に足しません。
OpenAIの最新モデルガイドでは、GPT-5.6のcache writeを未キャッシュ入力の1.25倍、cache readを割引単価として説明しています。
概念式を作ってからusageへ合わせる
料金表の単価が100万tokenあたりなら、概念上の計算は次のようになります。
料金 = 通常input × input単価
+ cached input × cache read単価
+ cache write × cache write単価
+ output × output単価
+ tool料金
ここで、通常inputが総inputからcached inputを引いた値なのか、usageへ別フィールドで返されるのかを確認します。
明示的cache writeがinput総量へ含まれるかも、利用するAPIの仕様に合わせます。
token数を1,000,000で割ってから単価を掛けます。
830万input tokenを例に再計算する
GPT-5.6の公式比較ページで確認した1M tokenあたりの料金は次です。
| モデル | input | cached input | output |
|---|---|---|---|
| Sol | $5.00 | $0.50 | $30.00 |
| Terra | $2.00 | $0.20 | $12.00 |
| Luna | $0.20 | $0.02 | $1.20 |
830万input tokenがすべて通常inputで、各リクエストが長文料金の条件に入らないと仮定します。
入力だけなら、Solは$41.50、Terraは$16.60、Lunaは$1.66です。
90%がcache readなら、通常inputは83万tokenで、cached inputは747万tokenになります。
この場合のinput部分は次です。
| モデル | input部分の概算 |
|---|---|
| Sol | $7.885 |
| Terra | $3.154 |
| Luna | $0.3154 |
この例にはoutput、cache write、tool料金を含めていません。
キャッシュ率だけでなく、outputとtool callの増加も別に集計します。
reasoning tokenを最終回答と混ぜない
推論モデルでは、最終回答が短くても内部推論へtokenを使うことがあります。
APIレスポンスにoutput_tokens_details.reasoning_tokensのような内訳があれば確認します。
最終テキストの長さだけで費用を見積もると、output使用量を過小評価します。
reasoning effortを上げると、token、待ち時間、料金が増え得ます。
品質が必ず向上するとは限らないため、代表課題で成功率と総費用を測ります。
定型処理は低いeffortへ置き、曖昧で失敗コストの高い課題だけ高いeffortを試します。
長文料金はリクエスト単位で見る
GPT-5.6のモデルページでは、1リクエストのinputが272K tokenを超える場合、リクエスト全体へinput 2倍とoutput 1.5倍の料金を適用すると説明しています。
830万tokenが多数の小さなリクエストなのか、巨大な少数のリクエストなのかで請求額は変わります。
日次合計だけでなく、リクエストごとのinput長を保存します。
巨大なコンテキストを毎回送るなら、モデルを安くする前に履歴の分割、cache、不要情報の除去を検討します。
見積もりのチェックリスト
- 認証がサブスクリプションかAPIキーか
- model IDと料金の確認日
- inputとcached inputの内訳
- cache writeの計上方法
- reasoningを含む総output
- 長文料金の対象リクエスト
- tool callの回数と単価
- Standard、Batch、Flexなどの処理階層
「何token使ったか」だけでなく、「どの料金区分のtokenを何回使ったか」を記録します。
この記録があれば、モデル変更、cache改善、prompt短縮の効果を同じ基準で比較できます。
