Multimodal قیمتیں: images، audio اور video پر اصل بل کیسے بنتا ہے

ایک transformer vectors کی sequence لیتا ہے۔ اسے اس سے کوئی غرض نہیں کہ وہ کہاں سے آئے۔ Chapter 8 نے اسے token id سے lookup کی گئی embeddings کھلائی تھیں؛ architecture میں کوئی چیز lookup کو لازمی نہیں بناتی۔

تو: picture کو fixed squares میں کاٹیں، ہر square کو numbers کی list میں flatten کریں، اور ہر list کو ایک learned linear layer سے گزار کر model کی width کا vector حاصل کریں۔ Colour pixels کا 32 × 32 patch $32 \times 32 \times 3 = 3072$ numbers ہے؛ projection $E \in \mathbb{R}^{d \times 3072}$ اسے ایک $d$-dimensional vector میں بدلتا ہے، بالکل اسی shape میں جس میں text token آتا ہے۔ بس یہی سارا معاملہ ہے، اور یہ وہ paper ہے جس کا title خود کہتا ہے: ایک image کی قیمت 16 × 16 words کے برابر ہے۔¹ Positional encoding شامل کریں تاکہ model جان سکے کہ کون سا square کہاں تھا، results کو text embeddings کے ساتھ interleave کریں، اور model جو sequence پڑھتا ہے وہ جزوی picture اور جزوی sentence بن جاتی ہے۔

تین papers نے اسے product بنایا۔ CLIP نے ایک image encoder اور ایک text encoder کو چار سو million scraped pairs پر اس بات پر agree کرنا سکھایا کہ pixels اور words ایک space share کر سکتے ہیں؛ وہیں یہ idea hypothesis رہنا چھوڑ گیا۔² Flamingo نے frozen vision encoder کو frozen language model کے ساتھ چند trained bridging layers کے ذریعے جوڑ دیا۔³ LLaVA نے دکھایا کہ bridge ایک single linear projection ہو سکتا ہے اور instruction-following generated data سے سکھائی جا سکتی ہے، اسی لیے اس کے بعد ہر open vision-language model تقریباً ایک ہی شکل کا دکھائی دیتا ہے۔⁴

آپ کے invoice کے لیے consequence فوری اور بے زرق ہے: patches sequence میں positions ہیں، اس لیے وہ input tokens ہیں، اس لیے آپ ان کی payment input rate پر کرتے ہیں۔ کتنے ہوں گے، یہ arithmetic ہے، اور ہر provider اسے مختلف طریقے سے کرتا ہے۔

نیچے ہر rule provider کی اپنی documentation سے implement کیا گیا ہے اور اسی documentation کی worked examples کے خلاف check کیا گیا ہے۔

OpenAI image کو 32 × 32 patches سے cover کرتا ہے اور count کو per-model factor سے multiply کرتا ہے۔ اگر patch count اس model اور detail level کے budget سے بڑھ جائے، تو image کو scale down کیا جاتا ہے جب تک وہ fit نہ ہو جائے:

Anthropic اسے 28 × 28 patches سے cover کرتا ہے، ہر ایک visual token، اور long edge اور token count دونوں پر caps لگاتا ہے — standard-tier models پر 1,568 pixels اور 1,568 tokens، high-resolution tier پر 2,576 اور 4,784۔ Oversized images کو اس largest size تک scale کیا جاتا ہے جو دونوں میں fit ہو۔⁵

Google pixels بالکل count نہیں کرتا۔ جس image کی دونوں sides 384 pixels یا اس سے کم ہوں وہ flat 258 tokens خرچ کرتی ہے۔ اس سے بڑی ہر چیز 258 tokens فی tile کے tiles میں کٹتی ہے، اور tile grid $\lfloor \min(w,h) / 1.5 \rfloor$ کے crop unit سے بنتی ہے۔⁶

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 کے printed numbers کے خلاف چلائیں:

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

