Context Window、token、請求額を実測する

この業界で最も高くつく誤解は、modelが会話を覚えているというものです。

覚えていません。そしてChapter 13の仕組みが、その理由を正確に説明しています。生成中のtransformerのstateはKV cacheです。sequence内のすべてのtokenについて計算されたkeyとvalueです。このcacheは1つのrequestの間だけ存在します。requestが終わると、それを保持していたprocessは別の誰かに使われ、cacheは消えます。向こう側にユーザーごとのstoreはなく、sessionもありません。

したがって次のrequestは、modelに知っていてほしいことをすべて載せて届かなければなりません。そしてmodelは、新しいtokenを1つemitする前に、prompt全体にforward passを走らせてそのstateを作り直します。Chapter 15 ではpromptを「state全体」と呼びました。物理的な理由はこれです。promptが完全なstateなのは、呼び出しをまたいで生き残るものが他にないからです。

context window は、そのpromptと回答を足した最大長です。どれだけのstateを再構築できるかの上限であり、request間で何かを保持する容器ではありません。それを「modelのmemory」と呼ぶと、因果の向きを逆に見ています。memoryを満たしているのではなく、memoryを再確立するために支払っているのです。

22倍はここから来ます。ターン $n$ はそれ以前の $n-1$ ターンすべてを運ぶため、$n$ ターンの会話全体の入力は、増え続ける級数の和になり、二次になります。

ここで $s$ はsystem prompt、$h_i$ はターン $i$ のhistoryです。40ターンにわたる実測の累積入力を $an^2 + bn$ に当てはめると $60.22\,n^2 + 432.25\,n$ となり、40ターン目で113,645 tokenを予測します。実測は112,617 tokenです。二次項が支配的で、線形項がユーザーが実際に入力した分です。

この章から持ち帰るべき結論はこれです。請求額は最後の質問ではなく、会話の二乗に比例して増えます。 同じ40個の質問をhistoryなしで投げると $0.066036 です。historyを保持すると $0.274386 です。historyは請求額を4.2倍にしました。そして会話長そのものが倍率なので、これからも増やし続けます。

windowが有限なのは、同じ方向に働く2つの理由があるからです。1つ目はChapter 9の理由です。attentionはすべてのtokenを他のすべてのtokenと比較するため、そのlayerの仕事量はsequence lengthの二乗で増えます。2つ目はmemoryです。KV cacheはsequence lengthに対して線形に増えます。Chapter 13でその計算をしました。長いsequenceでは、weightsよりも大きくなります。

どちらの制約にも対策は打たれてきましたが、どちらも消えたわけではありません。FlashAttention¹ は計算を組み替え、高帯域memoryへのread/writeを大幅に減らします。これにより、漸近的なcostを変えずに長いsequenceを実用的にします。Position Interpolation² とYaRN³ は、再trainingではなくChapter 9のpositional encodingを再スケーリングすることで、training済みmodelの使えるwindowを拡張します。これらが合わさって、windowは5年で2Kから1Mになりました。

ただし、それらはlong contextを無料にしたわけではありません。天井を高くし、傾きを緩やかにしただけです。傾きはまだ残っています。そしてこの章の後半で出てくるprice tierが測っているのは、その傾きです。

インターネット上のほぼすべてのcost calculatorは、API callを「input tokens × input price + output tokens × output price」としてmodel化します。2023年には正しかった式です。今では間違っており、請求額が上下どちらにも2倍以上ずれることがあります。

課金対象のtoken categoryは 5つ あります。

この5つのうち3つは2年前には個別の行として存在していませんでした。そして人が間違えるのは2つのcache行です。cache writeは通常のinputより高いのであって、安いのではありません。何かを保存するためにpremiumを払い、それを読み戻すときにdiscountを受けます。その取引が得かどうかは、何回読むかだけで決まります。

