ה-context window, ה-tokens והחשבון — במדידה

הטעות היקרה ביותר בתחום הזה היא לחשוב שמודל זוכר שיחה.

הוא לא, והמנגנון מפרק 13 מסביר בדיוק למה. המצב של transformer בזמן יצירה הוא ה-KV cache: ה-keys וה-values שחושבו לכל token ברצף. ה-cache הזה חי למשך בקשה אחת. כשהבקשה מסתיימת, התהליך שהחזיק אותו פנוי לשרת מישהו אחר, וה-cache נעלם. אין בצד השני מאגר פר-משתמש, ואין session.

לכן הבקשה הבאה צריכה להגיע כשהיא נושאת כל מה שהמודל אמור לדעת, והמודל בונה מחדש את המצב הזה באמצעות forward pass על כל ה-prompt לפני שהוא פולט token חדש אחד. פרק 15 קרא ל-prompt ״כל המצב״. זו הסיבה הפיזית: ה-prompt הוא המצב המלא כי שום דבר אחר לא שורד את הקריאה.

ה-context window היא האורך המקסימלי של ה-prompt הזה יחד עם התשובה שלו. היא תקרה לכמות המצב שאפשר לבנות מחדש, לא מיכל שמחזיק משהו בין בקשות. לקרוא לה ״הזיכרון של המודל״ הופך את כיוון הסיבתיות — אתם לא ממלאים זיכרון, אתם משלמים כדי להקים אחד מחדש.

מכאן מגיע ה-22. turn $n$ נושא את כל $n-1$ ה-turns הקודמים, ולכן סך ה-input לאורך שיחה של $n$ turns הוא סכום של סדרה גדלה, כלומר ריבועי:

כאשר $s$ הוא ה-system prompt ו-$h_i$ הוא ההיסטוריה ב-turn $i$. התאמת ה-input המצטבר שנמדד ל-$an^2 + bn$ לאורך ארבעים ה-turns נותנת $60.22\,n^2 + 432.25\,n$, שחוזה 113,645 tokens ב-turn 40 מול 112,617 שנמדדו. האיבר הריבועי שולט, והאיבר הליניארי הוא מה שהמשתמש באמת הקליד.

זו השורה שכדאי לקחת מהפרק הזה: החשבון שלכם גדל עם ריבוע השיחה, לא עם השאלה האחרונה. אותן ארבעים שאלות, אם נשאלו בלי היסטוריה בכלל, עלו $0.066036. שמירת ההיסטוריה עלתה $0.274386. ההיסטוריה הכפילה את החשבון פי 4.2, והיא תמשיך להכפיל אותו, כי המכפיל הוא אורך השיחה.

ה-window סופית משתי סיבות שמושכות לאותו כיוון. הראשונה היא של פרק 9: attention משווה כל token לכל token אחר, ולכן העבודה של השכבה הזאת גדלה עם ריבוע אורך הרצף. השנייה היא זיכרון: ה-KV cache גדל ליניארית עם אורך הרצף, ופרק 13 עשה את החשבון הזה — ברצפים ארוכים הוא גדול יותר מהמשקלים.

שני הגבולות הותקפו ואף אחד מהם לא הוסר. FlashAttention¹ מארגן מחדש את החישוב כך שהוא קורא וכותב הרבה פחות לזיכרון ברוחב פס גבוה, מה שהופך רצפים ארוכים למעשיים בלי לשנות את העלות האסימפטוטית. Position Interpolation² ו-YaRN³ מרחיבים את ה-window השימושית של מודל מאומן באמצעות שינוי קנה המידה של positional encodings מפרק 9 במקום לאמן מחדש. יחד הם הסיבה לכך ש-windows עברו מ-2K ל-1M בחמש שנים.

מה שהם לא עשו הוא להפוך contexts ארוכים לחינמיים. הם העלו את התקרה והפכו את השיפוע למתון יותר. השיפוע עדיין שם, וזה מה שמדרגות המחיר בהמשך הפרק מודדות.