نو agreements print ہوتے ہیں؛ full run پندرہ checks کرتا ہے، کیونکہ Anthropic کی table تمام چھ sizes کے لیے دونوں tiers دیتی ہے۔ Rules اب آپ کے ہیں کہ اپنی کسی بھی photograph پر چلائیں، اور یہی point ہے: یہ اس chapter کے وہ صرف تین functions ہیں جو آپ price page سے حاصل نہیں کر سکتے۔

ایک ہی 4:3 photograph کو چھ sizes پر تینوں سے گزاریں:

آخری column کو نیچے کی طرف پڑھیں۔ Picture کے 384 pixels سے اوپر جاتے ہی number پھر کبھی نہیں بدلتا، اور یہ coincidence یا cap نہیں ہے۔ Crop unit کو tile formula میں واپس substitute کریں، ایسی image کے لیے جو کم از کم اتنی wide ہو جتنی tall:

Size cancel ہو جاتا ہے۔ Google کے image tokens aspect ratio پر depend کرتے ہیں، اور کسی چیز پر نہیں۔ 4:3 photograph چار tiles ہے، چاہے وہ thumbnail ہو یا poster۔ یہی single algebraic fact اوپر savings table میں zero کی پوری explanation ہے، اور کوئی price page اسے کہیں نہیں لکھتا۔

باقی دو columns cap کرتے ہیں، مگر مختلف heights پر اور مختلف وجوہات سے — Anthropic declared token ceiling پر، OpenAI pixel limit کے بعد patch budget پر — اسی لیے تین curves مختلف sizes پر cross کرتے ہیں۔

اب اسے توڑیں۔ Vision model پر کم خرچ کرنے کا obvious طریقہ کم detail مانگنا ہے، تو detail: "low" بھیجیں:

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

کم detail مانگنے کی قیمت 25 % زیادہ نکلی۔ یہ bug نہیں ہے اور OpenAI sizing table کی ایک line میں خود کہتا ہے: اس model family پر، low 2048-pixel limit اور 6,144-patch budget استعمال کرتا ہے جبکہ high وہی pixel limit مگر 2,500-patch budget استعمال کرتا ہے، “so it can use more tokens than high”۔⁷ لفظ low fidelity setting کا نام ہے، price کا نہیں: documented پانچ model families میں سے دو پر یہ کوئی saving نہیں دیتا، اور ان دو میں سے ایک پر زیادہ خرچ کرواتا ہے۔

اب تک ہر چیز ایک model کے image پڑھنے کے بارے میں تھی۔ Image بنانا ایسے mechanism پر چلتا ہے جس میں tokens بالکل نہیں ہوتے، اور یہی وجہ ہے کہ اسے word کے بجائے picture کے حساب سے sold کیا جاتا ہے۔

Vendors image generation کو per picture price کے طور پر publish کرتے ہیں۔ یہ ویسا نہیں۔ GPT Image models specialised image tokens emit کرتے ہیں جن کا count requested size اور quality پر depend کرتا ہے؛ published counts کو GPT Image 1 کے published image output rate $40 per million سے multiply کریں اور اسی page پر per-image prices سے compare کریں:

نو derived figures نو published figures کے خلاف، ہر pair $0.002 کے اندر agree کرتا ہے۔¹¹ Google اس سے بھی زیادہ explicit ہے اور price page پر conversion خود کر دیتا ہے: image output $60 per million tokens پر، “output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image”۔¹²

تو per-image price ایک per-token price ہے جس میں count fold کر دیا گیا ہے۔ یہ ٹھیک ہے، اور یہ ایک چیز چھپاتا ہے۔ Current generation کی table لیں اور backwards divide کریں:

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

بڑی image ہر quality پر سستی ہے۔ 1024 × 1536 canvas میں 1024 × 1024 سے 50 % زیادہ pixels ہیں اور medium پر 23 % fewer tokens خرچ کرتا ہے۔ OpenAI اسے ایک ایسے sentence میں flag کرتا ہے جسے آپ skip کر دیں گے — “a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting” — اور previous model generation پر یہ الٹا چلتا تھا، portrait square سے 50 % زیادہ costly تھا۔¹¹ اس change سے پہلے لکھا گیا 1024x1024 کا ہر default اب expensive option ہے۔