reasoning bucketは Chapter 12 のものに価格が付いたものです。ここには明示しておく価値のある細部があります。Googleのdocumentationには、pricingは「APIから出力されるのがsummaryだけであっても、modelが生成する必要のあるfull thought tokensに基づく」とあります。⁴ あなたに送信されないtokensにも課金されます。これは、中身を数えることも、検査することも、検証することもできない唯一のbucketです。

ここからは単なる掛け算ではなく、normalisationの問題になります。providerごとにこれらのbucketを別の名前で報告し、しかもここが罠ですが、2つのproviderが同じ単語を別の量に使っています。

1つのcallを考えます。cacheから読まれた4,837 token、新規の110 token、可視output tokenが142、reasoning tokenが300です。

// OpenAI-compatible
{ "usage": { "prompt_tokens": 4947,
             "prompt_tokens_details": { "cached_tokens": 4837 },
             "completion_tokens": 442,
             "completion_tokens_details": { "reasoning_tokens": 300 } } }

// Anthropic
{ "usage": { "input_tokens": 110,
             "cache_read_input_tokens": 4837,
             "cache_creation_input_tokens": 0,
             "output_tokens": 442 } }

// Gemini
{ "usageMetadata": { "promptTokenCount": 4947,
                     "cachedContentTokenCount": 4837,
                     "candidatesTokenCount": 142,
                     "thoughtsTokenCount": 300 } }

prompt_tokens: 4947 と input_tokens: 110 を見てください。どちらのfieldも、同じ promptの入力token数です。OpenAIのものはcached tokensを含みます。Anthropicのものは含みません。documentationは恒等式 total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens を明示しています。⁵ Anthropicの input_tokens は「最後のcache breakpoint以降のtokens」を意味します。

そしてoutputを見てください。OpenAIとAnthropicはいずれも442を報告します。これはすでに300のreasoning tokensを含んでいます。Geminiは142を報告し、300は独自のfieldに入れます。Chapter 12では、同じ仕事を数える2つの方法の非互換性としてこれを指摘しました。ここではそれにいくらかかるかを見ています。

normalizerは30行で、任意ではありません。

export interface Usage {
  promptTokens?: number;        // input, NOT cached
  cachedInputTokens?: number;   // read from cache
  cacheWriteTokens?: number;    // written to cache on this call
  completionTokens?: number;    // output
  reasoningTokens?: number;     // billed apart from output (Gemini only)
}

const num = (v: unknown) => (typeof v === "number" && isFinite(v) ? v : 0);

export const fromOpenAI = (raw: any): Usage => {
  const u = raw.usage ?? {}, d = u.prompt_tokens_details ?? {};
  const cached = num(d.cached_tokens), write = num(d.cache_write_tokens);
  return {
    promptTokens: Math.max(0, num(u.prompt_tokens) - cached - write), 
    cachedInputTokens: cached,
    cacheWriteTokens: write,
    completionTokens: num(u.completion_tokens),   // reasoning already inside
    reasoningTokens: 0,
  };
};

export const fromAnthropic = (raw: any): Usage => {
  const u = raw.usage ?? {};
  return {
    promptTokens: num(u.input_tokens),            // already excludes cache
    cachedInputTokens: num(u.cache_read_input_tokens),
    cacheWriteTokens: num(u.cache_creation_input_tokens),
    completionTokens: num(u.output_tokens),
    reasoningTokens: 0,
  };
};

export const fromGemini = (raw: any): Usage => {
  const m = raw.usageMetadata ?? {}, cached = num(m.cachedContentTokenCount);
  return {
    promptTokens: Math.max(0, num(m.promptTokenCount) - cached),
    cachedInputTokens: cached,
    cacheWriteTokens: 0,
    completionTokens: num(m.candidatesTokenCount), // EXCLUDES thinking
    reasoningTokens: num(m.thoughtsTokenCount),    // billed at output rate
  };
};

上の3つのpayloadを3つのreaderに通すと、3つとも同じ Usage を生成し、したがって同じ数値になります。$0.006491 です。この一致こそが、そのlayerを書く理由です。

間違えると、同じcallでこうなります。

