Context Window, Tokens और बिल: माप के साथ

इस business में सबसे महँगी गलतफहमी यह है कि model बातचीत को याद रखता है।

ऐसा नहीं है, और Chapter 13 का mechanism ठीक-ठीक बताता है क्यों। generation के दौरान transformer की state KV cache होती है: sequence के हर token के लिए compute किए गए keys और values। वह cache एक request की अवधि तक रहता है। जब request खत्म होती है, उसे रखने वाली process किसी और को serve करने के लिए free होती है, और cache चला जाता है। दूसरी तरफ कोई per-user store नहीं है, और कोई session नहीं।

इसलिए अगली request को वह सब कुछ साथ लेकर आना पड़ता है जो model को पता होना चाहिए, और model एक भी नया token emit करने से पहले पूरे prompt पर forward pass चलाकर उस state को फिर से बनाता है। Chapter 15 ने prompt को "पूरी state" कहा था। भौतिक कारण यह है: prompt पूरी state है क्योंकि call के बाद कुछ और बचता ही नहीं।

context window उस prompt plus उसके answer की अधिकतम लंबाई है। यह इस बात की ceiling है कि आप कितनी state rebuild कर सकते हैं, ऐसा container नहीं जो requests के बीच कुछ hold करता हो। इसे "model की memory" कहना causality की दिशा उलट देता है — आप memory भर नहीं रहे हैं, आप उसे फिर से स्थापित करने का भुगतान कर रहे हैं।

बाईस यहीं से आता है। Turn $n$ अपने साथ पिछले सभी $n-1$ turns ले जाता है, इसलिए $n$ turns की बातचीत में कुल input एक बढ़ती हुई series का sum है, जो quadratic है:

जहाँ $s$ system prompt है और $h_i$ turn $i$ पर history है। चालीस turns पर measured cumulative input को $an^2 + bn$ पर fit करने से $60.22\,n^2 + 432.25\,n$ मिलता है, जो turn 40 पर 112,617 measured के विरुद्ध 113,645 tokens predict करता है। quadratic term dominate करता है और linear term वह है जो user ने सच में type किया।

इस chapter से याद रखने वाली बात यह है: आपका bill बातचीत के square के साथ बढ़ता है, आखिरी सवाल के साथ नहीं। वही चालीस सवाल अगर बिल्कुल history के बिना पूछे जाएँ तो $0.066036 लगते। history रखने पर $0.274386 लगा। History ने bill को 4.2 से multiply किया, और यह multiply करता रहेगा, क्योंकि multiplier बातचीत की लंबाई है।

window finite है, दो कारणों से जो एक ही दिशा में खींचते हैं। पहला Chapter 9 वाला है: attention हर token की तुलना हर दूसरे token से करता है, इसलिए उस layer का work sequence length के square के साथ बढ़ता है। दूसरा memory है: KV cache sequence length के साथ linearly बढ़ता है, और Chapter 13 ने वह arithmetic किया था — लंबे sequences पर यह weights से बड़ा हो जाता है।

दोनों limits पर हमला हुआ है और दोनों में से कोई हटाई नहीं गई। FlashAttention¹ computation को इस तरह reorganise करता है कि यह high-bandwidth memory में बहुत कम read और write करे, जिससे asymptotic cost बदले बिना लंबे sequences practical बनते हैं। Position Interpolation² और YaRN³ Chapter 9 के positional encodings को rescale करके trained model की usable window बढ़ाते हैं, retrain करके नहीं। इसी वजह से windows पाँच साल में 2K से 1M हो गईं।

उन्होंने long contexts को free नहीं बनाया। उन्होंने ceiling ऊँची की और slope को नरम किया। slope अभी भी है, और इस chapter में आगे के price tiers उसी को माप रहे हैं।

Internet पर लगभग हर cost calculator API call को input tokens × input price plus output tokens × output price मानता है। 2023 में यह सही था। अब यह इस तरह गलत है कि दोनों दिशाओं में bills दो गुना या उससे अधिक तक चूक जाते हैं।

पाँच billable token categories हैं:

इन पाँच में से तीन दो साल पहले अलग lines के रूप में मौजूद नहीं थे, और दो cache lines वही हैं जहाँ लोग गलती करते हैं, क्योंकि cache write ordinary input से ज्यादा cost करता है, कम नहीं। आप कुछ store करने के लिए premium देते हैं ताकि उसे वापस पढ़ते समय discount दे सकें, और यह trade अच्छा है या नहीं पूरी तरह इस पर निर्भर है कि आप उसे कितनी बार पढ़ते हैं।