تین products سے ایک ہی 519 characters بولنے کو کہیں — تقریباً 38 seconds کی audio — تو دو vendors سے تین unit systems ملتے ہیں:

وہی vendor دونوں units فروخت کرتا ہے: OpenAI کا tts-1 per million characters priced ہے جبکہ gpt-4o-mini-tts per million tokens priced ہے، $0.60 in اور $12.00 out۔¹³ اس لیے “cheapest text-to-speech” ایسا سوال نہیں جس کا answer ہو، جب تک آپ یہ نہ کہیں کہ آپ کیا بولوا رہے ہیں۔

اور دونوں units opposite چیزوں سے blind ہیں۔ Per-character price duration نہیں دیکھ سکتی: slow، deliberate voice choose کریں، یا pauses add کریں، bill نہیں بدلتا جبکہ audio longer ہو جاتی ہے۔ Per-second price content نہیں دیکھ سکتی: thirty seconds کی قیمت ایک جیسی ہے چاہے وہ dense technical paragraph ہو یا کوئی ten تک count کر رہا ہو۔ Voice بدلیں اور آپ کے دو vendors میں سے exactly ایک reprice کرتا ہے۔

Transcription الٹی سمت چلتی ہے اور پورے invoice کی سب سے simple line ہے — per minute of audio، 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)

تیسری row کے مقابل last row note کریں: words آتے ہی اسے live کرنا، finished file پر کرنے سے 5.7 times costly ہے۔ یہ gap batch نہ کر سکنے کی price ہے، اور یہی next section کو expensive بناتا ہے۔

اب وہ number جو decide کرتا ہے کہ voice feature ہے یا product۔

Call: ten-turn support conversation، 149 words، جو declared 150 words per minute پر 59.6 seconds of speech ہے — 21.2 caller نے بولے، 38.4 واپس بولے گئے۔ Token conversions providers کے اپنے ہیں۔ 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: دونوں directions میں 25 tokens per second، جس کی price page اسی line پر $12.00 per million اور $0.018 per minute publish کر کے confirm کرتا ہے۔¹²

Conversation بالکل اسی طرح accumulate کرتی ہے جیسے Chapter 16 نے کہا تھا، کیونکہ mechanism وہی ہے: “the entire conversation is sent to the model for each Response... thus turns later in the session will be more expensive”۔¹⁴ بس اب history audio tokens میں measure ہو رہی ہے۔

اب وہ comparison جو product decide کرتا ہے، چاروں کو ایک minute پر normalise کیا گیا:

Thirty-eight times۔ Thirty-eight per cent نہیں۔ وہی identical exchange، text کے بجائے sound میں conducted، تقریباً دو orders of magnitude مہنگا ہے، اور اس gap میں سے کوئی margin ایسا نہیں جو کسی نے charge کرنے کے لیے choose کیا ہو — یہ conversion rate ہے۔ Assistant audio کا ایک second بیس tokens ہے۔ وہی second declared rate پر 2.5 words carry کرتا ہے، اور measured transcript 1.26 tokens per word پر چلتا ہے، اس لیے text کے طور پر یہ 3.15 tokens ہے۔ Sound اسی meaning کے لیے 6.3 times bulkier package ہے، اور اس کا ہر token text output rate سے 5.3 times اور text input rate سے 16 times پر billed ہے۔ Bulk ratio کو price ratio سے multiply کریں تو order of magnitude accounting شروع ہونے سے پہلے ہی موجود ہے۔

Table سے دو operational consequences سیدھے نکلتے ہیں۔

Audio caching optimisation نہیں، business model ہے۔ Cached audio input $0.40 per million ہے fresh کے $32.00 کے مقابل — 98.75 % discount جو call کو half کر دیتا ہے۔ Rule Chapter 16 کا ہے، unchanged: cache prefix match کرتا ہے، اس لیے mid-call conversation کے front پر insert کی گئی کوئی بھی چیز اسے destroy کر دیتی ہے، اور “the caller is now verified” رکھنے کی natural جگہ بالکل وہیں ہے۔

