قیمت‌گذاری چندوجهی: تصاویر، صدا و ویدئو واقعاً چه چیزی را صورتحساب می‌کنند

یک transformer دنباله‌ای از بردارها می‌گیرد. برایش مهم نیست از کجا آمده‌اند. فصل 8 به آن embeddingهایی را خوراند که از یک token id lookup شده بودند؛ هیچ‌چیز در معماری، lookup را الزام نمی‌کند.

پس: تصویر را به مربع‌های ثابت ببرید، هر مربع را به فهرستی از اعداد تخت کنید، و هر فهرست را از یک لایه خطیِ یادگرفته‌شده عبور دهید تا برداری با عرض مدل بسازید. یک patch ‏32 × 32 از پیکسل‌های رنگی، $32 \times 32 \times 3 = 3072$ عدد است؛ projection ‏$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 نشان داد این پل می‌تواند یک projection خطی واحد باشد و instruction-following می‌تواند با داده تولیدی آموخته شود؛ به همین دلیل است که تقریباً همه مدل‌های vision-language باز بعد از آن شبیه هم به نظر می‌رسند.⁴

پیامد آن برای فاکتور شما فوری و بی‌زرق‌وبرق است: patchها موقعیت‌هایی در دنباله‌اند، پس input tokens هستند، پس با نرخ ورودی هزینه‌شان را می‌پردازید. تعدادشان حساب است، و هر provider آن را جور دیگری انجام می‌دهد.

هر قاعده زیر از مستندات خود provider پیاده‌سازی شده و با مثال‌های محاسبه‌شده همان مستندات سنجیده شده است.

OpenAI تصویر را با patchهای 32 × 32 می‌پوشاند و تعداد را در ضریب مخصوص هر مدل ضرب می‌کند. اگر تعداد patch از بودجه آن مدل و سطح detail فراتر برود، تصویر تا جایی کوچک می‌شود که جا شود:

Anthropic آن را با patchهای 28 × 28 می‌پوشاند، هر کدام یک visual token، و هم لبه بلند و هم تعداد token را سقف‌گذاری می‌کند — 1,568 پیکسل و 1,568 token در مدل‌های standard-tier، و 2,576 و 4,784 در high-resolution tier. تصاویر بیش‌ازحد بزرگ به بزرگ‌ترین اندازه‌ای کوچک می‌شوند که با هر دو جور دربیاید.⁵

Google اصلاً پیکسل‌ها را نمی‌شمارد. تصویری که هر دو ضلعش 384 پیکسل یا کمتر باشد، هزینه ثابت 258 token دارد. هر چیز بزرگ‌تر به tileهایی از 258 token بریده می‌شود، و شبکه tile از crop unit ‏$\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;      
}

هر کدام را روی اعدادی اجرا کنید که vendor خودش چاپ کرده است:

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 هر دو tier را برای هر شش اندازه می‌دهد. حالا قواعد برای اجرای روی هر عکسی که دارید مال شماست، و نکته همین است: این‌ها تنها سه تابع این فصل‌اند که از صفحه قیمت به دست نمی‌آیند.

همان عکس 4:3 را در شش اندازه از هر سه عبور دهید:

ستون آخر را رو به پایین بخوانید. وقتی تصویر از 384 پیکسل بزرگ‌تر شد، عدد دیگر هرگز تغییر نمی‌کند، و این نه تصادف است نه سقف. crop unit را برای تصویری که حداقل به پهنای ارتفاعش است دوباره در فرمول tile جای‌گذاری کنید:

اندازه حذف می‌شود. image tokens گوگل به aspect ratio وابسته‌اند و به هیچ چیز دیگر. یک عکس 4:3 چهار tile است، چه thumbnail باشد چه poster. همین واقعیت جبریِ واحد، کل توضیح صفرِ جدول صرفه‌جویی بالاست، و هیچ صفحه قیمتی در هیچ‌جا آن را بیان نمی‌کند.

دو ستون دیگر در عوض سقف می‌خورند، در ارتفاع‌های متفاوت و به دلایل متفاوت — Anthropic در سقف اعلام‌شده token، OpenAI در بودجه patch بعد از یک محدودیت پیکسلی — و به همین دلیل سه منحنی در اندازه‌های متفاوت همدیگر را قطع می‌کنند.

حالا خرابش کنید. راه بدیهی برای هزینه کمتر در 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-patch استفاده می‌کند، درحالی‌که high از همان محدودیت پیکسلی با بودجه 2,500-patch استفاده می‌کند، «so it can use more tokens than high».⁷ واژه low نام یک تنظیم fidelity است، نه قیمت: در دو تا از پنج خانواده مدل مستندشده هیچ صرفه‌جویی نمی‌خرد، و در یکی از همان دو، بیشتر هزینه دارد.

