תמחור רב־מודלי: על מה באמת משלמים בתמונות, אודיו ווידאו

transformer מקבל רצף של וקטורים. אין לו דעה מאיפה הם הגיעו. בפרק 8 האכלנו אותו ב־embeddings שנשלפו לפי token id; שום דבר בארכיטקטורה לא מחייב את השליפה הזאת.

אז: חותכים את התמונה לריבועים קבועים, משטחים כל ריבוע לרשימת מספרים, ודוחפים כל רשימה דרך שכבה ליניארית נלמדת אחת כדי לקבל וקטור ברוחב של המודל. טלאי 32 × 32 של פיקסלים צבעוניים הוא $32 \times 32 \times 3 = 3072$ מספרים; ההיטל $E \in \mathbb{R}^{d \times 3072}$ הופך אותו לווקטור $d$־ממדי אחד, בדיוק הצורה שבה מגיע text token. זה כל הסיפור, וזה גם המאמר שהכותרת שלו אומרת זאת: תמונה שווה 16 × 16 מילים.¹ מוסיפים positional encoding כדי שהמודל ידע איזה ריבוע היה איפה, משלבים את התוצאות עם ה־text embeddings, והרצף שהמודל קורא הוא בחלקו תמונה ובחלקו משפט.

שלושה מאמרים הפכו את זה למוצר. CLIP אימן image encoder ו־text encoder להסכים, על ארבע מאות מיליון זוגות שנגרדו מהרשת, וזה המקום שבו הרעיון שפיקסלים ומילים יכולים לחלוק מרחב הפסיק להיות השערה.² Flamingo חיבר vision encoder קפוא למודל שפה קפוא עם כמה שכבות גישור מאומנות.³ LLaVA הראה שהגשר יכול להיות היטל ליניארי יחיד ושאפשר ללמד instruction-following בעזרת נתונים שנוצרו, וזו הסיבה שכל מודל vision-language פתוח מאז נראה בערך אותו דבר.⁴

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

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

OpenAI מכסה את התמונה בטלאי 32 × 32 ומכפילה את הספירה בגורם לפי מודל. אם ספירת הטלאים עוברת את התקציב של אותו מודל ורמת detail, התמונה מוקטנת עד שהיא נכנסת:

Anthropic מכסה אותה בטלאי 28 × 28, visual token אחד לכל טלאי, ומגבילה גם את הצלע הארוכה וגם את ספירת ה־token — 1,568 פיקסלים ו־1,568 token במודלים standard-tier, 2,576 ו־4,784 במדרגת high-resolution. תמונות גדולות מדי מוקטנות לגודל הגדול ביותר שעומד בשתי המגבלות.⁵

Google לא סופרת פיקסלים בכלל. תמונה ששתי הצלעות שלה 384 פיקסלים או פחות עולה flat 258 token. כל דבר גדול יותר נחתך לאריחים של 258 token כל אחד, ורשת האריחים מגיעה מיחידת חיתוך של $\lfloor \min(w,h) / 1.5 \rfloor$.⁶

export function openaiImageTokens(
  w: number, h: number,
  { maxDim, patchBudget, multiplier }: { maxDim: number; patchBudget: number; multiplier: number },
) {
  const fit = Math.min(1, maxDim / Math.max(w, h));      // never enlarges
  w = Math.floor(w * fit); h = Math.floor(h * fit);
  let patches = Math.ceil(w / 32) * Math.ceil(h / 32);   
  if (patches > patchBudget) {
    const s = Math.sqrt((32 * 32 * patchBudget) / (w * h));
    const adj = s * Math.min(
      Math.floor((w * s) / 32) / ((w * s) / 32),
      Math.floor((h * s) / 32) / ((h * s) / 32));
    patches = Math.ceil(Math.floor(w * adj) / 32) * Math.ceil(Math.floor(h * adj) / 32);
  }
  return Math.ceil(patches * multiplier);                
}

export function anthropicVisualTokens(
  w: number, h: number,
  { maxLongEdge, maxTokens }: { maxLongEdge: number; maxTokens: number },
) {
  const tok = (a: number, b: number) => Math.ceil(a / 28) * Math.ceil(b / 28);
  const long = Math.max(w, h), short = Math.min(w, h);
  for (let L = Math.min(long, maxLongEdge); L >= 1; L--) {     
    const t = tok(L, Math.round((short * L) / long));
    if (t <= maxTokens) return t;                              
  }
  return 0;
}