reasoning bucket Chapter 12 वाला है, अब उस पर price लगा है, और इसमें एक detail साफ-साफ कहने लायक है: Google की documentation कहती है pricing "is based on the full thought tokens the model needs to generate, despite only the summary being output from the API."⁴ आप उन tokens के लिए billed होते हैं जो आपको कभी transmit नहीं किए जाते। यह इकलौता bucket है जिसकी contents आप count, inspect या verify नहीं कर सकते।

अब वह हिस्सा जो इसे multiplication problem के बजाय normalisation problem बनाता है। हर provider इन buckets को अलग names के तहत report करता है, और — यही trap है — उनमें से दो अलग quantities के लिए वही word use करते हैं।

एक call लीजिए: cache से पढ़े गए 4,837 tokens, 110 fresh, 142 visible output tokens, 300 reasoning tokens।

// 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 को देखिए। दोनों fields same prompt के input token count हैं। OpenAI के count में cached tokens शामिल हैं; Anthropic के count में वे शामिल नहीं हैं — इसकी documentation identity को explicitly बताती है, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Anthropic का input_tokens मतलब है "आपके last cache breakpoint के बाद के tokens"।

और output को देखिए। OpenAI और Anthropic दोनों 442 report करते हैं, जिसमें पहले से 300 reasoning tokens शामिल हैं। Gemini 142 report करता है और 300 को अपने अलग field में रखता है। Chapter 12 ने इसे same work को count करने के दो तरीकों के बीच incompatibility के रूप में flag किया था; यहाँ उसका cost है।

normaliser तीस lines का है और optional नहीं है:

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
  };
};

ऊपर के तीन payloads को तीन readers से चलाइए और तीनों वही Usage produce करते हैं, और इसलिए वही number: $0.006491। layer लिखने का पूरा point यही agreement है।

इसे गलत कीजिए और वही call कितना cost करेगा:

तीसरा dangerous है, क्योंकि यह good news की दिशा में silently fail करता है। आपका dashboard reasoning model को उसकी actual cost के आधे से भी कम पर दिखाता है, और कहीं कोई error नहीं उठता।

buckets normalise होने के बाद cost function छोटा है। केवल non-obvious हिस्सा 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);
}

वहाँ दो design decisions के लिए argument करना चाहिए। fallbacks — cache prices का input पर fallback, reasoning का output पर — यह encode करते हैं कि missing table का अर्थ क्या है: Gemini पर reasoning tokens output rate पर billed होते हैं, इसलिए absent reasoning price zero नहीं, output price है। और contextSize तीनों input buckets को sum करता है, fresh ones को नहीं, क्योंकि tier इस बात से चुना जाता है कि prompt कितना लंबा है, इस बात से नहीं कि उसमें से कितना full price पर charge हुआ।

prompt cache आपके prompt के prefix के लिए model की computed state store करता है, ताकि same prefix वाली later request उसे recompute करना skip कर दे। "prefix" word से चार properties निकलती हैं और चारों लोगों को चौंकाती हैं।

break-even इतना छोटा है कि दिमाग में रखा जा सकता है, और OpenAI की documentation arithmetic कर देती है: prefix को एक बार write करके एक बार reuse करने की cost उसकी ordinary input cost की 1.35× है, जबकि उसे दो बार uncached process करने की cost 2× है; दस requests में, one write और nine reads की cost 2.15× है, 10× के विरुद्ध। एक reuse write का खर्च निकाल देता है। Anthropic भी वहीं पहुँचता है: five-minute cache के लिए one read, one-hour cache के लिए two।

अब वही चालीस-turn conversation, caching on और prefix stable के साथ:

अड़सठ प्रतिशत सस्ता, और उस table में तीन numbers ध्यान के लायक हैं।

cache turn 6 तक engage नहीं करता। prompt तब तक 1,024 tokens तक नहीं पहुँचता, इसलिए पहले पाँच turns बिल्कुल पहले जैसे billed होते हैं — और छठा worse billed होता है, 1.25× write premium पर, क्योंकि वही turn cache भरता है। पहला read turn 7 पर आता है। table में 2,887 uncached tokens का arithmetic यही है: पाँच turns का, छह नहीं। Caching long prompts पर discount है, और short conversation को इससे कुछ नहीं मिलता।