اور client میں آپ جو بھی کریں، sound un-bill نہیں ہوتا۔ User assistant کے اوپر بولتا ہے، آپ کا code playback stop کرتا ہے، speaker quiet ہو جاتا ہے۔ جو کچھ already generate ہو چکا تھا وہ already charged تھا، کیونکہ billing response create ہوتے وقت accrue ہوتی ہے؛ اور Chapter 16 کے rule کے مطابق جو کچھ conversation میں رہتا ہے وہ ہر اگلے turn پر input audio کے طور پر re-sent ہوتا ہے۔ Chapter 14 نے یہ point text stream abort کرنے کے بارے میں بنایا تھا۔ Voice میں یہ thirty times more costly ہے۔

Video کچھ vendors per second بیچتے ہیں اور کچھ per clip، resolution کے tiers کے ساتھ اور کبھی duration کے لیے بھی۔ یہ دو shapes صرف convenience میں مختلف نہیں؛ وہ cross کرتی ہیں۔

Per-clip vendor 1.2 seconds سے کم پر per-second vendor سے dearer ہے اور twenty پر 16.7 times cheaper۔ ان دو models کی کوئی ordering clip length بدلنے کے بعد survive نہیں کرتی، اس لیے “which video model is cheapest” models کے بارے میں سوال نہیں ہے۔

Last row بدتر ہے، اور یہی chapter کا honest heart ہے۔ mochi real GPU seconds کے خلاف billed ہے — job کا measured prediction time — A100 پر $0.001400 per second اور H100 پر $0.001525، جو rented machine کے rates ہیں اور کچھ نہیں۔¹⁵ یہ بالکل precise tariff ہے اور یہ price نہیں ہے، کیونکہ جس quantity سے یہ multiply ہوتا ہے وہ تب تک unknown ہے جب تک آپ payment commit نہ کر چکے ہوں۔ اوپر والی row output کے ہر second کے لیے twelve GPU-seconds assume کرتی ہے؛ اس assumption کو quadruple کریں تو یہ cheapest band چھوڑ دیتی ہے، اور صرف six times پر mid-table میں پہنچتی ہے۔ یہ اس page کا واحد tariff ہے جسے آپ quote میں نہیں رکھ سکتے۔

تو: tokens، image tokens، characters، minutes، video seconds، whole clips، GPU seconds، flat units۔ آٹھ quantities، اور انہیں ایک axis پر رکھنے کا واحد طریقہ workload declare کرنا اور اسے price کرنا ہے۔

یہ Chapter 16 کے computeCost کی extension ہے — وہی tier machinery، اب ایسے criteria کے ساتھ جو 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;
}

دو marked lines وہ ہیں جہاں یہ ٹوٹتا ہے۔ Per unit quoted tariff u.images ?? 1 سے multiply کرتا ہے؛ per token quoted tariff ایسی چیز سے multiply کرتا ہے جو default to zero کرتی ہے۔ دونوں کو empty usage feed کریں — وہ shape جو measurement fail ہونے پر ملتی ہے — اور دیکھیں:

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

چھ بار کچھ نہیں ہوا، اور ایک بار تین dollars cost آئے اور پانچ بار کچھ نہیں۔ یہ rounding difference نہیں؛ یہ اس بات کا decision ہے کہ absent number کا مطلب کیا ہے، ہر unit کے لیے الگ لیا گیا اور کبھی لکھا نہیں گیا۔ درست rule یہ ہے کہ field جسے کسی نے measure نہیں کیا absent رہتی ہے، کیونکہ “not measured” اور “measured and came out zero” مختلف چیزیں ہیں۔ یہ function خاموشی سے disagree کرتا ہے۔

دوسری failure duration ہے۔ Clip-priced tariff اپنا tier maxDurationSeconds کو u.videoSeconds ?? 0 کے خلاف select کرتا ہے، اس لیے ایسی usage جس نے duration record ہی نہیں کی shortest tier سے match ہو جاتی ہے:

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

Video کی length نہ جاننے پر forty per cent off۔ دونوں bugs کی root ایک ہی ہے: ایک function کے اندر convenience کے لیے chosen default، جبکہ اس function کا پورا کام exact ہونا ہے۔