3つ目が危険です。良いニュースの方向に静かに失敗するからです。dashboard上ではreasoning modelのcostが実際の半分未満に見え、どこにもerrorは出ません。

bucketをnormaliseできれば、cost functionは短くなります。自明でないのはtier lookupだけで、次のsectionで説明します。

export interface Tier { maxPromptTokens: number | null; price: number }
export interface Pricing {
  input: Tier[]; output: Tier[];
  cachedInput?: Tier[]; cacheWrite?: Tier[]; reasoning?: Tier[];
}

const tierPrice = (tiers: Tier[] | undefined, contextSize: number, fallback?: Tier[]) => {
  const table = tiers ?? fallback;
  if (!table?.length) return 0;
  const sorted = [...table].sort(
    (a, b) => (a.maxPromptTokens ?? Infinity) - (b.maxPromptTokens ?? Infinity));
  for (const t of sorted)
    if (t.maxPromptTokens === null || contextSize <= t.maxPromptTokens) return t.price;
  return sorted[sorted.length - 1].price;
};

export function computeCost(pricing: Pricing, usage: Usage): number {
  const fresh = usage.promptTokens ?? 0;
  const read  = usage.cachedInputTokens ?? 0;
  const write = usage.cacheWriteTokens ?? 0;
  const out   = usage.completionTokens ?? 0;
  const think = usage.reasoningTokens ?? 0;
  const contextSize = fresh + read + write;   // the tier depends on the WHOLE prompt
  return fresh * tierPrice(pricing.input, contextSize)
       + read  * tierPrice(pricing.cachedInput, contextSize, pricing.input)
       + write * tierPrice(pricing.cacheWrite,  contextSize, pricing.input)
       + out   * tierPrice(pricing.output, contextSize)
       + think * tierPrice(pricing.reasoning, contextSize, pricing.output);
}

ここには擁護する価値のある設計判断が2つあります。fallback、つまりcache priceはinputへ、reasoningはoutputへfallbackするという点は、tableが欠けていることの意味をencodeしています。Geminiのreasoning tokensはoutput rateで課金されるので、reasoning priceがないことはzeroではなく、output priceを意味します。そして contextSize はfresh分だけでなく3つすべてのinput bucketを合計します。tierは、どれだけがfull priceで課金されたかではなく、promptの長さで選ばれるからです。

prompt cacheは、promptのprefixについてmodelが計算済みのstateを保存し、後続requestで同じprefixが来たときに再計算をskipします。「prefix」という言葉から4つの性質が出てきます。そして4つとも人を驚かせます。

break-evenは頭に入れておけるほど小さく、OpenAIのdocumentationが計算しています。prefixを一度writeして一度reuseすると、通常input costの1.35×になります。uncachedで2回処理する場合は2×です。10 requestでは、1回のwriteと9回のreadで2.15×、対してuncachedは10×です。1回reuseすればwriteの元が取れます。 Anthropicでも同じ地点に落ちます。5分cacheなら1 read、1時間cacheなら2 readです。

では40ターンの会話をもう一度見ます。cachingを有効にし、prefixが安定している場合です。

68%安くなります。そしてこの表の3つの数値は注意に値します。

cacheはターン6まで効きません。 promptはそこまで1,024 tokenに届かないため、最初の5ターンは以前とまったく同じように課金されます。そして6ターン目は、cacheを満たすターンなので1.25×のwrite premiumにより、むしろ悪く課金されます。最初のreadはターン7です。表の2,887 uncached tokensはその算術です。6ターン分ではなく、5ターン分です。cachingは長いpromptへのdiscountであり、短い会話は何も得ません。

write premiumは $0.002474 で、cached billの2.8%です。各ターンが新しいtailをwriteし、40回行われます。それでもwrite premium全体は、readが節約した額に比べれば丸め誤差です。write chargeは、心配をやめるためにこそ正確に理解する価値があります。

112,617 tokenのうち、full input priceで課金されたのは2,887 tokenだけ でした。これがうまく動くcacheの形です。ほとんどすべてがreadになります。

