Context Window، tokenها و صورت‌حساب؛ با عدد و اندازه‌گیری

گران‌ترین سوءبرداشت در این کسب‌وکار این است که مدل یک گفت‌وگو را به خاطر می‌سپارد.

این‌طور نیست، و مکانیزم فصل 13 دقیقاً می‌گوید چرا. وضعیت یک transformer هنگام generation همان KV cache است: کلیدها و مقدارهایی که برای هر token در دنباله محاسبه شده‌اند. این cache فقط برای مدت یک request زنده است. وقتی request تمام می‌شود، فرایندی که آن را نگه داشته آزاد است به شخص دیگری سرویس بدهد، و cache از بین می‌رود. آن طرف هیچ ذخیرهٔ per-user و هیچ sessionی وجود ندارد.

پس request بعدی باید همراه با هر چیزی برسد که مدل قرار است بداند، و مدل پیش از آنکه حتی یک token تازه منتشر کند، با اجرای یک forward pass روی کل prompt آن وضعیت را از نو می‌سازد. فصل 15 prompt را «کل وضعیت» نامید. دلیل فیزیکی‌اش این است: prompt وضعیت کامل است، چون هیچ چیز دیگری از call جان سالم به در نمی‌برد.

context window حداکثر طول آن prompt به‌علاوهٔ پاسخ آن است. سقفی است برای اینکه چقدر وضعیت می‌توانید از نو بسازید، نه ظرفی که چیزی را بین requestها نگه دارد. نامیدن آن به «حافظهٔ مدل» جهت علیت را برعکس می‌کند — شما حافظه‌ای را پر نمی‌کنید، دارید برای بازبرقرار کردن آن پول می‌دهید.

عدد بیست‌ودو از همین‌جا می‌آید. نوبت $n$ همهٔ $n-1$ نوبت قبلی را حمل می‌کند، پس کل input در یک گفت‌وگوی $n$ نوبتی برابر مجموع یک سریِ رو‌به‌رشد است، که درجه‌دو می‌شود:

که در آن $s$ system prompt است و $h_i$ تاریخچه در نوبت $i$. برازش input تجمعیِ اندازه‌گیری‌شده به $an^2 + bn$ در طول چهل نوبت، $60.22\,n^2 + 432.25\,n$ می‌دهد؛ این مقدار برای نوبت 40 عدد 113,645 token را پیش‌بینی می‌کند، در برابر 112,617 اندازه‌گیری‌شده. جملهٔ درجه‌دو غالب است و جملهٔ خطی همان چیزی است که کاربر واقعاً تایپ کرده.

نتیجه، جمله‌ای است که باید از این فصل با خود ببرید: صورت‌حساب شما با مربع طول گفت‌وگو رشد می‌کند، نه با پرسش آخر. همان چهل پرسش اگر بدون هیچ history پرسیده می‌شدند $0.066036 هزینه داشتند. نگه داشتن history هزینه را به $0.274386 رساند. History صورت‌حساب را 4.2 برابر کرد، و همچنان به ضرب کردن ادامه می‌دهد، چون ضریب همان طول گفت‌وگو است.

Window به دو دلیل هم‌جهت محدود است. دلیل اول همان دلیل فصل 9 است: attention هر token را با هر token دیگر مقایسه می‌کند، بنابراین کار آن لایه با مربع طول دنباله رشد می‌کند. دلیل دوم حافظه است: KV cache با طول دنباله خطی رشد می‌کند، و فصل 13 این حساب را انجام داد — در دنباله‌های بلند، از وزن‌ها هم بزرگ‌تر می‌شود.

به هر دو محدودیت حمله شده و هیچ‌کدام حذف نشده‌اند. FlashAttention¹ محاسبه را طوری بازآرایی می‌کند که خواندن و نوشتن بسیار کمتری روی حافظهٔ با پهنای‌باند بالا انجام شود؛ این کار دنباله‌های بلند را بدون تغییر هزینهٔ مجانبی عملی می‌کند. Position Interpolation² و YaRN³ با بازتنظیم positional encodingهای فصل 9، به‌جای آموزش دوباره، window قابل‌استفادهٔ یک مدل آموزش‌دیده را گسترش می‌دهند. این‌ها با هم دلیل‌اند که windowها در پنج سال از 2K به 1M رسیدند.

کاری که نکردند رایگان کردن contextهای بلند بود. سقف را بالاتر بردند و شیب را ملایم‌تر کردند. شیب هنوز وجود دارد، و همان چیزی است که tierهای قیمت در ادامهٔ این فصل اندازه می‌گیرند.