כמעט כל מחשבון עלויות באינטרנט ממדל קריאת API כ-input tokens כפול מחיר input ועוד output tokens כפול מחיר output. זה היה נכון ב-2023. עכשיו זה שגוי באופן שמייצר חשבונות שסטו פי שניים או יותר לשני הכיוונים.

יש חמש קטגוריות token לחיוב:

שלוש מתוך החמש האלה לא היו קיימות כשורות נפרדות לפני שנתיים, ושתי שורות ה-cache הן אלה שאנשים טועים בהן, כי cache write עולה יותר מ-input רגיל, לא פחות. אתם משלמים פרמיה כדי לשמור משהו כדי שתוכלו לשלם הנחה כשאתם קוראים אותו חזרה, והאם זו עסקה טובה תלוי לחלוטין בכמה פעמים תקראו אותו.

דלי ה-reasoning הוא של פרק 12, עכשיו עם מחיר, ויש בו פרט שכדאי לומר במפורש: התיעוד של Google אומר שהתמחור ״מבוסס על מלוא thought tokens שהמודל צריך ליצור, אף שרק התקציר יוצא מה-API.״⁴ אתם מחויבים על tokens שלעולם לא מועברים אליכם. זה הדלי היחיד שאת תוכנו אינכם יכולים לספור, לבדוק או לאמת.

עכשיו החלק שהופך את זה לבעיית נרמול ולא לבעיית כפל. כל ספק מדווח על הדליים האלה בשמות שונים, ו—זו המלכודת—שניים מהם משתמשים באותה מילה לשתי כמויות שונות.

קחו קריאה אחת: 4,837 tokens שנקראו מ-cache, 110 חדשים, 142 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. שני השדות הם ספירת ה-input tokens עבור אותו prompt. אצל OpenAI היא כוללת את ה-cached tokens; אצל Anthropic היא מחריגה אותם — התיעוד שלה מציין את הזהות במפורש, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ המשמעות של input_tokens אצל Anthropic היא ״ה-tokens אחרי נקודת ה-cache האחרונה שלכם״.

ועכשיו הסתכלו על ה-output. OpenAI ו-Anthropic מדווחות שתיהן 442, שכבר כולל את 300 ה-reasoning tokens. Gemini מדווחת 142 ושמה את ה-300 בשדה משלה. פרק 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
  };
};

הריצו את שלושת ה-payloads שלמעלה דרך שלושת הקוראים, ושלושתם מייצרים את אותו Usage, ולכן את אותו מספר: $0.006491. ההסכמה הזאת היא כל הסיבה לכתוב את השכבה.

טעו בזה, וזה מה שזה עולה באותה קריאה:

השלישית היא המסוכנת, כי היא נכשלת בשקט בכיוון של חדשות טובות. הדשבורד שלכם מראה שמודל reasoning עולה פחות מחצי ממה שהוא באמת עולה, ושום דבר בשום מקום לא מעלה שגיאה.

אחרי שהדליים נורמלו, פונקציית העלות קצרה. החלק היחיד שאינו מובן מאליו הוא חיפוש המדרגה, שהסעיף הבא מסביר:

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

שתי החלטות תכנון שם ראויות להגנה. ה-fallbacks — מחירי cache שנופלים חזרה ל-input, reasoning ל-output — מקודדים מה המשמעות של טבלה חסרה: reasoning tokens ב-Gemini מחויבים בתעריף output, ולכן מחיר reasoning חסר אינו אפס, אלא מחיר ה-output. ו-contextSize מסכם את כל שלושת דליי ה-input ולא רק את החדשים, כי המדרגה נבחרת לפי אורך ה-prompt, לא לפי כמה ממנו חויבו במחיר מלא.

prompt cache שומר את המצב המחושב של המודל עבור prefix של ה-prompt שלכם, כך שבקשה מאוחרת יותר עם אותו prefix מדלגת על החישוב מחדש שלו. ארבע תכונות נובעות מהמילה ״prefix״, וכל הארבע מפתיעות אנשים.

