What Multimodal AI Actually Costs, Modality by Modality

A token has no modality

Ask a frontier-model vendor what a token costs, and the answer almost never depends on what the token represents. OpenAI bills GPT-5.4 at 2.50 dollars per million input tokens whether those tokens came from a paragraph or a photograph ^[3]. Google prices Gemini 3.5 Flash at 1.50 dollars per million input tokens, and its own pricing page lists that single rate for “text, image, video, audio” without a modality-specific line item ^[4]. Anthropic is the most explicit of the three: its vision documentation tells developers to “estimate cost” by multiplying an image’s token count “by the per-token price of the model you’re using” — the same price used for everything else in the request ^[8]. The unit price of a token is, in a specific and verifiable sense, modality-blind.

None of that means images and video are cheap. It means the expense has moved somewhere the sticker price does not show: into how many tokens a modality is actually converted into before the meter starts running. A short caption might cost thirteen tokens. The photograph it describes can cost a hundred times that before the model has read a single word of the prompt. A minute of video can cost as much as a chapter. This article works through where that multiplier comes from, using each vendor’s own published token-counting rules rather than a guess, then follows the same logic upstream — into what it costs to assemble a training set of paired images and text rather than plain text, what it costs to train a model that natively handles more than one modality, and what physical ceiling all of this puts on how much a model can actually be shown at once.

Four separate accounts make up the total, and they are worth keeping apart because they are paid by different people at different times: the per-request bill a caller sees on an invoice; the labour bill a dataset builder pays once, before any model exists; the compute bill a lab pays once, training the thing; and the storage and bandwidth bill that sits underneath all three and is rarely priced per token at all.

How three vendors count a picture

Start with the invoice, because it is the most precisely documented of the four and the easiest to check against a live source.

OpenAI’s current patch-based tokenizer, used by the GPT-5.4 family, divides an image into 32-pixel patches and counts $\lceil \mathrm{width}/32 \rceil \times \lceil \mathrm{height}/32 \rceil$ of them, subject to a per-request patch budget that forces a resize if the count runs too high ^[1]. A square 1024-by-1024 image needs no resizing and comes to exactly 1,024 patches — 32 across, 32 down. At GPT-5.4’s input rate, that one frame costs a little over a quarter of a cent: 1,024 tokens times 2.50 dollars per million comes to about 0.26 cents ^{[1, 3]}. The company’s earlier tile-based scheme, still documented for GPT-4o and GPT-4.1, works differently but lands in the same place: a flat base charge plus 170 tokens for every 512-pixel tile the image is carved into once it is scaled to fit within a 2048-pixel frame ^[1]. Two tokenizers, two constants, the same underlying shape — cost climbs with how finely the image gets sliced, not with what is in it.

Google’s Gemini models slice more coarsely by default and make the arithmetic explicit in their own documentation. An image with both dimensions at 384 pixels or under costs a flat 258 tokens; anything larger is broken into 768-by-768 tiles, each billed at 258 tokens, with the tile count set by the image’s own geometry. Google’s worked example is a 960-by-540 photograph, which divides into six tiles and comes to 1,548 tokens ^[5]. At Gemini 3.5 Flash’s rate of 1.50 dollars per million input tokens, that photograph costs about 0.23 cents; at the cheaper Gemini 3.7 Flash rate of 0.75 dollars per million, holding through the end of 2026, it costs about 0.12 cents ^[4]. By the ordinary rule of thumb that one token runs about three-quarters of an English word, 1,548 tokens is in the neighbourhood of eleven hundred words — the model pays roughly as much attention, measured in billable units, to one modest photograph as it would to three or four pages of prose.

Anthropic’s Claude models count in even smaller units: a visual token per 28-by-28-pixel patch, so an image costs $\lceil \mathrm{width}/28 \rceil \times \lceil \mathrm{height}/28 \rceil$ tokens up to a model-specific cap. Claude’s documentation lays out the arithmetic for several sizes without requiring a reader to compute anything: a 1000-by-1000 image comes to 1,296 tokens on every current tier; a 4K frame is capped at 4,784 tokens on the newer high-resolution tier introduced with Claude 4.7. The company has already done the dollar conversion for two of its own models — at Claude Haiku 4.5’s rate, a thousand of those 1000-by-1000 images cost about 1.30 dollars; at Claude Opus 5’s rate, the same thousand images cost about 6.48 dollars, and a thousand 4K images cost about 23.92 dollars ^[8]. Every one of those figures uses the model’s ordinary input-token price. There is no separate “vision surcharge” line item on any of the three platforms — only a token count that images generate in far greater volume than the words describing them would.