تقریباً هر ماشین‌حساب هزینه در اینترنت یک API call را به‌صورت input tokens ضرب‌در قیمت input به‌علاوهٔ output tokens ضرب‌در قیمت output مدل می‌کند. این در سال 2023 درست بود. حالا به‌شکلی غلط است که صورت‌حساب‌ها را در هر دو جهت با ضریب دو یا بیشتر از واقعیت دور می‌کند.

پنج دستهٔ token قابل‌صورت‌حساب وجود دارد:

سه مورد از این پنج مورد دو سال پیش به‌صورت line جدا وجود نداشتند، و دو خط cache همان‌هایی‌اند که مردم اشتباه می‌گیرند، چون cache write بیشتر از input معمولی هزینه دارد، نه کمتر. شما برای ذخیره کردن چیزی premium می‌پردازید تا بعداً برای خواندن دوباره‌اش discount بگیرید، و اینکه این معامله خوب باشد کاملاً به تعداد دفعاتی بستگی دارد که آن را می‌خوانید.

سبد reasoning متعلق به فصل 12 است، حالا با قیمت روی آن، و نکته‌ای دارد که باید صریح گفته شود: مستندات Google می‌گوید pricing «بر اساس همهٔ thought tokenهایی است که مدل برای generate کردن نیاز دارد، هرچند فقط summary از API خروجی داده می‌شود.»⁴ شما برای tokenهایی صورت‌حساب می‌شوید که هرگز به شما منتقل نمی‌شوند. این تنها سبدی است که محتویاتش را نمی‌توانید بشمارید، inspect کنید یا verify کنید.

حالا بخشی که این را به مسئلهٔ normalisation تبدیل می‌کند، نه مسئلهٔ multiplication. هر provider این bucketها را با نام‌های متفاوت گزارش می‌کند، و — این تله است — دو تای آن‌ها از یک واژه برای دو کمیت متفاوت استفاده می‌کنند.

یک call را در نظر بگیرید: 4,837 token خوانده‌شده از cache، 110 token تازه، 142 output token قابل‌مشاهده، 300 reasoning token.

// 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 شمارش input token برای همان prompt هستند. عدد OpenAI شامل tokenهای cached است؛ عدد Anthropic آن‌ها را مستثنا می‌کند — مستنداتش identity را صریح بیان می‌کند، total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ مقدار input_tokens در Anthropic یعنی «tokenهای بعد از آخرین cache breakpoint شما».

و به output نگاه کنید. OpenAI و Anthropic هر دو 442 گزارش می‌کنند، که همین حالا 300 reasoning token را در خود دارد. Gemini عدد 142 را گزارش می‌کند و 300 را در field جداگانهٔ خودش می‌گذارد. فصل 12 این را به‌عنوان ناسازگاری بین دو روش شمارش یک کار واحد علامت‌گذاری کرد؛ اینجا می‌بینید هزینه‌اش چیست.

یک normaliser سی خط است و اختیاری نیست:

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

سه payload بالا را از سه reader عبور دهید و هر سه همان Usage را تولید می‌کنند، و بنابراین همان عدد را: $0.006491. کل هدف نوشتن این لایه همین توافق است.

اگر اشتباه کنید، روی همان call این‌قدر هزینه دارد:

سومی خطرناک است، چون بی‌صدا و در جهت خبر خوب fail می‌کند. داشبورد شما نشان می‌دهد یک reasoning model کمتر از نصف هزینهٔ واقعی‌اش هزینه دارد، و هیچ‌جا هیچ errorی بالا نمی‌آید.

وقتی bucketها normalised شدند، cost function کوتاه است. تنها بخش غیرآشکار tier lookup است، که بخش بعد توضیح می‌دهد:

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

دو تصمیم طراحی در آنجا ارزش دفاع کردن دارند. fallbackها — قیمت‌های cache که به input برمی‌گردند، و reasoning که به output برمی‌گردد — معنای یک جدول ناقص را encode می‌کنند: reasoning tokenها در Gemini با نرخ output صورت‌حساب می‌شوند، پس نبودن قیمت reasoning صفر نیست، قیمت output است. و contextSize هر سه bucket ورودی را جمع می‌کند، نه فقط freshها را، چون tier بر اساس طول prompt انتخاب می‌شود، نه بر اساس اینکه از چه مقدار آن full price گرفته شده.