実際にお金を失うfailureは、1行のbugです。

毎回変わるものをpromptの前方に置いてください。timestamp、request id、ユーザー名、「today is」行、新しくretrievedされたdocumentなどです。するとprefixはbyte 1から異なります。何も一致しません。すべてのcallがmissになります。そしてすべてのcallが新しいprefixを提示するため、すべてのcallがwriteもします。

同じ会話、同じ40ターン、caching有効、ただしsystem promptの先頭にcallごとのtimestampを置いた場合です。

prompt cachingを有効にした結果、会話は有効にしない場合より20%高くなりました。109,730 tokenに1.25×のwrite premiumを払い、読み戻しはzeroです。errorもwarningもなく、featureはonです。

したがってrule、prompt cachingの全体を1行で言うと、こうです。安定contentを前に、可変contentを後ろに。 system instructions、tool definitions、reference materialを先に置き、timestamps、user identity、current questionを最後に置く。Anthropicは階層を明示しています。cacheは tools → system → messages に従い、どのlevelで変更があっても、そのlevelとそれ以降すべてがinvalidateされます。つまり1つのtool descriptionを編集するだけでcache全体がinvalidateされます。⁵

人がつまずく帰結が2つあります。enabled になっているtoolを変えるとtool definitionsが変わるため、一部ユーザーにtoolを追加するfeature flagはcacheを2つに分割します。またAnthropicでは、web searchやcitationsをtoggleするとsystem promptが変更され、自分のtextを一行も触っていなくてもsystem cacheとmessage cacheがinvalidateされます。

二次に増えるbillへの明らかな反応は、history全体を送るのをやめることです。直近12 messageだけ残し、残りを落とす。確かにbillは下がりますが、たいてい誤った手です。測定がその理由を示します。

12 message windowへのtruncateは、すべてをuncachedで送るより57%安いです。誰もがする比較であり、このtechniqueがpopularな理由です。しかし、うまく動くcacheと一緒に全historyを送る場合より39%高く、truncationと同時にcachingをonにすると、良くなるどころか少し悪くなります。

mechanismはまたprefixです。sliding windowは各ターンで最古のmessageを落とすため、promptは前回と同じところから始まらなくなり、毎ターン新しいprefixを提示します。OpenAIのguidanceはまさにこう言っています。「summarisation, compaction, or context truncation can change the prefix and reset cache reuse」。⁶ 40ターン目にはwindowed promptは813 tokenで、1,024-token minimumを下回るため、そもそもcacheできません。

そしてお金はcostの安い半分です。落としたものは、ターン40でmodelが必要とした、ターン2のユーザー指示です。truncationは、見えるbillと見えないfailureを交換します。それを適切に行う、つまりcompaction、window外に保持するstructured notes、必要時のhistory retrievalは、Chapter 24 の主題です。

long contextは、長いから高いだけではありません。thresholdを超えると、tokenあたりも高くなります。そしてthresholdはprompt全体に遡及的に適用されます。

gpt-5.6-terra のOpenAI model pageは、それを一文で述べています。「Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request」。⁷ 超過分ではありません。全体です。

prompt 271,999 + 500 output  ->  $0.5500
prompt 272,000 + 500 output  ->  $0.5500
prompt 272,001 + 500 output  ->  $1.0970

1 tokenで55セントです。retrieved documentsからpromptを組み立て、そのサイズをcontrolできないserviceなら、誰もteam内で書き留めていない境界にcost modelの崖があります。

Googleのpricingも同じ仕組みで、thresholdは200,000 tokenです。Gemini 2.5 Proは200Kまでのpromptで100万input tokenあたり $1.25、超えると $2.50 です。outputは $10.00 から $15.00 になります。⁸ Anthropicは反対の方向に進みました。2026年9月6日時点のdocumentationでは、Claude 4.6以降は100万token window全体をstandard pricingに含むため、「900k-token request is billed at the same per-token rate as a 9k-token request」とされています。⁹ 以前のmodelにはsurchargeが残っていました。