A single formula covers all three counting schemes if the tile or patch edge length is left as a free constant $P$, specific to the vendor:

with a request’s image cost simply $\mathrm{cost}_{\mathrm{image}} = N_{\mathrm{tok}}(H,W) \cdot p_{\mathrm{tok}}$ at the model’s own per-token price $p_{\mathrm{tok}}$. The constant differs — 28 pixels for Claude, 32 for GPT-5.4, roughly 768 divided into geometry-dependent tiles for Gemini — but the shape does not: token count, and therefore cost, scales with the area of the image, not its linear size. Doubling both width and height quadruples the token bill under every one of these three schemes. That is the single fact behind essentially every dollar figure in the rest of this section, and it is also why “send a smaller image” is the one universally effective cost lever a caller has, across all three vendors, without changing anything about the model itself.

What a second of video actually costs

Video inherits the same per-tile arithmetic and multiplies it by time. Google is again the most specific vendor to check, because Gemini’s video-understanding documentation breaks the rate down by component: at default media resolution, each sampled frame (taken at one frame per second) costs about 258 tokens and the accompanying audio track costs about 32 tokens per second, for a documented total of “approximately 300 tokens per second of video.” At the model’s low-resolution setting, the same second costs about 100 tokens — 66 for the frame plus 32 for audio ^[6]. In the notation above, that is

where $t$ is duration in seconds, $f$ the sampling rate, and $\tau_{\mathrm{frame}}$, $\tau_{\mathrm{audio}}$ the per-frame and per-second-of-audio token costs Google publishes. A minute of default-resolution video comes to roughly 18,000 tokens — about 2.7 cents at Gemini 3.5 Flash’s input rate, or about 1.35 cents at Gemini 3.7 Flash’s ^{[6, 4]}. That is understanding a minute of footage: having the model watch it once and answer questions about it.

Producing a minute of video is a different economic activity entirely, billed on a different meter. Google’s own pricing page lists Veo 3.1 video generation at 0.40 dollars per second for 720p or 1080p output and 0.60 dollars per second for 4K — 24 to 36 dollars for a single minute ^[4]. OpenAI’s Sora 2 API prices standard 720p generation at 0.10 dollars per second and its Pro tier at 0.30 to 0.70 dollars per second depending on resolution, six to forty-two dollars a minute. Both companies charge for generated video directly in dollars per second rather than routing it through the input-token meter at all — a tell that ingesting a modality and producing one are priced as separate businesses, not two prices on the same scale. Understanding a minute of video, on the token meter, costs roughly a thousandth of generating one.

The token-rate figures also fix a hard ceiling on how much video a single request can hold, independent of price. Google’s documentation describes Gemini’s current context windows as running to “1 million or more tokens” ^[7]. Dividing that budget by the video token rate gives the most a caller can put in front of the model before the context window itself — never mind the prompt or the answer — is exhausted: at roughly 300 tokens per second, a million-token budget holds a little under fifty-six minutes of default-resolution video; switched to the low-resolution setting, the same budget stretches to about two hours and forty-seven minutes. That trade is not a pricing decision so much as a hard physical one: resolution and duration draw from the same fixed pool, and a caller who wants both a feature-length runtime and full detail in every frame is asking for something the arithmetic above simply will not grant inside one context window, at any price.

The bill is not the price; it is the count

It is worth pausing on how strange this arrangement actually is, because it explains why “multimodal is more expensive” is true but easy to state in a way that misleads. The per-token price is set by the model — how much compute one forward pass over one token burns, roughly the same regardless of what that token encodes. The token count is set by the input — how many of those units a photograph or a clip has to be sliced into before the model can read it at all. A vendor could, in principle, keep image and video tokens billed at parity with text tokens forever and still make vision and video dramatically more expensive per request, simply because the tokenizer hands over so many more of them. That is exactly what the numbers above show happening: not a higher price for the same unit, but the same price for a radically larger number of units.