prompt cache وضعیت محاسبه‌شدهٔ مدل را برای یک prefix از prompt شما ذخیره می‌کند، تا request بعدی با همان prefix از محاسبهٔ دوبارهٔ آن عبور کند. چهار ویژگی از واژهٔ «prefix» نتیجه می‌شود و هر چهار مورد مردم را غافلگیر می‌کنند.

break-even آن‌قدر کوچک است که می‌شود در ذهن نگه داشت، و مستندات OpenAI خودش حساب را انجام می‌دهد: یک‌بار نوشتن prefix و یک‌بار reuse کردنش 1.35× هزینهٔ input معمولی آن را دارد، در برابر 2× برای پردازش دوبارهٔ آن بدون cache؛ در ده request، یک write و نه read برابر 2.15× هزینه دارد، در برابر 10×. یک reuse هزینهٔ write را جبران می‌کند. Anthropic هم به همان‌جا می‌رسد: یک read برای cache پنج‌دقیقه‌ای، دو read برای cache یک‌ساعته.

حالا دوباره همان گفت‌وگوی چهل‌نوبتی، با caching روشن و prefix پایدار:

شصت‌وهشت درصد ارزان‌تر، و سه عدد در این جدول ارزش توجه دارند.

cache تا نوبت 6 فعال نمی‌شود. prompt تا آن موقع به 1,024 token نمی‌رسد، پس پنج نوبت اول دقیقاً مثل قبل صورت‌حساب می‌شوند — و ششم بدتر صورت‌حساب می‌شود، با premium نوشتن 1.25×، چون همان نوبتی است که cache را پر می‌کند. اولین read در نوبت 7 می‌آید. عدد 2,887 uncached token در جدول همین حساب است: ارزش پنج نوبت، نه شش نوبت. Caching discount روی promptهای بلند است، و گفت‌وگوی کوتاه چیزی از آن نمی‌گیرد.

premium نوشتن $0.002474 است، یعنی 2.8٪ از صورت‌حساب cached. هر نوبت tail تازهٔ خودش را می‌نویسد، چهل بار، و کل premium نوشتن در برابر چیزی که readها ذخیره کردند خطای گرد کردن است. ارزش دارد write charge را دقیق بفهمید تا دیگر نگرانش نباشید.

فقط 2,887 token با قیمت کامل input charge شد از 112,617. شکل یک cache سالم همین است: تقریباً همه چیز read است.

اینجا failureی است که پول واقعی هزینه می‌کند، و یک باگ یک‌خطی است.

چیزی را که در هر call تغییر می‌کند نزدیک ابتدای prompt بگذارید — timestamp، request id، نام کاربر، یک خط «امروز ... است»، یک سند تازه retrieve‌شده — و prefix از byte اول متفاوت می‌شود. هیچ چیز match نمی‌شود. هر call یک miss است. و چون هر call یک prefix جدید ارائه می‌کند، هر call همچنین می‌نویسد.

همان گفت‌وگو، همان چهل نوبت، caching روشن، با timestamp مخصوص هر call در بالای system prompt:

روشن کردن prompt caching گفت‌وگو را بیست درصد گران‌تر از روشن نکردنش کرد. شما premium نوشتن 1.25× را روی 109,730 token پرداخت کردید و صفر read گرفتید. هیچ error، هیچ warning، و feature روشن است.

پس rule، و کل prompt caching در یک خط، این است: محتوای پایدار جلو، محتوای متغیر عقب. ابتدا system instructions، tool definitions و reference material؛ timestampها، user identity و پرسش فعلی در آخر. Anthropic سلسله‌مراتب را صریح می‌کند — cache از tools → system → messages پیروی می‌کند، و تغییر در هر سطح همان سطح و همهٔ بعد از آن را invalid می‌کند، پس ویرایش یک tool description واحد کل cache را invalid می‌کند.⁵

دو پیامد هست که مردم در آن گیر می‌کنند. تغییر اینکه کدام tools enabled هستند tool definitions را تغییر می‌دهد، پس feature flagی که برای بعضی کاربران tool اضافه می‌کند cache شما را دو قسمت می‌کند. و در Anthropic، روشن و خاموش کردن web search یا citations system prompt را تغییر می‌دهد، که بدون دست زدن شما به یک خط از متن خودتان، system و message cacheها را invalid می‌کند.

