Multimodal Pricing: 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 में यही लिखा है: an image is worth 16 × 16 words.¹ positional encoding जोड़ें ताकि model जान सके कौन-सा square कहाँ था, results को text embeddings के साथ interleave करें, और जो sequence model पढ़ता है वह आधी picture और आधी sentence होती है।

तीन papers ने इसे product बनाया। CLIP ने चार सौ million scraped pairs पर image encoder और text encoder को सहमत होना सिखाया, और यहीं pixels और words के shared space की 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 हैं, इसलिए आप उनके लिए input rate पर pay करते हैं। कितने हैं, यह arithmetic है, और हर provider इसे अलग तरह से करता है।

नीचे का हर rule provider की अपनी documentation से implement किया गया है और उसी documentation में दिए worked examples के against check किया गया है।

OpenAI image को 32 × 32 patches से cover करता है और count को per-model factor से multiply करता है। अगर patch count उस model और detail level के budget से अधिक हो जाए, तो image को fit होने तक scale down किया जाता है:

Anthropic इसे 28 × 28 patches से cover करता है, हर patch एक visual token, और long edge और token count दोनों पर cap लगाता है — standard-tier models पर 1,568 pixels और 1,568 tokens, high-resolution tier पर 2,576 और 4,784। Oversized images को उन दोनों में fit होने वाले सबसे बड़े size तक scale किया जाता है।⁵

Google pixels count ही नहीं करता। जिस image के दोनों sides 384 pixels या कम हैं, उसकी flat cost 258 tokens है। उससे बड़ी कोई भी image 258 tokens वाले 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 के against run करें:

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 पंद्रह check करता है, क्योंकि Anthropic की table सभी छह sizes के लिए दोनों tiers देती है। Rules अब आपके हैं, किसी भी photograph पर चलाने के लिए — और यही point है: इस chapter में ये ही तीन functions हैं जो आपको price page से नहीं मिल सकते।

उसी 4:3 photograph को छह sizes पर तीनों से गुज़ारें:

आखिरी column को नीचे की ओर पढ़ें। picture 384 pixels से ऊपर होते ही number फिर कभी नहीं बदलता, और यह coincidence या cap नहीं है। कम से कम जितनी wide उतनी tall image के लिए crop unit को tile formula में वापस substitute करें:

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 पर और अलग reasons से — Anthropic declared token ceiling पर, OpenAI pixel limit के बाद patch budget पर — इसलिए तीन curves अलग-अलग sizes पर cross करती हैं।

अब इसे तोड़ें। vision model पर कम खर्च करने का obvious तरीका less detail माँगना है, इसलिए detail: "low" भेजें:

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

कम detail माँगने की cost 25 % ज्यादा निकली। यह bug नहीं है और OpenAI sizing table की एक line में ऐसा कहता है: उस model family पर, low 2048-pixel limit और 6,144-patch budget use करता है जबकि high वही pixel limit और 2,500-patch budget use करता है, “so it can use more tokens than high”.⁷ शब्द low fidelity setting का नाम है, price का नहीं: documented पाँच model families में से दो पर इससे कोई saving नहीं मिलती, और उनमें से एक पर यह ज्यादा cost करता है।

अब तक सब कुछ image read करने वाले model के बारे में था। image बनाना ऐसे mechanism पर चलता है जिसमें tokens होते ही नहीं, और इसी वजह से वह word के बजाय picture के हिसाब से बिकता है।

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 करें:

नौ published figures के against नौ derived 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 लें और उल्टा 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

हर quality पर बड़ी image सस्ती है। 1024 × 1536 canvas, 1024 × 1024 से 50 % ज्यादा pixels है और medium पर 23 % कम tokens cost करता है। 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” — और पिछले model generation पर यह उल्टा चलता था, portrait square से 50 % ज्यादा cost करता था।¹¹ उस change से पहले लिखे 1024x1024 के हर default अब expensive option हैं।