export function geminiImageTokens(w: number, h: number) {
  if (w <= 384 && h <= 384) return 258;
  const crop = Math.floor(Math.min(w, h) / 1.5);               
  return Math.ceil(w / crop) * Math.ceil(h / crop) * 258;      
}

הריצו כל כלל מול המספרים שהספק שלו מדפיס:

OpenAI, gpt-5.4 at detail:high (2048 px, 2,500 patches, 1.2x)
  1024x1024 -> 1024 patches -> 1229 tokens   doc says 1229   MATCH
  2048x2048 -> 2500 patches -> 3000 tokens   doc says 3000   MATCH

Anthropic, the published table (one tier per row shown)
  200x200    std   64 @ 200x200     doc   64, not resized    OK
  1000x1000  std 1296 @ 1000x1000   doc 1296, not resized    OK
  1092x1092  std 1521 @ 1092x1092   doc 1521, not resized    OK
  1920x1080  std 1560 @ 1456x819    doc 1560, 1456x819       OK
  2000x1500  std 1564 @ 1269x952    doc 1564, 1269x952       OK
  3840x2160  hi  4784 @ 2576x1449   doc 4784, 2576x1449      OK

Google, the worked example
  960x540 -> crop 360 -> 3 x 2 = 6 tiles     doc says 6      MATCH

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

העבירו אותה תמונת 4:3 דרך שלושת הכללים בשישה גדלים:

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

הגודל מצטמצם החוצה. ה־image tokens של Google תלויים ביחס הממדים ובשום דבר אחר. תמונת 4:3 היא ארבעה אריחים בין אם היא thumbnail ובין אם היא פוסטר. העובדה האלגברית היחידה הזאת היא כל ההסבר לאפס בטבלת החיסכון למעלה, ושום דף מחיר בשום מקום לא מציין אותה.

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

עכשיו נשבור את זה. הדרך הברורה להוציא פחות על vision model היא לבקש פחות detail, אז שלחו detail: "low":

1600x1200   low = 2280   high = 2280   ratio 1.00
3200x2400   low = 3687   high = 2942   ratio 1.25

בקשה ל־detail נמוך יותר עלתה 25 % יותר. זה לא באג ו־OpenAI אומרת זאת בשורה אחת בטבלת הגדלים: במשפחת המודלים הזאת, low משתמש במגבלת 2048 פיקסלים עם תקציב 6,144 טלאים, בעוד high משתמש באותה מגבלת פיקסלים עם תקציב 2,500 טלאים, ״כך שהוא יכול להשתמש ביותר token מ־high״.⁷ המילה low מציינת הגדרת נאמנות, לא מחיר: בשתיים מחמש משפחות המודלים המתועדות היא לא קונה שום חיסכון, ובאחת משתי אלה היא עולה יותר.

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

ספקים מפרסמים יצירת תמונות כמחיר לתמונה. זה לא כזה. מודלי GPT Image פולטים image tokens ייעודיים שספירתם תלויה בגודל ובאיכות המבוקשים; הכפילו את הספירות שפורסמו בתעריף image output שפורסם ל־GPT Image 1, $40 למיליון, והשוו למחירי התמונה באותו עמוד:

תשעה נתונים נגזרים מול תשעה נתונים שפורסמו, וכל זוג מסכים בטווח של $0.002.¹¹ Google מפורשת עוד יותר ועושה בשבילכם את ההמרה בדף המחיר עצמו: image output ב־$60 למיליון token, ״תמונות output ב־1K ‏(1024x1024px) צורכות 1120 token ושקולות ל־$0.067 לתמונה״.¹²

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

quality   1024x1024            1024x1536
low       $0.006 -> 200 tok    $0.005 -> 167 tok
medium    $0.053 -> 1767 tok   $0.041 -> 1367 tok
high      $0.211 -> 7033 tok   $0.165 -> 5500 tok

התמונה הגדולה יותר היא הזולה יותר בכל איכות. canvas של 1024 × 1536 כולל 50 % יותר פיקסלים מ־1024 × 1024 ועולה 23 % פחות token ב־medium. OpenAI מסמנת זאת במשפט שקל לדלג עליו — ״רזולוציה לא־ריבועית גדולה יותר יכולה לפעמים לייצר פחות output tokens מרזולוציה קטנה יותר או ריבועית באותה הגדרת איכות״ — ובדור המודלים הקודם זה עבד הפוך, portrait עלה 50 % יותר מ־square.¹¹ כל ברירת מחדל של 1024x1024 שנכתבה לפני השינוי הזה היא עכשיו האפשרות היקרה.