The one place this symmetry breaks is generation rather than understanding, and it is worth naming as a distinct, separately priced activity rather than folding it into the same story. OpenAI’s image-generation models are billed at an explicitly higher rate for output than for input — GPT-Image-1’s image-output tokens run 40 dollars per million against 5 dollars per million for text input tokens feeding the same request, and its newer GPT-Image-2 successor still prices output at 30 dollars per million against the same 5-dollar input rate ^[2]. Sora’s and Veo’s per-second video pricing sits even further from the input-token economy, priced in whole dollars per second rather than fractions of a cent per token. Reading a modality and producing one are not the same expense scaled by a constant; they are two different meters, and only one of them charges the same rate it charges for text.

What it costs to build the pairs in the first place

Move upstream of any single request, to the training data itself, and the cost story changes shape again — from a per-token price to a labour price, paid once by whoever assembled the dataset.

The original way to pair an image with text was to pay people to look at the image and write the text, and the accounting for that approach is unusually well documented. The paper introducing Microsoft’s COCO dataset reports that labelling roughly 2.5 million object instances into segmentation masks alone took “over 22 worker hours per 1,000 segmentations,” that category labelling across the dataset took about 20,000 worker hours, and that instance spotting took a further 10,000 — a total the authors put at “over 70,000 worker hours” for a dataset that, even so, produced just over a million human-written captions ^[17]. That is a real, bounded, human-priced cost, and it does not scale linearly to billions of examples; multiplying COCO’s effort by the thousand-fold jump to a billion-pair dataset would mean tens of millions of worker hours; it would take a large workforce years to complete.

Billion-scale image-text datasets exist because that multiplication was avoided rather than paid. LAION-5B’s 5.85 billion pairs were assembled by running a CLIP model over Common Crawl’s alt-text-labelled images and keeping only pairs whose image and text embeddings scored above a cosine-similarity threshold — the project’s own account puts the rejection rate at roughly ninety percent, reducing “50-plus billion candidates to just below 6 billion,” using 32 A100 GPUs running for about a week to score the pool ^{[9, 10]}. No person looked at any individual pair; the CLIP scoring model that made the filtering possible was itself trained on exactly this kind of noisy, uncurated web alt-text rather than gold-standard captions, which is the property that let it scale in the first place ^[11]. Video followed the same path once it needed similar scale. Panda-70M’s 70 million video-caption pairs, drawn from 3.8 million high-resolution clips selected out of the 100-million-clip HD-VILA corpus ^[14], were captioned not by people but by five separate automated “cross-modality teacher” models — Video LLaMA, VideoChat, VideoChat Text, BLIP-2 and MiniGPT-4 — with a small retrieval model, trained on a human-labelled subset, then used to pick the best of several machine-written captions for each clip at scale. The paper’s own framing is blunt about why: “manually annotating 70M videos is prohibitively expensive and time consuming” ^[13].

Text-only corpora sit a further step down this same cost ladder, because they require neither human judgment nor a second model’s inference pass over every example — mostly quality filters run once over text that was already digitised. RedPajama’s 1.2-trillion-token reproduction of the LLaMA training mix, built from Common Crawl, C4, GitHub, books, arXiv, Wikipedia and StackExchange, was compiled through pattern-based cleaning pipelines rather than any per-example labelling step at all ^[16]. The ordering that falls out of these four cases is not a matter of degree so much as of kind: human annotation costs worker-hours per example and does not scale past the low millions without a workforce years in the making; automated captioning costs one or more model inference passes per example and scales to the hundreds of millions; filtering already-digitised text costs neither, and scales to the trillions of tokens. Paired multimodal data got big only once curation stopped requiring a person, or later a model, to look at each individual pair — and each of those steps down in per-example cost bought scale at the price of exactly the noise a filtering pipeline, rather than a person, will always let through.

The storage and bandwidth nobody prices per token

None of the four accounts above is complete without the physical weight of the data itself, because that weight is paid in storage and bandwidth regardless of what any API charges per token.