write premium $0.002474 है, जो cached bill का 2.8 % है। हर turn अपनी नई tail लिखता है, चालीस बार, और पूरा write premium reads ने जो बचाया उसके मुकाबले rounding error है। write charge को precisely समझना इसलिए worth है ताकि आप इसके बारे में चिंता बंद करें।

112,617 में से केवल 2,887 tokens full input price पर charge हुए। working cache का shape यही है: लगभग सब कुछ read है।

यह failure असली पैसा cost करता है, और यह one-line bug है।

prompt के front के पास कुछ ऐसा रखिए जो हर call पर बदलता है — timestamp, request id, user का नाम, "today is" line, freshly retrieved document — और prefix byte one से ही अलग हो जाता है। कुछ match नहीं करता। हर call miss है। और क्योंकि हर call novel prefix present करता है, हर call write भी करता है।

वही conversation, वही चालीस turns, caching enabled, system prompt के top पर per-call timestamp के साथ:

prompt caching enable करने से conversation, उसे enable न करने की तुलना में बीस प्रतिशत ज्यादा महँगी हो गई। आपने 109,730 tokens पर 1.25× write premium दिया और zero वापस पढ़ा। कोई error नहीं, कोई warning नहीं, और feature switched on है।

तो rule, और एक line में prompt caching का पूरा सार: stable content आगे, variable content पीछे। System instructions, tool definitions और reference material पहले; timestamps, user identity और current question last। Anthropic hierarchy explicit बनाता है — cache tools → system → messages follow करता है, और किसी level पर change उस level और उसके बाद सब कुछ invalidate कर देता है, इसलिए एक single tool description edit करना entire cache invalidate कर देता है।⁵

दो consequences हैं जिन पर लोग अटकते हैं। कौन-से tools enabled हैं यह बदलना tool definitions बदलता है, इसलिए कोई feature flag जो कुछ users के लिए tool जोड़ता है आपका cache दो भागों में split कर देता है। और Anthropic पर web search या citations toggle करना system prompt modify करता है, जो system और message caches को invalidate कर देता है, भले आप अपने text की एक line न छुएँ।

quadratic bill पर obvious response है पूरी history भेजना बंद करना: last dozen messages रखें और बाकी drop कर दें। इससे bill घटता है, और यह आम तौर पर wrong move है, और measurement बताता है क्यों।

twelve-message window तक truncate करना सब कुछ uncached भेजने से 57 % सस्ता है — वही comparison जो हर कोई करता है, और इसी वजह से technique popular है। लेकिन working cache के साथ सब कुछ भेजने की तुलना में यह 39 % ज्यादा महँगा है, और truncation के साथ caching on करना इसे बेहतर नहीं बल्कि थोड़ा worse बनाता है।

mechanism फिर prefix है। sliding window हर turn पर oldest message drop करती है, इसलिए prompt अब वहाँ से शुरू नहीं होता जहाँ पिछली बार शुरू हुआ था और हर turn नया prefix present करता है। OpenAI की guidance ठीक यही कहती है: "summarisation, compaction, or context truncation can change the prefix and reset cache reuse."⁶ turn 40 तक windowed prompt 813 tokens है, 1,024-token minimum से नीचे, इसलिए इसे cache किया ही नहीं जा सकता।

और money cost का cheap half है। आपने जो drop किया वह user का turn 2 वाला instruction है जिसकी model को turn 40 पर जरूरत थी। Truncation ऐसा bill trade करता है जिसे आप देख सकते हैं, ऐसी failure के लिए जिसे आप नहीं देख सकते, और इसे properly करना — compaction, window के बाहर रखे structured notes, history को on demand retrieve करना — Chapter 24 का subject है।

Long contexts केवल इसलिए ज्यादा महँगे नहीं हैं कि वे लंबे हैं। threshold के बाद वे per token ज्यादा महँगे हैं, और threshold retroactively पूरे prompt पर apply होता है।

gpt-5.6-terra के लिए OpenAI का model page इसे एक sentence में कहता है: "Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request."⁷ excess के लिए नहीं। पूरी चीज़ के लिए।

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

एक token, पचपन cents। अगर आपकी service retrieved documents से prompts बनाती है जिनका size आप control नहीं करते, तो आपके cost model में ऐसी boundary पर cliff है जिसे आपकी team में किसी ने लिखा नहीं है।