נקודת האיזון קטנה מספיק כדי לזכור בראש, והתיעוד של OpenAI עושה את החשבון: כתיבת prefix פעם אחת ושימוש חוזר בו פעם אחת עולה 1.35× מעלות ה-input הרגילה שלו, מול 2× לעיבוד שלו פעמיים ללא cache; לאורך עשר בקשות, כתיבה אחת ותשע קריאות עולות 2.15× מול 10×. שימוש חוזר אחד משלם על הכתיבה. Anthropic מגיעה לאותו מקום: קריאה אחת ל-cache של חמש דקות, שתיים ל-cache של שעה.

עכשיו שוב השיחה בת ארבעים ה-turns, עם caching פעיל ו-prefix יציב:

זול יותר בשישים ושמונה אחוזים, ושלושה מספרים בטבלה הזאת שווים תשומת לב.

ה-cache לא נכנס לפעולה עד turn 6. ה-prompt לא מגיע ל-1,024 tokens עד אז, ולכן חמשת ה-turns הראשונים מחויבים בדיוק כמו קודם — וה-sixth מחויב גרוע יותר, בפרמיית כתיבה של 1.25\u00d7, כי זה ה-turn שממלא את ה-cache. הקריאה הראשונה מגיעה ב-turn 7. 2,887 ה-uncached tokens בטבלה הם החשבון: חמישה turns, לא שישה. caching הוא הנחה על prompts ארוכים, ושיחה קצרה לא מקבלת ממנו כלום.

פרמיית הכתיבה היא $0.002474, שהם 2.8 % מהחשבון עם cache. כל turn כותב את הזנב החדש שלו, ארבעים פעמים, וכל פרמיית הכתיבה היא טעות עיגול לעומת מה שהקריאות חסכו. כדאי להבין את חיוב הכתיבה במדויק כדי להפסיק לדאוג ממנו.

רק 2,887 tokens חויבו במחיר input מלא מתוך 112,617. כך נראה cache שעובד: כמעט הכול הוא read.

הנה הכשל שעולה כסף אמיתי, והוא באג של שורה אחת.

שימו משהו שמשתנה בכל קריאה קרוב לתחילת ה-prompt — timestamp, request id, שם המשתמש, שורת ״היום הוא״, מסמך שאוחזר עכשיו — וה-prefix שונה כבר מה-byte הראשון. שום דבר לא מתאים. כל קריאה היא miss. וכיוון שכל קריאה מציגה prefix חדש, כל קריאה גם כותבת.

אותה שיחה, אותם ארבעים turns, caching מופעל, עם timestamp לכל קריאה בראש ה-system prompt:

הפעלת prompt caching הפכה את השיחה ליקרה בעשרים אחוזים יותר מאשר לא להפעיל אותו. שילמתם את פרמיית הכתיבה 1.25× על 109,730 tokens וקראתם חזרה אפס. אין שגיאה, אין אזהרה, והפיצ׳ר מופעל.

אז הכלל, והוא כל prompt caching בשורה אחת: תוכן יציב מקדימה, תוכן משתנה מאחור. הוראות מערכת, הגדרות tools וחומרי עזר קודם; timestamps, זהות משתמש והשאלה הנוכחית אחרונים. Anthropic הופכת את ההיררכיה למפורשת — ה-cache עוקב אחרי tools → system → messages, ושינוי בכל רמה מבטל את הרמה הזאת ואת כל מה שאחריה, כך שעריכה של תיאור tool יחיד מבטלת את כל ה-cache.⁵

שתי השלכות שאנשים נתקלים בהן. שינוי אילו tools מופעלים משנה את הגדרות ה-tools, ולכן feature flag שמוסיף tool לחלק מהמשתמשים מפצל את ה-cache לשניים. וב-Anthropic, הפעלה או כיבוי של חיפוש web או citations משנה את ה-system prompt, מה שמבטל את cache המערכת וההודעות בלי שנגעתם בשורה אחת מהטקסט שלכם.

התגובה המתבקשת לחשבון ריבועי היא להפסיק לשלוח את כל ההיסטוריה: לשמור את תריסר ההודעות האחרונות ולזרוק את השאר. זה אכן מקטין את החשבון, ובדרך כלל זו התנועה הלא נכונה, והמדידה אומרת למה.