Costs computable ہونے کے بعد comparison کو دوسری half چاہیے — ایک declared representative workload، ہر engine کے لیے ایک، public میں stated تاکہ reader disagree کر سکے:

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

ان میں سے ہر line ایک argument ہے۔ Text ایک quarter input اور three quarters output mix کرتا ہے کیونکہ real usage output کی طرف skew کرتی ہے؛ fifty-fifty blend models کو differently rank کرتا ہے۔ Image workload 1,500 output tokens assume کرتا ہے، OpenAI کے medium square کے 1,056 اور medium portrait کے 1,584 کے درمیان۔ Video 1080p پر five seconds assume کرتا ہے، اور ہم ابھی دیکھ چکے ہیں کہ دو vendors 1.2 seconds پر places swap کرتے ہیں۔ Compute entry sixty GPU-seconds assume کرتی ہے کیونکہ assume کرنے کو اور کچھ نہیں۔

یہی method ہے، اور یہی واحد honest method available ہے: آپ مختلف units میں prices compare نہیں کر سکتے؛ آپ صرف اس workload کی cost compare کر سکتے ہیں جسے آپ نے لکھا ہو۔ کوئی بھی table جو workload print کیے بغیر multimodal models rank کرتی ہے، اپنی assumptions rank کر رہی ہوتی ہے۔

اب آپ ہر وہ چیز price کر سکتے ہیں جو model produce کر سکتا ہے، جس unit میں بھی وہ sold ہو، اور بلند آواز میں کہہ سکتے ہیں کہ آپ کے comparison نے کون سا workload assume کیا۔ یہ وہ invoice بند کرتا ہے جو Chapter 16 نے کھولا تھا، اور Part III بھی بند کرتا ہے: Chapter 14 سے یہاں تک سب کچھ ایک call کے بارے میں تھا — اسے کیسے make کرنا ہے، اس میں کیا put کرنا ہے، اسے کیسے sample کرنا ہے، یہ کیا return کرتا ہے، اس کی cost کیا ہے۔

Chapter 22 analysis کی unit بدلتا ہے، اور یہ change expensive ہے۔ Agent ایک call نہیں؛ یہ loop ہے جو خود decide کرتا ہے کہ کتنی calls کرنی ہیں، اور پچھلے دو chapters کی arithmetic ہی اسے architecture diagram سے budget میں بدلتی ہے۔ یہ اسی model سے ایک ہی سوال دو بار پوچھ کر شروع ہوتا ہے، دوسری بار catalogue میں ایک tool add کر کے، اور measure کرتا ہے کہ اس ایک tool نے کیا کیا: ایک call دو بن گئی، thirty-nine input tokens 420 بن گئے۔

یہ اسے agent بناتا ہے یا نہیں، اس کا depend اس بات پر ہے کہ آپ دو published definitions میں سے کون سی کھولتے ہیں، اور وہ agree نہیں کرتیں۔ ان میں سے ایک خود سے بھی agree نہیں کرتی۔

اس chapter میں ہر price، formula اور conversion rate provider کے اپنے page سے 7 September 2026 کو read کیا گیا اور اسی date کے ساتھ quoted ہے، کیونکہ یہ سب move ہوں گے۔ Token counts، costs اور comparisons اس data پر اوپر printed code سے compute کیے گئے، ایک machine پر، کسی paid API call کے بغیر — یہی honest وجہ بھی ہے کہ اس chapter میں ایک بھی latency claim نہیں ہے۔

Image-token functions، cost tables، voice-call breakdown اور empty-usage results اس chapter میں printed TypeScript سے produce کیے گئے، Node 22 پر run کر کے۔ Voice comparison کے لیے dialogue 149 words کا ہے اور tiktoken کے ساتھ o200k_base encoding کے تحت 188 tokens پر tokenized ہوا؛ اس کی duration 150 words per minute کے declared rate سے آتی ہے، جو comparison کا parameter ہے، measurement نہیں۔ ہر provider figure کے ساتھ وہ footnote ہے جو اس page کا نام لیتا ہے جہاں سے یہ آیا۔