Google pricing भी 200,000-token threshold के साथ इसी तरह काम करती है: Gemini 2.5 Pro 200K तक के prompts के लिए $1.25 per million input tokens है और उससे ऊपर $2.50, output $10.00 से $15.00 हो जाता है।⁸ Anthropic दूसरी दिशा में गया — 6 September 2026 तक इसकी documentation कहती है कि Claude 4.6 और later full one-million-token window को standard pricing में include करते हैं, इसलिए "a 900k-token request is billed at the same per-token rate as a 9k-token request."⁹ Earlier models में surcharge था।

इसीलिए price एक number नहीं है। price tiers की table है जो prompt length से keyed है, और cost function में Tier[] इसी के लिए है, और इसी वजह से computeCost हर bucket separately नहीं बल्कि whole prompt से tier select करता है।

पाँच buckets Chapter 13 के दो phases पर map होते हैं, और mapping दिखते ही price ratios arbitrary लगना बंद हो जाते हैं।

Input tokens prefill हैं। पूरा prompt एक pass में model से गुजरता है, parallel में processed — बड़े matrix multiplications, compute-bound। प्रति token cost low है, और यही phase time to first token set करता है: 4,947-token prompt में first word आने से पहले 4,947 tokens का prefill करना है।

Output tokens decode हैं। वे एक-एक करके produce होते हैं, हर एक full forward pass जो पूरे KV cache को read करता है, GPU mostly compute करने के बजाय memory की प्रतीक्षा करता है। यही phase tokens per second set करता है, इसे एक response के भीतर parallelise नहीं किया जा सकता, और इसी वजह से यहाँ priced model पर output input से लगभग छह गुना cost करता है: $12.00 बनाम $2.00 per million tokens।

तीन consequences सीधे निकलते हैं। cache read prefill work को replace करता है, इसलिए यह latency और money दोनों खरीदता है — वही discount lower bill और first token के लिए shorter wait के रूप में दिखता है। Reasoning tokens decode हैं जिन्हें आप कभी नहीं देखते, इसी वजह से reasoning model कई seconds तक कुछ stream नहीं करता और फिर जल्दी answer देता है: Chapter 12 ने interface consequence के बारे में warning दी थी, और यह invoice consequence है। और stream abort करना generation को stop नहीं करता — Chapter 14 ने cancellation बनाया और price को इस chapter के लिए छोड़ा, और price full output count है, क्योंकि tokens produce और billed होते हैं चाहे कोई सुन रहा हो या नहीं। उसी answer के लिए भी यही सच है जिसे कोई रखता नहीं: turn 40 answer को पाँच बार regenerate करने में screen पर बचे one answer के लिए $0.057990 लगते हैं।

Chapter 7 का tokenizer Python था और वहीं रहा। Budgeting उस server में होती है जो request बनाता है, इसलिए यह यहाँ होनी चाहिए, और accuracy के ठीक तीन levels उपलब्ध हैं।

Level one: locally count करें। js-tiktoken वही BPE merge tables ship करता है जो Python tiktoken, इसलिए OpenAI encodings के लिए byte-for-byte identical count, बिना network call:

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);
}

दो constants मायने रखते हैं और local counts यहीं drift करते हैं। आपका text वह नहीं है जो tokenize होता है — Chapter 11 का chat template पहले हर message को role markers में wrap करता है, और वे tokens हैं जिनके लिए आप pay करते हैं। हर message के लिए four और reply priming के लिए three OpenAI chat models के लिए conventional approximation है; ऊपर की conversation के eighty-one messages में वे 324 tokens बनते हैं, इसकी length का 6.4 %। यहाँ के counts Chapter 7 के Python tiktoken के against सभी eighty-one strings पर cross-check किए गए और identical हैं।

Level two: provider से पूछें। Anthropic /v1/messages/count_tokens expose करता है और Google count_tokens, दोनों real call जैसी same request shape accept करते हैं और free में input token count return करते हैं। इन्हें तब use करें जब आप locally count नहीं कर सकते — और Anthropic के लिए आप locally count नहीं कर सकते, जिसका tokenizer published नहीं है। Anthropic की documentation सावधानी से बताती है कि वह आपको क्या दे रही है: count "is an estimate" है, और यह "may include tokens added automatically by Anthropic for system optimizations", जिनके लिए "you are not billed".¹⁰

Level three: response में usage पढ़ें। वही truth है, और यह पैसे खर्च होने के बाद आता है। ठीक इसी वजह से पहले दो levels मौजूद हैं — request भेजनी है या नहीं decide करने के लिए, bill करने के लिए नहीं।

चार line items जो line items के रूप में appear नहीं होते।