קיצור ל-window של שתים-עשרה הודעות זול ב-57 % משליחת הכול ללא cache — ההשוואה שכולם עושים, והסיבה שהטכניקה פופולרית. אבל הוא יקר ב-39 % משליחת הכול עם cache עובד, והפעלת caching לצד קיצור הופכת אותו למעט גרוע יותר, לא טוב יותר.

המנגנון הוא שוב ה-prefix. window נגררת זורקת את ההודעה הישנה ביותר בכל turn, ולכן ה-prompt כבר לא מתחיל איפה שהתחיל בפעם הקודמת וכל turn מציג prefix חדש. ההנחיה של OpenAI אומרת בדיוק את זה: ״summarisation, compaction, or context truncation can change the prefix and reset cache reuse.״⁶ ב-turn 40 ה-prompt בחלון הוא 813 tokens, מתחת למינימום 1,024-token, ולכן אי אפשר לשמור אותו ב-cache בכלל.

והכסף הוא החצי הזול של העלות. מה שזרקתם הוא ההוראה שהמשתמש נתן ב-turn 2 שהמודל היה צריך ב-turn 40. Truncation מחליף חשבון שאתם יכולים לראות בכשל שאינכם יכולים לראות, ולעשות את זה נכון — compaction, הערות מובנות שמוחזקות מחוץ ל-window, אחזור היסטוריה לפי דרישה — הוא הנושא של פרק 24.

contexts ארוכים אינם יקרים יותר רק כי הם ארוכים יותר. מעבר לסף מסוים הם יקרים יותר לכל token, והסף חל רטרואקטיבית על כל ה-prompt.

דף המודל של OpenAI עבור gpt-5.6-terra אומר זאת במשפט אחד: ״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

token אחד, חמישים וחמישה סנט. אם השירות שלכם בונה prompts ממסמכים שאוחזרו וגודלם אינו בשליטתכם, יש לכם צוק במודל העלויות בגבול שאף אחד בצוות לא כתב.

התמחור של Google עובד באותו אופן עם סף של 200,000-token: Gemini 2.5 Pro עולה $1.25 למיליון input tokens עבור prompts עד 200K ו-$2.50 מעליו, כשה-output עולה מ-$10.00 ל-$15.00.⁸ Anthropic הלכה לכיוון השני — נכון ל-6 בספטמבר 2026, התיעוד שלה מציין ש-Claude 4.6 ואילך כוללים את מלוא ה-window של מיליון token במחיר סטנדרטי, כך ש-״a 900k-token request is billed at the same per-token rate as a 9k-token request.״⁹ מודלים מוקדמים יותר שמרו על התוספת.

לכן מחיר אינו מספר. מחיר הוא טבלת מדרגות שממופתחות לפי אורך prompt, וזה התפקיד של Tier[] בפונקציית העלות, ולכן computeCost בוחר את המדרגה באמצעות כל ה-prompt ולא כל דלי בנפרד.

חמשת הדליים ממופים לשני השלבים של פרק 13, וכשרואים את המיפוי יחסי המחירים מפסיקים להיראות שרירותיים.

Input tokens הם prefill. כל ה-prompt עובר דרך המודל במעבר אחד, מעובד במקביל — הכפלות מטריצות גדולות, מוגבלות-חישוב. העלות ל-token נמוכה, וזה השלב שקובע את time to first token: prompt של 4,947-token כולל 4,947 tokens של prefill לפני שהמילה הראשונה מופיעה.

Output tokens הם decode. הם נוצרים אחד-אחד, כל אחד forward pass מלא שקורא את כל ה-KV cache, כשה-GPU בעיקר ממתין לזיכרון במקום לחשב. זה השלב שקובע tokens per second, אי אפשר למקבל אותו בתוך תשובה אחת, וזו הסיבה ש-output עולה בערך פי שישה מ-input במודל שמתומחר כאן: $12.00 מול $2.00 למיליון tokens.