だからpriceは1つの数値ではありません。priceはprompt lengthをkeyにしたtier tableです。それがcost function内の Tier[] の役割であり、computeCost がbucketごとではなくprompt全体でtierを選ぶ理由です。

5つのbucketはChapter 13の2つのphaseに対応します。その対応が見えると、price ratioは恣意的に見えなくなります。

Input tokensはprefillです。 prompt全体が1回のpassでmodelに通され、並列に処理されます。大きなmatrix multiplicationで、compute-boundです。tokenあたりcostは低く、このphaseが time to first token を決めます。4,947-token promptでは、最初の単語が現れる前に4,947 token分のprefillを行う必要があります。

Output tokensはdecodeです。 1つずつ生成され、それぞれがKV cache全体を読むfull forward passです。GPUは計算よりmemory待ちをしていることが多くなります。このphaseが tokens per second を決め、1つのresponse内ではparalleliseできません。そして、ここで価格を付けたmodelでoutputがinputの約6倍かかる理由でもあります。100万tokenあたり $12.00 対 $2.00 です。

3つの帰結が直接出てきます。cache readはprefill workを置き換えるため、latencyとお金を同時に買います。同じdiscountが、低いbillとfirst tokenまでの短い待ち時間として現れます。Reasoning tokensはあなたに見えないdecode です。reasoning modelが数秒間何もstreamせず、その後すばやく答える理由です。Chapter 12はinterface上の帰結を警告しましたが、これはinvoice上の帰結です。そして streamをabortしてもgenerationは止まりません。Chapter 14 はcancellationを作り、価格はこの章に残しました。その価格はfull output countです。誰かがlistenしているかどうかに関係なく、tokensは生成され課金されるからです。誰も保持しないanswerにも同じことが言えます。ターン40のanswerを5回regenerateすると、画面に残った1つに対して $0.057990 かかります。

Chapter 7のtokenizerはPythonで、そのままそこに留まりました。budgetingはrequestを構築するserverで起きるので、ここで行う必要があります。そして利用できるaccuracy levelは正確に3つです。

Level one: locally countする。 js-tiktoken はPythonの tiktoken と同じBPE merge tableを同梱しているため、OpenAI encodingではnetwork callなしにbyte-for-byteで同一のcountが得られます。

import { getEncoding } from "js-tiktoken";

const enc = getEncoding("o200k_base");
const PER_MESSAGE = 4;   // role and delimiters added by the chat template
const PER_REPLY = 3;     // priming for the assistant turn

export function promptTokens(messages: { role: string; content: string }[]) {
  return messages.reduce(
    (sum, m) => sum + enc.encode(m.content).length + PER_MESSAGE, PER_REPLY);
}

2つのconstantが重要で、local countがずれる場所でもあります。tokenizeされるのはあなたのtextそのものではありません。Chapter 11 のchat templateが、まず各messageをrole markerでwrapし、それらにも料金がかかります。OpenAI chat modelsでは、messageあたり4 token、reply primingに3 tokenというのが慣用的な近似です。上の会話の81 messageでは合計324 tokenになり、会話長の6.4%です。ここでのcountは、Chapter 7のPython tiktoken と全81 stringsでcross-checkされ、完全に一致しています。

Level two: providerに聞く。 Anthropicは /v1/messages/count_tokens を、Googleは count_tokens を公開しており、どちらも実callと同じrequest shapeを受け取り、input token countを無料で返します。locally countできない場合に使ってください。そしてAnthropicではlocally countできません。tokenizerが公開されていないからです。Anthropicのdocumentationは、それが何を返しているかについて慎重です。countは「estimate」であり、「Anthropicがsystem optimizationsのために自動追加するtokensを含む場合がある」が、それらには「課金されない」としています。¹⁰

Level three: responseの usage を読む。 それが真実であり、お金を使った後に届きます。だからこそ最初の2つのlevelが存在します。請求するためではなく、requestを送るべきか判断するためです。

line itemとしては現れない4つのline itemです。