پاسخ بدیهی به صورت‌حساب درجه‌دو این است که ارسال کل history را متوقف کنید: دوازده message آخر را نگه دارید و بقیه را بیندازید. این کار صورت‌حساب را کم می‌کند، و معمولاً حرکت اشتباهی است، و اندازه‌گیری می‌گوید چرا.

Truncate کردن به یک window دوازده‌messageی 57٪ ارزان‌تر از ارسال همه‌چیز بدون cache است — مقایسه‌ای که همه انجام می‌دهند و دلیل محبوبیت تکنیک. اما 39٪ گران‌تر از ارسال همه‌چیز با cache سالم است، و روشن کردن caching کنار truncation آن را کمی بدتر می‌کند، نه بهتر.

mechanism دوباره همان prefix است. sliding window در هر نوبت قدیمی‌ترین message را حذف می‌کند، پس prompt دیگر از همان‌جایی شروع نمی‌شود که دفعهٔ قبل شروع شده بود و هر نوبت prefix تازه‌ای ارائه می‌کند. راهنمای OpenAI دقیقاً همین را می‌گوید: «summarisation، compaction یا context truncation می‌تواند prefix را تغییر دهد و cache reuse را reset کند.»⁶ تا نوبت 40، prompt پنجره‌ای 813 token است، کمتر از حداقل 1,024-token، پس اصلاً نمی‌تواند cache شود.

و پول، نیمهٔ ارزان هزینه است. چیزی که حذف کردید instructionی است که کاربر در نوبت 2 داده بود و مدل در نوبت 40 به آن نیاز داشت. Truncation صورت‌حسابی را که می‌بینید با failureی که نمی‌بینید معاوضه می‌کند، و درست انجام دادنش — compaction، یادداشت‌های structured بیرون از window، retrieve کردن history بر اساس نیاز — موضوع فصل 24 است.

contextهای بلند فقط به این دلیل گران‌تر نیستند که بلندترند. بعد از یک threshold، به‌ازای هر token گران‌تر می‌شوند، و threshold به‌صورت retroactive روی کل prompt اعمال می‌شود.

صفحهٔ مدل OpenAI برای gpt-5.6-terra در یک جمله می‌گوید: «Promptهایی با بیش از 272K input token برای کل request با 2x input و 1.5x output قیمت‌گذاری می‌شوند.»⁷ نه فقط برای مازاد. برای کل چیز.

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

یک token، پنجاه‌وپنج سنت. اگر سرویس شما promptها را از اسناد retrieve‌شده‌ای می‌سازد که اندازه‌شان در کنترل شما نیست، در cost model خودتان یک پرتگاه دارید در مرزی که هیچ‌کس در تیم شما جایی ننوشته است.

قیمت‌گذاری Google هم با threshold 200,000-token همین‌طور کار می‌کند: Gemini 2.5 Pro برای promptهای تا 200K برابر $1.25 به‌ازای هر میلیون input token است و بالاتر از آن $2.50، و output از $10.00 به $15.00 می‌رود.⁸ Anthropic مسیر دیگری رفت — تا 6 سپتامبر 2026، مستنداتش می‌گوید Claude 4.6 و بعد از آن کل window یک‌میلیون-token را با قیمت استاندارد شامل می‌شوند، بنابراین «یک request 900k-token با همان نرخ per-token یک request 9k-token صورت‌حساب می‌شود.»⁹ مدل‌های قدیمی‌تر surcharge را نگه داشتند.

برای همین price یک عدد نیست. price جدولی از tierهاست که با طول prompt کلید می‌شود، و Tier[] در cost function برای همین است، و به همین دلیل computeCost tier را با کل prompt انتخاب می‌کند، نه هر bucket به‌صورت جداگانه.

پنج bucket روی دو فاز فصل 13 map می‌شوند، و وقتی mapping را ببینید نسبت‌های قیمت دیگر دل‌بخواهی به نظر نمی‌رسند.

Input tokenها prefill هستند. کل prompt در یک pass از مدل عبور می‌کند، به‌صورت parallel پردازش می‌شود — ضرب‌های ماتریسی بزرگ، compute-bound. هزینه به‌ازای هر token پایین است، و این همان فازی است که time to first token را تعیین می‌کند: یک prompt با 4,947 token باید 4,947 token prefill انجام دهد پیش از آنکه اولین کلمه ظاهر شود.