همه‌چیز تا اینجا مدلی بوده که تصویری را می‌خواند. ساختن تصویر روی مکانیزمی اجرا می‌شود که اصلاً token ندارد، و به همین دلیل به‌جای کلمه، با تصویر فروخته می‌شود.

Vendorها image generation را به‌صورت قیمت هر تصویر منتشر می‌کنند. این‌طور نیست. مدل‌های GPT Image، image tokens تخصصی بیرون می‌دهند که تعدادشان به اندازه و quality درخواستی وابسته است؛ تعدادهای منتشرشده را در نرخ image output منتشرشده GPT Image 1 یعنی $40 به ازای هر میلیون ضرب کنید و با قیمت‌های هر تصویر در همان صفحه مقایسه کنید:

نه رقم مشتق‌شده در برابر نه رقم منتشرشده، و هر جفت با اختلافی کمتر از $0.002 همخوان است.¹¹ Google حتی صریح‌تر است و تبدیل را خودش روی صفحه قیمت برایتان انجام می‌دهد: image output با $60 به ازای هر میلیون token، «output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image».¹²

پس قیمت هر تصویر، قیمت هر 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

تصویر بزرگ‌تر در هر quality ارزان‌تر است. یک canvas ‏1024 × 1536 پنجاه درصد پیکسل بیشتری از 1024 × 1024 دارد و در medium بیست‌وسه درصد token کمتر هزینه دارد. OpenAI آن را در جمله‌ای علامت می‌زند که احتمالاً از آن می‌گذرید — «a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting» — و در نسل قبلی مدل‌ها برعکس بود، portrait پنجاه درصد بیشتر از square هزینه داشت.¹¹ هر default از 1024x1024 که قبل از آن تغییر نوشته شده، حالا گزینه گران است.

از سه محصول بخواهید همان 519 کاراکتر را بگویند — حدود 38 ثانیه audio — و از دو vendor سه سیستم واحد می‌گیرید:

همان vendor هر دو واحد را می‌فروشد: tts-1 از OpenAI برحسب هر میلیون کاراکتر قیمت‌گذاری می‌شود، درحالی‌که gpt-4o-mini-tts برحسب هر میلیون token قیمت‌گذاری می‌شود، $0.60 ورودی و $12.00 خروجی.¹³ پس «ارزان‌ترین text-to-speech» تا وقتی نگویید چه چیزی را می‌خوانید، پرسشی با پاسخ نیست.

و دو واحد نسبت به چیزهای متضاد کورند. قیمت هر کاراکتر duration را نمی‌بیند: صدایی آهسته و شمرده انتخاب کنید، یا مکث اضافه کنید، فاکتور تکان نمی‌خورد درحالی‌که audio طولانی‌تر می‌شود. قیمت هر ثانیه content را نمی‌بیند: سی ثانیه همان‌قدر هزینه دارد، چه یک پاراگراف فنی فشرده باشد چه کسی تا ده بشمارد. voice را عوض کنید و دقیقاً یکی از دو vendor شما دوباره قیمت‌گذاری می‌کند.

Transcription برعکس می‌رود و ساده‌ترین خط کل فاکتور است — به ازای هر دقیقه audio، ثابت:

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)

ردیف آخر را نسبت به سوم ببینید: انجام آن به‌صورت زنده، وقتی کلمات می‌رسند، 5.7 برابر انجام آن روی فایل آماده هزینه دارد. این فاصله قیمتِ نتوانستن برای batch کردن است، و همان چیزی است که بخش بعدی را گران می‌کند.

حالا عددی که تعیین می‌کند voice یک feature است یا یک محصول.

تماس: مکالمه پشتیبانی ده‌نوبتی، 149 کلمه، که با نرخ اعلام‌شده 150 کلمه در دقیقه، 59.6 ثانیه گفتار است — 21.2 ثانیه از تماس‌گیرنده، 38.4 ثانیه پاسخ. تبدیل‌های token متعلق به خود providerهاست. OpenAI: «audio tokens in user messages are 1 token per 100 ms of audio, while audio tokens in assistant messages are 1 token per 50 ms».¹⁴ Google: ‏25 token در ثانیه، در هر دو جهت، که صفحه قیمتش با انتشار $12.00 به ازای هر میلیون و $0.018 به ازای هر دقیقه در همان خط تأیید می‌کند.¹²