system prompt、毎callで支払い。 上のものはtemplate overhead込みで192 tokenです。40 callでは7,680 token、この会話のbill全体の5.6%です。8行を一度書いただけのものに、です。同時に、安定していて先頭にあるため、最良のcache candidateでもあります。

Tool definitions。 すべてのtoolのname、description、JSON schemaは毎requestで送られ、providerはその上にscaffoldingを追加します。Anthropicはその数値を公開しています。toolを有効にするだけで、Claude Sonnet 4.5では tool_choice を auto に設定した場合に496 tokenのhidden system promptが追加され、any またはnamed toolでは588になります。⁹ これは自分のschemaの前です。Chapter 18 はcatalogueを作ります。Chapter 24はそれが何を食うかを測ります。

破棄したものを含む、すべてのgeneration。 5回regenerateすれば5倍かかります。chatに表示されるのは1つです。

表示されないthoughts。 課金は、summaryだけが返る場合でもfull thought tokensに基づきます。そしてあなた側のaccountingでは、その数値をauditできません。

最後に1つ警告しておきます。自然な次の発想ですが、答えは見かけほど明らかではありません。

100万token windowは、100万のusable tokensを意味しません。retrieval accuracyはpositionによって低下します。Liu et al.は、modelがlong inputの先頭と末尾では情報を比較的確実に見つける一方、中央ではかなり不安定になることを見いだしました。¹¹ より大きなwindowが買うのは、より多く送れる能力であって、読まれる確実性ではありません。

この現象は、このcourseでは一度だけ測定します。同じ853-token prompt内の9つのpositionでのretrieval rateです。そしてそれはChapter 24に属します。agentの動作を変えるからです。ここで引用しているのは、何を買うべきかを変えるからです。最も安いtokenは、送らなかったtokenです。

これで、callする前にいくらかかるかを予測し、後で実際に何がかかったかを読み、その2つの違いを見分けられます。requestについては、まだ触っていない部分を除き、すべてを扱いました。その残りがknobsです。

Chapter 17 はsamplingです。temperature、top-p、top-k、penalties、そして存在しないdeterminismを扱います。まずこの分野で最も広く見られる誤り、temperatureはcreativity dialだという考えを解体します。そうではありません。temperatureは Chapter 4 のlogitsをsoftmaxの前で割るものであり、それを上げてもmodelが想像力豊かになるわけではありません。model自身がより悪いとscoreしたtokensのprobabilityを上げるだけです。そこから、なぜgreedy decodingがsamplingより測定可能に悪いtextを生むのか、なぜtop-kとtop-pがdistributionの反対の形で失敗するのか、そして章末の実験へ進みます。temperature 0で20回の同一forward passを行うと、modelが単独で走る場合はbit-for-bitで同一の結果が返ります。しかし同じpromptを他人のrequestと同じbatchに入れると、そのlogitsの97%が動きます。

すべてが一致するわけではありません。その理由は Chapter 2 のfloating-point boxから始まります。

この章のすべてのprices、thresholds、multipliersは、2026年9月6日 にprovider自身のpageから読んだものです。変わるため、その日付とともに記載しています。数字よりmethodが重要です。bucket、prefix rule、tier arithmeticは2年間安定していましたが、その中の数値はすべて動いてきました。

Stanford CS336 lecture 2、Resource accounting は、このmaterialに最も近いacademic treatmentであり、次に読むべきものです。この章がinference側で行ったのと同じ算術を、training側で行っています。ここでのtoken countsは、js-tiktoken 1.0.21を使い、o200k_base と cl100k_base encodingsで、5,090 tokenの40ターン会話に対して生成しました。per-message template overheadは慣用的なfour-plus-three approximationであり、含める箇所では明記しています。cache、tier、truncationの数値は、これらの実測token countにdocumented pricing rulesを適用したものであり、live API responseの観測ではありません。この章を作るために有料callは行っていません。それが、latency claimがqualitativeで、cost claimがそうでない正直な理由でもあります。