Output tokenها decode هستند. آن‌ها یکی‌یکی تولید می‌شوند، هر کدام یک forward pass کامل که کل KV cache را می‌خواند، در حالی که GPU بیشتر منتظر حافظه است تا مشغول محاسبه. این همان فازی است که tokens per second را تعیین می‌کند، درون یک response قابل parallel شدن نیست، و دلیل این است که output روی مدلی که اینجا قیمت‌گذاری شده حدود شش برابر input هزینه دارد: $12.00 در برابر $2.00 به‌ازای هر میلیون token.

سه پیامد مستقیم دارد. cache read جایگزین کار prefill می‌شود، پس هم‌زمان latency و پول می‌خرد — همان discount به‌صورت صورت‌حساب کمتر و انتظار کوتاه‌تر برای first token ظاهر می‌شود. Reasoning tokenها decodeی هستند که هرگز نمی‌بینید، برای همین reasoning model چند ثانیه هیچ چیز stream نمی‌کند و بعد سریع جواب می‌دهد: فصل 12 دربارهٔ پیامد interface هشدار داد، و اینجا پیامد invoice آن است. و abort کردن stream generation را متوقف نمی‌کند — فصل 14 cancellation را ساخت و قیمت را به این فصل واگذار کرد، و قیمت همان output count کامل است، چون tokenها تولید و صورت‌حساب می‌شوند چه کسی گوش بدهد چه ندهد. پاسخ‌هایی که کسی نگه نمی‌دارد هم همین‌اند: regenerate کردن پاسخ نوبت 40 پنج بار، برای همان یکی که روی صفحه می‌ماند $0.057990 هزینه دارد.

tokenizer فصل 7 Python بود و همان‌جا ماند. Budgeting در serverی اتفاق می‌افتد که request را می‌سازد، پس باید اینجا انجام شود، و دقیقاً سه سطح accuracy در دسترس است.

سطح یک: محلی بشمارید. js-tiktoken همان BPE merge tableهای tiktoken در Python را دارد، بنابراین برای encodingهای OpenAI شمارشی byte-for-byte identical، بدون 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);
}

دو constant مهم‌اند و همان‌جایی‌اند که شمارش‌های محلی drift می‌کنند. متن شما آن چیزی نیست که tokenize می‌شود — chat template فصل 11 ابتدا هر message را در role markerها wrap می‌کند، و آن‌ها tokenهایی هستند که بابتشان پول می‌دهید. چهار token به‌ازای هر message و سه token برای reply priming تقریب رایج برای مدل‌های chat در OpenAI است؛ در طول هشتاد و یک message گفت‌وگوی بالا، جمعاً 324 token می‌شود، یعنی 6.4٪ طول آن. شمارش‌های اینجا با tiktoken در Python از فصل 7 روی همهٔ هشتاد و یک string cross-check شدند و identical هستند.

سطح دو: از provider بپرسید. Anthropic، /v1/messages/count_tokens را expose می‌کند و Google، count_tokens را؛ هر دو همان شکل request یک call واقعی را می‌پذیرند و یک شمارش input token رایگان برمی‌گردانند. وقتی نمی‌توانید محلی بشمارید از آن‌ها استفاده کنید — و برای Anthropic نمی‌توانید محلی بشمارید، چون tokenizer آن published نیست. مستندات Anthropic دربارهٔ چیزی که می‌دهد محتاط است: count «یک estimate» است، و «ممکن است tokenهایی را شامل شود که Anthropic برای system optimizations به‌طور خودکار اضافه می‌کند»، که «برای آن‌ها صورت‌حساب نمی‌شوید».¹⁰

سطح سه: usage را در response بخوانید. حقیقت همان است، و بعد از خرج شدن پول می‌رسد. دقیقاً برای همین دو سطح اول وجود دارند — برای تصمیم اینکه request را بفرستید یا نه، نه برای bill کردن آن.

چهار line item که به‌صورت line item ظاهر نمی‌شوند.

system prompt، در هر call پرداخت می‌شود. مورد بالا با template overhead خودش 192 token است. در چهل call می‌شود 7,680 token — 5.6٪ از کل صورت‌حساب این گفت‌وگو، برای هشت خطی که یک‌بار نوشته شده. همچنین بهترین candidate ممکن برای cache است، چون هم stable است هم first.

Tool definitions. نام، description و JSON schema هر tool در هر request ارسال می‌شود، و providerها scaffolding هم اضافه می‌کنند. Anthropic عدد را منتشر می‌کند: صرف enabled کردن tools یک hidden system prompt با 496 token روی Claude Sonnet 4.5 اضافه می‌کند وقتی tool_choice روی auto باشد، یا 588 با any یا یک named tool.⁹ این پیش از schemaهای خودتان است. فصل 18 catalogue را می‌سازد؛ فصل 24 اندازه می‌گیرد چه می‌خورد.