מכאן נובעות ישירות שלוש השלכות. cache read מחליף עבודת prefill, ולכן הוא קונה latency וכסף יחד — אותה הנחה מופיעה גם כחשבון נמוך יותר וגם כהמתנה קצרה יותר ל-token הראשון. Reasoning tokens הם decode שאינכם רואים, ולכן מודל reasoning לא מזרים כלום למשך כמה שניות ואז עונה מהר: פרק 12 הזהיר מההשלכה הממשקית, וזו ההשלכה בחשבונית. ו-ביטול stream אינו עוצר את ה-generation — פרק 14 בנה cancellation והשאיר את המחיר לפרק הזה, והמחיר הוא ספירת ה-output המלאה, כי ה-tokens נוצרים ומחויבים בין אם מישהו מאזין ובין אם לא. אותו דבר נכון לגבי התשובה שאף אחד לא שומר: יצירה מחדש של תשובת turn 40 חמש פעמים עולה $0.057990 עבור זו שנשארת על המסך.

ה-tokenizer של פרק 7 היה Python ונשאר שם. תקצוב קורה בשרת שבונה את הבקשה, ולכן הוא צריך לקרות כאן, ויש בדיוק שלוש רמות דיוק זמינות.

רמה אחת: לספור מקומית. js-tiktoken מגיע עם אותן טבלאות מיזוג BPE כמו tiktoken של Python, ולכן נותן ספירה זהה byte-for-byte עבור encodings של OpenAI, בלי קריאת רשת:

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

שני הקבועים חשובים, ושם ספירות מקומיות נסחפות. הטקסט שלכם אינו מה שעובר tokenization — תבנית ה-chat של פרק 11 עוטפת כל הודעה קודם בסימוני role, ואלה tokens שאתם משלמים עליהם. ארבעה לכל הודעה ושלושה ל-reply priming הם הקירוב המקובל למודלי chat של OpenAI; לאורך שמונים ואחת ההודעות של השיחה למעלה הם מסתכמים ב-324 tokens, 6.4 % מאורכה. הספירות כאן הוצלבו מול tiktoken של Python מפרק 7 על כל שמונים ואחד המחרוזות והן זהות.

רמה שתיים: לשאול את הספק. Anthropic חושפת את /v1/messages/count_tokens ו-Google חושפת את count_tokens, ושניהם מקבלים את אותה צורת בקשה כמו קריאה אמיתית ומחזירים ספירת input token בחינם. השתמשו בהם כשאי אפשר לספור מקומית — ואי אפשר לספור מקומית עבור Anthropic, שה-tokenizer שלה אינו מפורסם. התיעוד של Anthropic זהיר לגבי מה שהוא נותן לכם: הספירה ״is an estimate״, והיא ״may include tokens added automatically by Anthropic for system optimizations״, שעליהם ״you are not billed״.¹⁰

רמה שלוש: לקרוא את usage בתגובה. זו האמת, והיא מגיעה אחרי שהכסף כבר הוצא. בדיוק לכן שתי הרמות הראשונות קיימות — כדי להחליט אם לשלוח את הבקשה, לא כדי לחייב עליה.

ארבע שורות שאינן מופיעות כשורות.

ה-system prompt, משולם בכל קריאה. זה שלמעלה הוא 192 tokens עם תקורת התבנית שלו. לאורך ארבעים קריאות אלה 7,680 tokens — 5.6 % מכל חשבון השיחה הזאת, עבור שמונה שורות שנכתבו פעם אחת. הוא גם מועמד ה-cache הטוב ביותר האפשרי, כי הוא גם יציב וגם ראשון.

הגדרות tools. השם, התיאור ו-JSON schema של כל tool יוצאים בכל בקשה, והספקים מוסיפים מעליהם scaffolding. Anthropic מפרסמת את המספר: עצם הפעלת tools מוסיפה system prompt נסתר של 496 tokens ב-Claude Sonnet 4.5 כש-tool_choice מוגדר ל-auto, או 588 עם any או tool בשם.⁹ וזה עוד לפני ה-schemas שלכם. פרק 18 בונה את הקטלוג; פרק 24 מודד כמה הוא אוכל.