בקשו משלושה מוצרים להקריא אותם 519 תווים — בערך 38 שניות אודיו — ותקבלו שלוש מערכות יחידות משני ספקים:

אותו ספק מוכר את שתי היחידות: tts-1 של OpenAI מתומחר למיליון תווים בעוד gpt-4o-mini-tts מתומחר למיליון token, $0.60 פנימה ו־$12.00 החוצה.¹³ לכן ״text-to-speech הזול ביותר״ אינה שאלה שיש לה תשובה עד שאומרים מה מקריאים.

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

תמלול פועל בכיוון השני והוא השורה הפשוטה ביותר בכל החשבונית — לכל דקת אודיו, flat:

whisper                  $0.005960     ($0.006 / min)
gpt-transcribe           $0.004470     ($0.0045 / min)
gpt-4o-mini-transcribe   $0.002980     ($0.003 / min)
gpt-live-transcribe      $0.016887     ($0.017 / min)

שימו לב לשורה האחרונה מול השלישית: לעשות זאת live, בזמן שהמילים מגיעות, עולה פי 5.7 מלעשות זאת על קובץ גמור. הפער הזה הוא המחיר של אי־יכולת לעשות batch, והוא מה שהופך את הסעיף הבא ליקר.

עכשיו המספר שקובע אם קול הוא feature או מוצר.

השיחה: שיחת תמיכה בת עשרה תורים, 149 מילים, שבקצב מוצהר של 150 מילים לדקה הן 59.6 שניות דיבור — 21.2 שנאמרות על ידי המתקשר, 38.4 שנאמרות בחזרה. המרות ה־token הן של הספקים עצמם. OpenAI: ״audio tokens בהודעות משתמש הם 1 token לכל 100 ms של אודיו, בעוד audio tokens בהודעות assistant הם 1 token לכל 50 ms״.¹⁴ Google: 25 token לשנייה, בשני הכיוונים, מה שדף המחיר שלה מאשר כשהוא מפרסם $12.00 למיליון ו־$0.018 לדקה באותה שורה.¹²

השיחה מצטברת בדיוק כפי שפרק 16 אמר שתצטבר, כי זה אותו מנגנון: ״כל השיחה נשלחת למודל עבור כל Response... לכן תורים מאוחרים יותר בסשן יהיו יקרים יותר״.¹⁴ רק שעכשיו ההיסטוריה נמדדת ב־audio tokens.

עכשיו ההשוואה שקובעת את המוצר, כל הארבעה מנורמלים לדקה:

פי שלושים ושמונה. לא שלושים ושמונה אחוז. אותה החלפה בדיוק, כשהיא מתבצעת בקול במקום בטקסט, יקרה כמעט בשני סדרי גודל, ואף חלק מהפער הזה אינו מרווח שמישהו בחר לגבות — זה יחס ההמרה. שנייה אחת של אודיו assistant היא עשרים token. אותה שנייה נושאת 2.5 מילים בקצב המוצהר, והתמליל הנמדד רץ ב־1.26 token למילה, כך שכטקסט היא 3.15 token. קול הוא חבילה גדולה פי 6.3 לאותה משמעות, וכל אחד מה־token שלו מחויב פי 5.3 מתעריף text output ופי 16 מתעריף text input. הכפילו יחס נפח ביחס מחיר וסדר הגודל כבר שם לפני שהחשבונאות מתחילה.

שתי השלכות תפעוליות נובעות ישירות מהטבלה.

Audio caching הוא לא אופטימיזציה, הוא המודל העסקי. cached audio input עולה $0.40 למיליון מול $32.00 ל־fresh — הנחה של 98.75 % שמחצה את השיחה. הכלל הוא של פרק 16, ללא שינוי: ה־cache מתאים prefix, ולכן כל דבר שמוכנס בתחילת השיחה באמצע שיחה הורס אותו, והמקום הטבעי לשים ״המתקשר אומת עכשיו״ הוא בדיוק שם.

ושום דבר שתעשו בלקוח לא מבטל חיוב של צליל. המשתמש מדבר מעל ה־assistant, הקוד שלכם עוצר את הניגון, הרמקול משתתק. כל מה שכבר נוצר כבר חויב, כי החיוב נצבר כשה־response נוצר; ולפי הכלל של פרק 16 כל מה שנשאר בשיחה נשלח מחדש, כ־input audio, בכל תור שאחריו. פרק 14 אמר את זה על ביטול text stream. בקול זה עולה פי שלושים יותר.

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