तीन products से वही 519 characters बोलने को कहें — लगभग 38 seconds का audio — और दो vendors से तीन unit systems मिलते हैं:

Same vendor दोनों units बेचता है: OpenAI का tts-1 per million characters price है जबकि gpt-4o-mini-tts per million tokens price है, $0.60 in और $12.00 out।¹³ इसलिए “cheapest text-to-speech” ऐसा सवाल नहीं है जिसका answer हो, जब तक आप यह न कहें कि आप क्या बोल रहे हैं।

और दोनों units opposite चीज़ों से blind हैं। Per-character price duration नहीं देख सकता: slow, deliberate voice चुनें, या pauses जोड़ें, bill नहीं बदलता जबकि audio लंबा हो जाता है। Per-second price content नहीं देख सकता: तीस seconds की cost उतनी ही है, चाहे वह dense technical paragraph हो या कोई दस तक गिन रहा हो। Voice बदलें और आपके दो vendors में ठीक एक reprices करता है।

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 के against आखिरी row note करें: words आते ही live करना, finished file पर करने से 5.7 गुना cost करता है। यह gap batch न कर पाने की कीमत है, और यही अगले section को expensive बनाता है।

अब वह number जो decide करता है कि voice feature है या product।

Call: ten-turn support conversation, 149 words, जो declared 150 words per minute पर 59.6 seconds की 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 में measured है।

अब comparison जो product decide करता है, सभी चार को एक minute पर normalise करके:

Thirty-eight times. Thirty-eight per cent नहीं। वही identical exchange, sound में conducted instead of text, लगभग दो orders of magnitude महँगा है, और उस gap में से कुछ भी ऐसा margin नहीं है जिसे किसी ने charge करने के लिए चुना — यह 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 का bill text output rate से 5.3 गुना और text input rate से 16 गुना लगता है। Bulk ratio को price ratio से multiply करें और accounting शुरू होने से पहले ही order of magnitude आ चुका होता है।

Table से दो operational consequences सीधे निकलते हैं।

Audio caching optimisation नहीं, business model है। Cached audio input $0.40 per million है जबकि fresh $32.00 — 98.75 % discount जो call को आधा कर देता है। Rule Chapter 16 का है, unchanged: cache prefix match करता है, इसलिए conversation के front में mid-call कुछ भी insert करने से वह destroy हो जाता है, और “caller is now verified” रखने की natural जगह ठीक वही है।

और client में आप कुछ भी करें, sound un-bill नहीं होता। User assistant के ऊपर बोलता है, आपका code playback रोक देता है, speaker quiet हो जाता है। जो भी already generate हो चुका था वह already charged था, क्योंकि billing response create होते समय accrue होती है; और Chapter 16 के rule के अनुसार जो भी conversation में रहता है वह बाद के हर turn पर input audio के रूप में फिर भेजा जाता है। Chapter 14 ने text stream abort करने के बारे में यही point बनाया था। Voice में इसकी cost तीस गुना ज्यादा है।

Video कुछ vendors per second बेचते हैं और कुछ per clip, resolution और कभी-कभी duration के tiers के साथ। ये दो shapes सिर्फ convenience में अलग नहीं हैं; ये cross करते हैं।

Per-clip vendor 1.2 seconds से नीचे per-second वाले से महँगा है और twenty पर 16.7 times cheaper। Clip length change होते ही उन दो models की कोई ordering survive नहीं करती, इसलिए “कौन-सा video model cheapest है” models के बारे में सवाल नहीं है।

Last row worse है, और chapter का honest heart है। mochi real GPU seconds के against bill होता है — job का measured prediction time — A100 पर $0.001400 per second और H100 पर $0.001525, जो rented machine के rates हैं और कुछ नहीं।¹⁵ यह बिल्कुल precise tariff है और price नहीं है, क्योंकि वह quantity जिससे इसे multiply करना है, आपके pay करने की commitment के बाद तक unknown है। ऊपर की row output के हर second के लिए twelve GPU-seconds assume करती है; उस assumption को quadruple करें और यह cheapest band छोड़ देती है, और छह गुना पर जाकर mid-table में land करती है। यह इस 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 zero है। दोनों को empty usage दें — वही 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