כל generation, כולל אלה שאתם זורקים. חמש יצירות מחדש עולות פי חמש. ה-chat מציג אחת.

מחשבות שלא מוצגות לכם. החיוב מבוסס על מלוא thought tokens אף שרק תקציר מוחזר, ושום חשבונאות שלכם לא יכולה לבקר את המספר הזה.

אזהרה אחת לסיום, כי זו המחשבה הטבעית הבאה והתשובה אינה המובנת מאליה.

window של מיליון token אינה אומרת מיליון tokens שימושיים. דיוק retrieval יורד לפי מיקום: Liu ואחרים מצאו שמודלים מאתרים מידע באופן אמין בתחילת input ארוך ובסופו, והרבה פחות אמין באמצע.¹¹ window גדולה יותר קונה את היכולת לשלוח יותר, לא את הוודאות שיקראו את זה.

התופעה הזאת נמדדת פעם אחת בקורס הזה — שיעור ה-retrieval בתשעה מיקומים באותו prompt בן 853-token — והיא שייכת לפרק 24, שם היא משנה את מה ש-agent עושה. היא מצוטטת כאן כי היא משנה את מה שכדאי לכם לקנות: ה-token הזול ביותר הוא זה שלא שלחתם.

עכשיו אתם יכולים לחזות כמה קריאה תעלה לפני שתבצעו אותה, לקרוא כמה היא עלתה אחר כך, ולהבדיל בין השניים. זה מכסה כל מה שקשור לבקשה חוץ מהחלק שעוד לא נגעתם בו: הכפתורים.

פרק 17 הוא sampling — temperature, top-p, top-k, ה-penalties, והדטרמיניזם שאין לכם. הוא מתחיל בפירוק הטעות הנפוצה ביותר בתחום, שלפיה temperature הוא חוגת יצירתיות. הוא לא: temperature מחלק את ה-logits מ-פרק 4 לפני ה-softmax, והעלאה שלו לא הופכת את המודל לדמיוני, היא מעלה את ההסתברות של tokens שהמודל עצמו דירג כגרועים יותר. משם, למה greedy decoding מייצר טקסט גרוע יותר באופן מדיד מ-sampling, למה top-k ו-top-p נכשלים בצורות התפלגות הפוכות, והניסוי שסוגר את הפרק: עשרים forward passes זהים ב-temperature 0 חוזרים זהים bit-for-bit כשהמודל רץ לבדו, ושימת אותו prompt ב-batch לצד בקשות של מישהו אחר מזיזה 97 % מה-logits שלו.

לא כולם תואמים. הסיבה מתחילה בתיבת ה-floating-point מ-פרק 2.

כל המחירים, הספים והמכפילים בפרק הזה נקראו מדפי הספקים עצמם ב-6 בספטמבר 2026 ומצוינים עם התאריך הזה כי הם ישתנו. השיטה חשובה יותר מהמספרים: הדליים, כלל ה-prefix וחשבון המדרגות יציבים כבר שנתיים, בעוד שכל מספר בתוכם זז.

הרצאה 2 של Stanford CS336, Resource accounting, היא הטיפול האקדמי הקרוב ביותר לחומר הזה והקריאה הבאה הנכונה: היא עושה את אותו חשבון בצד האימון שהפרק הזה עושה בצד ה-inference. ספירות ה-token כאן הופקו עם js-tiktoken 1.0.21 באמצעות encodings o200k_base ו-cl100k_base, על שיחה בת ארבעים turns של 5,090 tokens; תקורת התבנית לכל הודעה היא קירוב הארבע-ועוד-שלוש המקובל ומצוינת בכל מקום שבו היא כלולה. נתוני ה-cache, המדרגות וה-truncation הם כללי התמחור המתועדים שהוחלו על ספירות ה-token שנמדדו, לא תצפיות של תגובות API חיות — לא בוצעה קריאה בתשלום כדי להפיק את הפרק הזה, וזו גם הסיבה הכנה לכך שטענות ה-latency הן איכותניות וטענות העלות אינן.