הספק לפי clip יקר יותר מהספק לפי שנייה מתחת ל־1.2 שניות וזול ממנו פי 16.7 בעשרים שניות. שום דירוג של שני המודלים האלה לא שורד שינוי באורך ה־clip, ולכן ״איזה מודל וידאו הכי זול״ אינה שאלה על מודלים.

השורה האחרונה גרועה יותר, והיא הלב הישר של הפרק. mochi מחויב לפי שניות GPU אמיתיות — זמן ה־prediction הנמדד של העבודה — ב־$0.001400 לשנייה על A100 ו־$0.001525 על H100, שהם תעריפי המכונה המושכרת ולא שום דבר אחר.¹⁵ זה תעריף מדויק לחלוטין והוא לא מחיר, כי הכמות שהוא מכפיל אינה ידועה עד אחרי שהתחייבתם לשלם עליה. השורה למעלה מניחה שתים עשרה GPU-seconds לכל שניית output; הכפילו את ההנחה הזאת בארבע והיא יוצאת מהפס הזול ביותר, ורק בפי שש היא נוחתת באמצע הטבלה. זה התעריף היחיד בעמוד הזה שאי אפשר לשים בהצעת מחיר.

אז: tokens, image tokens, תווים, דקות, שניות וידאו, clips שלמים, GPU seconds, יחידות flat. שמונה כמויות, והדרך היחידה לשים אותן על ציר אחד היא להצהיר על workload ולתמחר אותו.

זו ההרחבה ל־computeCost של פרק 16 — אותה מכונת מדרגות, עכשיו עם קריטריונים שאינם אורך prompt:

export interface MediaCriteria {
  resolution?: string[]; quality?: string[];
  hasAudio?: boolean; maxDurationSeconds?: number;
}
export interface MediaTier { when?: MediaCriteria; price: number }
export type MediaRate = number | MediaTier[];

const matches = (when: MediaCriteria, u: Usage) => {
  const inList = (l?: string[], v?: string) => !l || (v !== undefined && l.includes(v));
  if (!inList(when.resolution, u.resolution)) return false;
  if (!inList(when.quality, u.quality)) return false;
  if (when.hasAudio !== undefined && when.hasAudio !== (u.hasAudio ?? false)) return false;
  if (when.maxDurationSeconds !== undefined
      && (u.videoSeconds ?? 0) > when.maxDurationSeconds) return false;   
  return true;
};

const mediaPrice = (rate: MediaRate | undefined, u: Usage): number => {
  if (rate === undefined) return 0;
  if (typeof rate === "number") return rate;
  for (const t of rate.filter((t) => t.when)) if (matches(t.when!, u)) return t.price;
  return rate.find((t) => !t.when)?.price ?? 0;      // the tier with no criteria is the default
};

export function computeCost(p: Pricing, u: Usage): number {
  let c = textCost(p, u);                             // Chapter 16, unchanged
  if (p.imageInputToken || p.imageOutputToken) {
    c += (u.imageInputTokens ?? 0) * (p.imageInputToken ?? 0)
       + (u.imageOutputTokens ?? 0) * (p.imageOutputToken ?? 0);
  } else if (p.imageUnit !== undefined) c += (u.images ?? 1) * mediaPrice(p.imageUnit, u);  
  if (p.videoSecond !== undefined) c += (u.videoSeconds ?? 0) * mediaPrice(p.videoSecond, u);
  if (p.videoUnit   !== undefined) c += (u.videoCount ?? 1)   * mediaPrice(p.videoUnit, u);
  c += (u.audioInputTokens ?? 0)       * (p.audioInputToken ?? 0)
     + (u.cachedAudioInputTokens ?? 0) * (p.cachedAudioInputToken ?? p.audioInputToken ?? 0)
     + (u.audioOutputTokens ?? 0)      * (p.audioOutputToken ?? 0)
     + (u.computeSeconds ?? 0)         * (p.computeSecond ?? 0)
     + (u.chars ?? 0)                  * (p.perChar ?? 0)
     + (u.minutes ?? 0)                * (p.perMinute ?? 0);
  return c;
}

שתי השורות המסומנות הן המקום שבו זה נשבר. תעריף שמצוטט ליחידה מכפיל את u.images ?? 1; תעריף שמצוטט ל־token מכפיל משהו שברירת המחדל שלו היא אפס. הזינו לשניהם usage ריק — הצורה שמקבלים כשמדידה נכשלה — וצפו:

per image (nano-banana-pro)     empty usage => $0.1500
per clip  (hailuo-02)           empty usage => $0.1500
per unit  (a cloned voice)      empty usage => $3.0000
per token (gpt-image-2)         empty usage => $0.0000
per second (veo-3.1)            empty usage => $0.0000
per GPU-second (mochi)          empty usage => $0.0000

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

הכשל השני הוא משך. התעריף לפי clip בוחר מדרגה עם maxDurationSeconds מול u.videoSeconds ?? 0, כך ש־usage שלא תיעד משך לעולם מתאים למדרגה הקצרה ביותר:

duration recorded    ->  $0.45
duration missing     ->  $0.27

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

כשאפשר לחשב עלויות, ההשוואה צריכה את החצי השני — workload מייצג מוצהר, אחד לכל engine, מפורסם כך שקורא יכול לחלוק עליו:

export const representative = {
  text:   { blend: [[{ promptTokens: 1e6 }, 0.25], [{ completionTokens: 1e6 }, 0.75]] },
  image:  { images: 1, imageInputTokens: 50, imageOutputTokens: 1500 },
  video:  { videoSeconds: 5, videoCount: 1, resolution: "1080p", hasAudio: true, computeSeconds: 60 },
  voice:  { chars: 1000, computeSeconds: 10 },
  stt:    { minutes: 1 },
};

כל אחת מהשורות האלה היא טענה. טקסט מערבב רבע input ושלושה רבעים output כי שימוש אמיתי נוטה ל־output; תערובת חמישים־חמישים מדרגת את המודלים אחרת. workload התמונה מניח 1,500 output tokens, בין 1,056 של OpenAI לריבוע medium לבין 1,584 שלה ל־portrait medium. וידאו מניח חמש שניות ב־1080p, וכבר ראינו שני ספקים מחליפים מקומות ב־1.2 שניות. רשומת ה־compute מניחה שישים GPU-seconds כי אין שום דבר אחר להניח.

וזו השיטה, והיא היחידה ההוגנת שיש: אי אפשר להשוות מחירים ביחידות שונות; אפשר רק להשוות את העלות של workload שכתבתם במפורש. כל טבלה שמדרגת מודלים multimodal בלי להדפיס את ה־workload שלה מדרגת את ההנחות שלה עצמה.

עכשיו אפשר לתמחר כל דבר שמודל יכול להפיק, בכל יחידה שבה הוא נמכר, ולומר בקול איזה workload ההשוואה שלכם הניחה. זה סוגר את החשבונית שפרק 16 פתח, וזה סוגר את חלק III: כל מה שמפרק 14 ועד כאן עסק ב־קריאה אחת — איך לבצע אותה, מה לשים בה, איך לדגום אותה, מה היא מחזירה, כמה היא עולה.

פרק 22 משנה את יחידת הניתוח, והשינוי יקר. agent אינו קריאה אחת; הוא לולאה שמחליטה בעצמה כמה קריאות לבצע, והאריתמטיקה של שני הפרקים האחרונים היא מה שהופך את זה מדיאגרמת ארכיטקטורה לתקציב. הוא נפתח בשאילת אותה שאלה לאותו מודל פעמיים, עם tool אחד שנוסף לקטלוג בפעם השנייה, ובמדידה מה tool אחד עשה: קריאה אחת הפכה לשתיים, שלושים ותשעה input tokens הפכו ל־420.

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

כל מחיר, נוסחה ויחס המרה בפרק הזה נקראו מהעמוד של הספק עצמו ב־7 בספטמבר 2026 ומצוטטים עם התאריך הזה, כי כולם יזוזו. ספירות ה־token, העלויות וההשוואות חושבו על הנתונים האלה באמצעות הקוד שמודפס למעלה, על מכונה אחת, בלי לבצע קריאת API בתשלום — וזו גם הסיבה הכנה לכך שאין בפרק הזה ולו טענת latency אחת.

פונקציות image-token, טבלאות העלות, פירוט שיחת הקול ותוצאות empty-usage הופקו על ידי ה־TypeScript שמודפס בפרק הזה, בהרצה על Node 22. הדיאלוג ששימש להשוואת הקול הוא בן 149 מילים ועבר tokenization עם tiktoken תחת קידוד o200k_base ל־188 token; משכו נובע מקצב מוצהר של 150 מילים לדקה, שהוא פרמטר של ההשוואה ולא מדידה. כל נתון ספק נושא את הערת השוליים שמציינת את העמוד שממנו הגיע.