कुछ नहीं हुआ, छह बार, और एक बार cost तीन dollars आई और पाँच बार कुछ नहीं। यह rounding difference नहीं है; यह decision है कि absent number का मतलब क्या है, हर unit के लिए अलग-अलग लिया गया और कहीं लिखा नहीं गया। सही rule यह है कि ऐसा field जिसे किसी ने measure नहीं किया absent रहता है, क्योंकि “not measured” और “measured and came out zero” अलग चीज़ें हैं। यह function चुपचाप disagree करता है।

Second failure duration है। Clip-priced tariff अपना tier maxDurationSeconds से u.videoSeconds ?? 0 के against select करता है, इसलिए ऐसी usage जिसने duration record ही नहीं की, shortest tier match करती है:

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

Video कितनी लंबी थी यह न जानने पर forty per cent off। दोनों bugs की root वही है: convenience के लिए चुना गया default, ऐसे function के अंदर जिसका पूरा काम exact होना है।

Costs computable होने के बाद comparison को दूसरा half चाहिए — हर engine के लिए एक declared representative workload, 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 को अलग 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 है, और available अकेली honest method है: आप अलग-अलग units में prices compare नहीं कर सकते; आप केवल उस workload की cost compare कर सकते हैं जिसे आपने लिखकर declare किया है। कोई भी table जो अपना workload print किए बिना multimodal models rank करती है, अपने assumptions rank कर रही है।

अब आप model जो भी produce कर सकता है उसकी कीमत लगा सकते हैं, चाहे वह जिस unit में बिके, और जोर से कह सकते हैं कि आपकी comparison ने कौन-सा workload assume किया। इससे वह invoice बंद होता है जिसे Chapter 16 ने खोला था, और Part III भी बंद होता है: Chapter 14 से यहाँ तक सब कुछ one call के बारे में था — उसे कैसे बनाना है, उसमें क्या डालना है, उसे कैसे sample करना है, वह क्या return करता है, उसकी cost क्या है।

Chapter 22 unit of analysis बदलता है, और यह change expensive है। agent one call नहीं है; वह loop है जो खुद decide करता है कि कितनी calls करनी हैं, और पिछले दो chapters का arithmetic ही उसे architecture diagram से budget में बदलता है। वह उसी model से वही सवाल दो बार पूछकर शुरू होता है, दूसरी बार catalogue में एक tool जोड़कर, और यह measure करके कि उस एक tool ने क्या किया: one call two बन गई, thirty-nine input tokens 420 बन गए।

क्या इससे वह agent बनता है, यह इस पर depend करता है कि आप दो published definitions में से कौन-सी खोलते हैं, और वे agree नहीं करतीं। उनमें से एक खुद से भी agree नहीं करती।

इस chapter में हर price, formula और conversion rate provider के अपने page से 7 September 2026 को पढ़ा गया और उसी date के साथ quote किया गया है, क्योंकि ये सब बदलेंगे। token counts, costs और comparisons उस data पर ऊपर printed code से, एक machine पर, बिना किसी paid API call के compute किए गए — और यही honest reason भी है कि इस chapter में एक भी latency claim नहीं है।

Image-token functions, cost tables, voice-call breakdown और empty-usage results इस chapter में printed TypeScript से produce किए गए, Node 22 पर run करके। Voice comparison के लिए used dialogue 149 words का है और tiktoken के साथ o200k_base encoding के तहत 188 tokens पर tokenized हुआ; उसकी duration 150 words per minute की declared rate से आती है, जो comparison का parameter है, measurement नहीं। हर provider figure उस footnote को carry करता है जो उस page का नाम बताता है जिससे वह आया।