The clearest side-by-side comparison is between the two text-and-image corpora already discussed. RedPajama’s 1.2 trillion tokens occupy about 5 terabytes of disk once unzipped ^[16] — a shade over 4 gigabytes for every billion tokens. LAION-5B’s own image-downloading toolchain documents a very different weight for the same rough job of “assemble a foundation-model training corpus”: pulling all 5.85 billion images at a modest 384-pixel resize comes to 220 terabytes, or roughly 38 kilobytes for every single pair once the image bytes are counted alongside its few dozen bytes of caption text ^[12]. Shrinking every image further, to 256 pixels, still only brings the total down to about 50 terabytes ^[12] — the floor is set by having any image at all, not by how aggressively it gets compressed. Video corpora carry the same weight forward at a larger scale still: the paper introducing the WebVid dataset reports 10 million clips totalling about 52,000 hours of footage ^[15], and HD-VILA-100M’s 100 million clips run to 371,500 hours drawn from 3.3 million source videos ^[14] — durations that dwarf anything a text corpus of comparable “size,” measured in training examples, would ever need to store.

That storage weight becomes a bandwidth bill the moment a dataset has to move — off a hyperscaler’s object store and onto the compute cluster that trains on it, or across a network link to a second site for redundancy — and it recurs every time the corpus is re-shuffled, re-filtered, or re-downloaded for a fresh training run, in a way a five-terabyte text corpus simply is not exposed to at the same frequency or the same cost. None of the three vendors in the earlier sections publishes a per-token price for this stage, because it is not billed per token at all; it is billed in the currency infrastructure teams actually use — per gigabyte moved and per terabyte-month stored — and it sits underneath every dollar figure quoted earlier in this article as a cost that has already been paid once, in full, before the first token is ever counted.

What it costs to train the model itself

The last account is the compute spent turning a curated, stored corpus into a trained model, and here two real, differently documented architectures give two very different answers to the same question — what it costs, in GPU-hours, to make a model see as well as it reads.

Meta’s Chameleon trains images and text as one shared token stream from the first step, an approach the paper’s own authors call early fusion ^[21]. Its 34-billion-parameter model, trained on Nvidia A100-80GB GPUs, took 4,282,407 GPU-hours according to the paper’s own compute table, and the authors state directly that they “successfully train Chameleon-34B on 5x the number of tokens as Llama-2” ^[21] — the paper elsewhere records 9.2 trillion tokens seen over 2.1 epochs of its full training set. Llama 2’s own paper, reporting on the same GPU generation, gives a clean same-size, text-only comparison: its 34-billion-parameter model — trained, though never released — took 1,038,336 A100-80GB GPU-hours over 2.0 trillion tokens ^[20]. Total compute for the native multimodal model at the same parameter count ran a little over four times higher. Measured per trillion tokens processed rather than in aggregate, though, Chameleon-34B was not more expensive to run than Llama-2-34B; at roughly 428,000 GPU-hours per trillion tokens against Llama 2’s roughly 519,000, the early-fusion model was, if anything, slightly cheaper per token on this specific pair of runs. The honest reading of that pair of numbers is not that early fusion carries no cost — different training stacks, cluster generations within the same GPU family, and achieved throughput could all still separate the two figures — but that the bulk of Chameleon-34B’s higher total bill traces to Meta’s decision to train on five times more data, a data-scale choice, rather than to some fixed multiplier that early fusion imposes on every token it touches.

Meta’s own Llama 3.2-Vision models took the opposite architectural route, and the same model-card discipline that reported the numbers above reports these too. Rather than training every modality jointly from the first step, Llama 3.2-Vision attaches a separately trained vision adapter — cross-attention layers feeding an image encoder’s output into an already-pretrained Llama 3.1 language model — a late-fusion design in the lineage this publication has covered elsewhere in this series. Meta’s own model card gives the compute by stage on H100-80GB GPUs: the 90-billion-parameter vision model’s pretraining and annealing stages alone came to 1,775,120 GPU-hours; its 11-billion-parameter sibling took 246,120 ^[19]. Llama 3.1’s own model card reports that pretraining the 70-billion-parameter text model those adapters attach to took 7.0 million H100-80GB hours on its own ^[18]. Adding native image understanding to an already-trained 70-billion-parameter text model, in other words, cost about a quarter as much again as training the text model cost in the first place — a real but comparatively modest surcharge, because most of the parameters and most of the compute were already paid for by the text-only run underneath it. (These two comparisons should not be read across each other: Chameleon and Llama 2 both trained on A100-80GB GPUs, while both Llama 3.2-Vision and Llama 3.1 trained on the newer H100-80GB, a materially faster part, so the fair comparison in each case is within its own hardware generation, not between them.)