مکالمه دقیقاً همان‌طور انباشته می‌شود که فصل 16 گفت، چون همان مکانیزم است: «the entire conversation is sent to the model for each Response... thus turns later in the session will be more expensive».¹⁴ فقط حالا history با audio tokens اندازه‌گیری می‌شود.

حالا مقایسه‌ای که محصول را تعیین می‌کند، هر چهار مورد نرمال‌شده به یک دقیقه:

سی‌وهشت برابر. نه سی‌وهشت درصد. همان تبادل، اگر به‌جای متن با صدا انجام شود، تقریباً دو مرتبه بزرگی گران‌تر است، و هیچ‌کدام از این فاصله حاشیه سودی نیست که کسی انتخاب کرده باشد — نرخ تبدیل است. یک ثانیه audio از assistant بیست token است. همان ثانیه با نرخ اعلام‌شده 2.5 کلمه حمل می‌کند، و transcript اندازه‌گیری‌شده 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 تازه — تخفیف 98.75 % که تماس را نصف می‌کند. قاعده همان قاعده فصل 16 است، بی‌تغییر: cache یک prefix را match می‌کند، پس هر چیزی که وسط تماس جلوی مکالمه درج شود آن را نابود می‌کند، و جای طبیعی گذاشتن «تماس‌گیرنده اکنون verify شده» دقیقاً همان‌جاست.

و هیچ کاری در client یک صدا را از صورتحساب خارج نمی‌کند. کاربر روی حرف assistant صحبت می‌کند، کد شما پخش را متوقف می‌کند، speaker ساکت می‌شود. هرچه قبلاً تولید شده بود قبلاً هزینه شده، چون billing وقتی response ساخته می‌شود انباشته می‌شود؛ و طبق قاعده فصل 16 هرچه در مکالمه بماند، در هر نوبت بعدی دوباره به‌عنوان input audio فرستاده می‌شود. فصل 14 این نکته را درباره abort کردن text stream گفت. در voice سی برابر بیشتر هزینه دارد.

Video را بعضی vendorها به ازای هر ثانیه می‌فروشند و بعضی به ازای هر clip، با tierهایی برای resolution و گاهی duration. این دو شکل فقط از نظر راحتی فرق ندارند؛ همدیگر را قطع می‌کنند.

vendor هر-clip زیر 1.2 ثانیه از هر-ثانیه گران‌تر است و در بیست ثانیه 16.7 برابر ارزان‌تر. هیچ ترتیب رتبه‌بندی این دو مدل با تغییر طول clip دوام نمی‌آورد، پس «کدام video model ارزان‌تر است» پرسشی درباره مدل‌ها نیست.

ردیف آخر بدتر است، و قلب صادق این فصل همان‌جاست. mochi بر اساس ثانیه‌های واقعی GPU صورتحساب می‌شود — زمان prediction اندازه‌گیری‌شده job — با $0.001400 در ثانیه روی A100 و $0.001525 روی H100، که نرخ‌های ماشین اجاره‌ای‌اند و هیچ چیز دیگر.¹⁵ این تعرفه‌ای کاملاً دقیق است و قیمت نیست، چون کمیتی که در آن ضرب می‌شود تا بعد از تعهد به پرداخت ناشناخته است. ردیف بالا دوازده GPU-second به ازای هر ثانیه خروجی فرض می‌کند؛ آن فرض را چهار برابر کنید و از باند ارزان‌ترین خارج می‌شود، و فقط در شش برابر به میانه جدول می‌رسد. این تنها تعرفه این صفحه است که نمی‌توانید در quote بگذارید.

پس: tokenها، image tokens، کاراکترها، دقیقه‌ها، video seconds، clipهای کامل، GPU seconds، واحدهای ثابت. هشت کمیت، و تنها راه گذاشتنشان روی یک محور این است که workloadی اعلام کنید و آن را قیمت‌گذاری کنید.

این گسترش computeCost فصل 16 است — همان ماشین tier، حالا با criterionهایی که prompt length نیستند:

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

دو خط علامت‌خورده جایی است که می‌شکند. تعرفه‌ای که به ازای unit نقل شده، u.images ?? 1 را ضرب می‌کند؛ تعرفه‌ای که به ازای token نقل شده، چیزی را ضرب می‌کند که پیش‌فرضش صفر است. به هر دو یک usage خالی بدهید — شکلی که وقتی measurement شکست می‌گیرید — و ببینید:

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