system prompt, हर call पर paid। ऊपर वाला अपने template overhead के साथ 192 tokens है। चालीस calls में यह 7,680 tokens है — इस conversation के पूरे bill का 5.6 %, आठ lines के लिए जो एक बार लिखी गईं। यह best possible cache candidate भी है, क्योंकि stable और first दोनों है।

Tool definitions। हर tool का name, description और JSON schema हर request पर जाता है, और providers उसके ऊपर scaffolding add करते हैं। Anthropic number publish करता है: tools enable करना ही Claude Sonnet 4.5 पर tool_choice को auto set करने के साथ 496 tokens का hidden system prompt add करता है, या any या named tool के साथ 588।⁹ यह आपके own schemas से पहले है। Chapter 18 catalogue बनाता है; Chapter 24 measure करता है कि यह कितना खाता है।

हर generation, उनमें भी जिन्हें आप discard करते हैं। पाँच regenerations पाँच गुना cost करती हैं। chat एक दिखाता है।

Thoughts जो आपको नहीं दिखाए जाते। Billing full thought tokens पर based है, हालांकि केवल summary return होती है, और आपकी कोई accounting उस number को audit नहीं कर सकती।

close करने के लिए एक warning, क्योंकि natural next thought यही है और answer obvious नहीं है।

million-token window का मतलब million usable tokens नहीं है। Retrieval accuracy position के साथ degrade होती है: Liu et al. ने पाया कि models long input की शुरुआत और अंत में information reliably locate करते हैं और middle में बहुत कम reliably।¹¹ बड़ी window ज्यादा भेजने की ability खरीदती है, read होने की certainty नहीं।

इस phenomenon को इस course में एक बार measure किया गया है — same 853-token prompt में nine positions पर retrieval rate — और यह Chapter 24 में belong करता है, जहाँ यह बदलता है कि agent क्या करता है। इसे यहाँ इसलिए cite किया गया है क्योंकि यह बदलता है कि आपको क्या खरीदना चाहिए: सबसे सस्ता token वह है जिसे आपने भेजा ही नहीं।

अब आप call करने से पहले predict कर सकते हैं कि उसका cost क्या होगा, बाद में पढ़ सकते हैं कि actual cost क्या हुआ, और दोनों के बीच फर्क बता सकते हैं। यह request के बारे में सब कुछ cover करता है सिवाय उस हिस्से के जिसे आपने अभी छुआ नहीं है: knobs।

Chapter 17 sampling है — temperature, top-p, top-k, penalties, और वह determinism जो आपके पास नहीं है। यह field की सबसे widespread error dismantle करके शुरू करता है, कि temperature creativity dial है। ऐसा नहीं है: temperature Chapter 4 के logits को softmax से पहले divide करता है, और इसे raise करने से model imaginative नहीं होता, यह उन tokens की probability बढ़ाता है जिन्हें model ने खुद worse score किया था। वहाँ से, greedy decoding sampling से measurably worse text क्यों produce करता है, top-k और top-p distribution की opposite shapes पर क्यों fail करते हैं, और chapter को खत्म करने वाला experiment: temperature 0 पर बीस identical forward passes bit-for-bit identical लौटते हैं जब model अकेला चलता है, और वही prompt किसी और की requests के साथ batch में रखने से उसके 97 % logits move हो जाते हैं।

वे सब match नहीं करते। वजह Chapter 2 के floating-point box से शुरू होती है।

इस chapter में सभी prices, thresholds और multipliers providers के अपने pages से 6 September 2026 को read किए गए और उस date के साथ stated हैं क्योंकि वे बदलेंगे। method numbers से ज्यादा matter करता है: buckets, prefix rule और tier arithmetic दो साल से stable हैं जबकि उनमें हर figure move हुआ है।

Stanford CS336 lecture 2, Resource accounting, इस material का closest academic treatment है और सही next read है: यह training side पर वही arithmetic करता है जो यह chapter inference side पर करता है। यहाँ token counts js-tiktoken 1.0.21 से o200k_base और cl100k_base encodings use करके produce किए गए, 5,090 tokens की forty-turn conversation पर; per-message template overhead conventional four-plus-three approximation है और जहाँ भी include है वहाँ stated है। cache, tier और truncation figures documented pricing rules हैं जो उन measured token counts पर applied हैं, live API responses के observations नहीं — इस chapter को produce करने के लिए कोई paid call नहीं किया गया, जो यह honest reason भी है कि latency claims qualitative हैं और cost claims नहीं।