Put the two side by side and a genuine finding falls out, not just an anecdote: how a lab chooses to make a model multimodal changes its compute bill by roughly an order of magnitude, at matched parameter count. Training every modality jointly from scratch, as Chameleon does, costs several times a comparable text-only run — driven chiefly by the extra data the joint objective was fed, on the one clean comparison available. Bolting a modality onto an already-trained text model through a frozen-backbone adapter, as Llama 3.2-Vision does, costs on the order of a quarter more than the text model alone. Neither number is “the cost of multimodality.” They are the costs of two different engineering decisions that both get marketed under that one word.

Predictions, with the observations that would falsify them

These are forecasts, kept separate from the sourced figures above. Horizon: 12 August 2028. Assumptions: no discontinuity in transformer-based tokenization comparable to the arrival of the architecture itself, continued commercial pressure to support image and video input, and continued public disclosure of at least some token-counting and training-compute figures by major vendors.

One. Per-token pricing will remain modality-uniform at the major API vendors — the same input rate for text, image, video and audio tokens on a given model — because differentiated per-modality pricing would require disclosing a cost breakdown vendors currently avoid publishing. Disconfirmed if two or more of OpenAI, Google or Anthropic introduce an explicit higher per-token rate for image or video input specifically, distinct from the token-count mechanism already documented.

Two. The gap between understanding a minute of video and generating one will narrow rather than hold at three orders of magnitude, as generation models adopt more of the KV-cache and batching efficiencies already standard in text and image-understanding serving. Indicator: a documented drop in per-second video-generation pricing exceeding the rate of general inference-cost decline. Disconfirmed if the ratio between generation and understanding pricing per second of video is materially unchanged from the figures in this article by the horizon date.

Three. Automated, model-based curation will keep displacing human annotation for new paired datasets at ever-larger scale, and manually captioned datasets comparable to COCO will remain a benchmark-construction tool rather than a pretraining-scale one. Disconfirmed if a widely adopted foundation-model training corpus in 2028 is shown to rely primarily on human-written captions at LAION-scale volume.

Four. Late-fusion, adapter-based approaches to adding a modality to an existing text model will remain the lower-compute route relative to training a comparable-size model multimodally from scratch, because most of the saving comes from reusing already-paid-for pretraining rather than from any efficiency specific to the adapter architecture. Disconfirmed if a published compute comparison shows an early-fusion, from-scratch multimodal model trained for total compute at or below a matched-size late-fusion adapter approach, controlling for token count.

What to take away

Multimodal AI is not one price rise; it is four separate, separately paid accounts wearing one name. The per-request bill stays close to text’s per-token price and grows instead through token count, which climbs with the area of an image or the duration of a clip under every vendor’s own documented formula. The data-curation bill fell from tens of thousands of worker-hours per few hundred thousand examples to a week of GPU time per several billion, and it fell specifically because human judgment was replaced with automated filtering and captioning, at a cost in noise this article has only gestured at. The storage and bandwidth bill sits underneath all of it, unpriced per token, and runs to tens of thousands of times the weight of a text corpus of comparable scale. And the training-compute bill depends entirely on which of two architectural strategies a lab chooses — joint training from scratch, at several times a comparable text-only run, or a bolted-on adapter, at a comparatively modest surcharge on an already-trained model.

None of these four numbers substitutes for any of the others, and no single “multimodal costs more” headline captures what any specific one of them is doing. Ask which of the four accounts is actually in question — the invoice, the labour, the compute, or the storage — before accepting a claim about what going multimodal costs, and ask it before choosing which architecture to build, because the four accounts do not move together and a design decision that is cheap on one of them is routinely expensive on another.