شش بار هیچ اتفاقی نیفتاد، و یک بار سه دلار هزینه داشت و پنج بار هیچ. این اختلاف گرد کردن نیست؛ تصمیمی است درباره اینکه عدد غایب یعنی چه، جداگانه برای هر unit گرفته شده و هیچ‌جا نوشته نشده. قاعده درست این است که فیلدی که هیچ‌کس اندازه‌اش نگرفته غایب می‌ماند، چون «اندازه‌گیری نشده» و «اندازه‌گیری شده و صفر درآمده» چیزهای متفاوت‌اند. این تابع آرام با آن مخالف است.

شکست دوم duration است. تعرفه clip-priced، tier خود را با maxDurationSeconds در برابر u.videoSeconds ?? 0 انتخاب می‌کند، پس usageی که هرگز duration ثبت نکرده، با کوتاه‌ترین tier match می‌شود:

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

چهل درصد تخفیف برای اینکه نمی‌دانید video چقدر طول داشته است. هر دو باگ یک ریشه دارند: پیش‌فرضی که برای راحتی داخل تابعی انتخاب شده که کل کارش دقیق بودن است.

وقتی هزینه‌ها قابل محاسبه شدند، مقایسه نیمه دیگر را می‌خواهد — یک representative 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 را مخلوط می‌کند چون usage واقعی به output متمایل است؛ blend پنجاه‌پنجاه مدل‌ها را جور دیگری رتبه‌بندی می‌کند. workload تصویر 1,500 output token فرض می‌کند، بین 1,056 OpenAI برای medium square و 1,584 آن برای medium portrait. Video پنج ثانیه در 1080p فرض می‌کند، و همین حالا دیدیم دو vendor در 1.2 ثانیه جا عوض می‌کنند. ورودی compute شصت GPU-second فرض می‌کند چون چیز دیگری برای فرض کردن نیست.

روش همین است، و تنها روش صادقانه موجود: نمی‌توانید قیمت‌ها را در واحدهای متفاوت مقایسه کنید؛ فقط می‌توانید هزینه workloadی را که نوشته‌اید مقایسه کنید. هر جدولی که multimodal models را بدون چاپ workload خود رتبه‌بندی کند، فرض‌های خودش را رتبه‌بندی می‌کند.

حالا می‌توانید هر چیزی را که مدل می‌تواند تولید کند، در هر واحدی که فروخته می‌شود، قیمت‌گذاری کنید و با صدای بلند بگویید مقایسه شما چه workloadی را فرض کرده است. این فاکتوری را که فصل 16 باز کرد می‌بندد، و Part III را هم می‌بندد: همه‌چیز از فصل 14 تا اینجا درباره یک call بوده است — چطور آن را بسازید، چه چیزی در آن بگذارید، چطور sample کنید، چه برمی‌گرداند، چه هزینه‌ای دارد.

فصل 22 واحد تحلیل را عوض می‌کند، و این تغییر گران است. یک agent یک call نیست؛ حلقه‌ای است که خودش تصمیم می‌گیرد چند call بسازد، و حساب دو فصل اخیر همان چیزی است که آن را از diagram معماری به budget تبدیل می‌کند. با پرسیدن همان سؤال از همان مدل دو بار شروع می‌شود، با یک tool اضافه‌شده به catalogue در بار دوم، و اندازه‌گیری اینکه آن یک tool چه کرد: یک call شد دو call، سی‌ونه input token شد 420.

اینکه آیا همین آن را agent می‌کند یا نه، بستگی دارد کدام‌یک از دو تعریف منتشرشده را باز کنید، و آن‌ها توافق ندارند. یکی از آن‌ها حتی با خودش هم توافق ندارد.

هر قیمت، فرمول و نرخ تبدیل در این فصل از صفحه خود provider در 7 سپتامبر 2026 خوانده شده و با همان تاریخ نقل می‌شود، چون همه‌شان جابه‌جا خواهند شد. token countها، هزینه‌ها و مقایسه‌ها روی آن data با کدی که بالا چاپ شد، روی یک ماشین، و بدون هیچ paid API call محاسبه شدند — که دلیل صادقانه نبودن حتی یک ادعای latency در این فصل هم هست.

توابع image-token، جدول‌های هزینه، breakdown تماس voice و نتایج empty-usage با TypeScript چاپ‌شده در این فصل تولید شدند، اجراشده روی Node 22. دیالوگ استفاده‌شده برای مقایسه voice، 149 کلمه است و با tiktoken تحت encoding ‏o200k_base به 188 token تبدیل شد؛ duration آن از نرخ اعلام‌شده 150 کلمه در دقیقه می‌آید، که parameter مقایسه است نه measurement. هر رقم provider، footnoteای دارد که صفحه مبدأش را نام می‌برد.