هر generation، از جمله آن‌هایی که دور می‌اندازید. پنج regeneration پنج برابر هزینه دارد. chat یکی را نشان می‌دهد.

Thoughtهایی که به شما نشان داده نمی‌شوند. Billing بر اساس full thought tokens است، هرچند فقط summary برمی‌گردد، و هیچ accountingی از سمت شما نمی‌تواند آن عدد را audit کند.

یک warning برای پایان، چون فکر طبیعی بعدی همین است و پاسخ آن جواب بدیهی نیست.

window یک‌میلیون-token به‌معنای یک‌میلیون token قابل‌استفاده نیست. دقت retrieval با position افت می‌کند: Liu و همکاران دریافتند مدل‌ها اطلاعات را در ابتدا و انتهای input بلند reliably پیدا می‌کنند و در میانه بسیار کمتر reliably.¹¹ window بزرگ‌تر توانایی ارسال بیشتر را می‌خرد، نه قطعیت خوانده شدن.

این پدیده یک‌بار در این دوره اندازه‌گیری شده — نرخ retrieval در نه position در همان prompt با 853 token — و جای آن در فصل 24 است، جایی که کاری را که یک agent انجام می‌دهد تغییر می‌دهد. اینجا cite شده چون چیزی را که باید بخرید تغییر می‌دهد: ارزان‌ترین token همان tokenی است که نفرستادید.

حالا می‌توانید پیش از انجام یک call هزینه‌اش را predict کنید، بعد از آن هزینهٔ واقعی‌اش را بخوانید، و تفاوت این دو را تشخیص دهید. این همهٔ request را پوشش می‌دهد، جز بخشی که هنوز لمس نکرده‌اید: knobها.

فصل 17 sampling است — temperature، top-p، top-k، penaltyها، و determinismی که ندارید. با dismantle کردن رایج‌ترین خطای این حوزه شروع می‌کند: اینکه temperature یک creativity dial است. نیست: temperature مقدار logitها از فصل 4 را پیش از softmax تقسیم می‌کند، و بالا بردنش مدل را imaginative نمی‌کند؛ احتمال tokenهایی را بالا می‌برد که خود مدل بدتر score کرده. از آنجا، اینکه چرا greedy decoding متنی measurably بدتر از sampling تولید می‌کند، چرا top-k و top-p روی شکل‌های مخالف distribution شکست می‌خورند، و آزمایشی که فصل را تمام می‌کند: بیست forward pass identical در temperature 0 وقتی مدل تنها اجرا می‌شود bit-for-bit identical برمی‌گردند، و گذاشتن همان prompt در یک batch کنار requestهای دیگران 97٪ از logitهایش را جابه‌جا می‌کند.

همه‌شان match نمی‌شوند. دلیلش با کادر floating-point از فصل 2 شروع می‌شود.

همهٔ priceها، thresholdها و multiplierهای این فصل در 6 سپتامبر 2026 از صفحه‌های خود providerها خوانده شده‌اند و با همین تاریخ بیان می‌شوند چون تغییر خواهند کرد. روش از اعداد مهم‌تر است: bucketها، rule مربوط به prefix و arithmetic مربوط به tierها دو سال پایدار بوده‌اند، در حالی که هر عدد داخلشان جابه‌جا شده است.

سخنرانی 2 از Stanford CS336، Resource accounting، نزدیک‌ترین treatment آکادمیک این material است و next read درست: همان arithmetic را در سمت training انجام می‌دهد که این فصل در سمت inference انجام می‌دهد. token countهای اینجا با js-tiktoken نسخهٔ 1.0.21 و با encodingهای o200k_base و cl100k_base، روی یک گفت‌وگوی چهل‌نوبتی با 5,090 token تولید شدند؛ per-message template overhead همان تقریب رایج چهار-به‌علاوه-سه است و هرجا شامل شده بیان شده. ارقام cache، tier و truncation حاصل اعمال ruleهای documented pricing روی آن token countهای اندازه‌گیری‌شده‌اند، نه observation از live API responseها — هیچ paid callی برای تولید این فصل انجام نشده، و این همچنین دلیل صادقانهٔ آن است که ادعاهای latency کیفی‌اند و ادعاهای cost نه.