How Image and Video Input Actually Bills

Image and video input billing is the least standardized corner of AI API pricing: every vendor charges per token, but a token of image is not a defined quantity. At least five different pixel-to-token conversion rules coexist across the major APIs, and three vendors publish a per-token price while publishing no conversion at all — which means their image costs cannot be budgeted before the invoice arrives.

The stakes compound quietly. The same 1024×1024 screenshot bills anywhere from 384 to 1,601 tokens depending purely on which published rule processes it — a roughly 4.2× spread before any per-token price difference is applied. Where both a published formula and a published rate exist, the dollar cost of that one image runs from roughly $0.0008 on Gemini Flash’s standard rate to roughly $0.0068 at Claude Opus 5’s high-resolution tier — nearly a nine-fold gap for identical pixels.

One boundary sentence before anything else: this reference prices what it costs to feed images and video in — our cost-per-finished-second reference is the output-side companion that prices generating video, and our image generation pricing comparison owns the output side for images. Likewise, our tokenizer cost variance reference covers how text becomes tokens; this page covers how pixels do. Every number below was fetched from vendor documentation on August 26, 2026, and every derived cell is recomputed from the vendor’s own stated formula.

When a pricing page says “$X per million input tokens,” that number is only half the bill for multimodal input. The other half is the conversion: how many tokens does your image become? For text, the tokenizer answers that (imperfectly — see the variance reference above). For pixels, the answer depends entirely on vendor-specific preprocessing: tiling, patching, resizing, caps, and detail parameters that can move the token count by multiples without any change to the headline rate.

Across the vendors and gateways in this reference, the answers sort into three honesty classes — and the third class is the reason this page exists.

OpenAI is the only vendor in this set running two accounting regimes at once, split by model generation. Older vision models bill a base token count plus a per-tile charge; the current generations count 32×32-pixel patches with a multiplier. Both are fully documented in the images and vision guide, retrieved August 26, 2026.

Run the patch rule on our test image, on gpt-5.4 at detail: high: ceil(1024/32) × ceil(1024/32) = 1,024 patches, inside that detail level’s 2,048px dimension cap so no resize applies, and ceil(1024 × 1.2) = 1,229 billable tokens — our arithmetic from OpenAI’s published rule.

Under the tile regime, the same image resizes to 768×768 (shortest side over 768px), which four 512px squares cover: gpt-4o bills 85 + 4×170 = 765 tokens, and gpt-5.1 bills 70 + 4×140 = 630 tokens — our arithmetic from the published rule. Note the direction: OpenAI’s newer patch regime bills roughly twice the tokens of its older tile regime for this image. A model upgrade inside one vendor can move your image bill more than switching vendors would.

Anthropic’s vision documentation publishes the cleanest single formula in this set.

The formula is constant; what changed in 2026 is the resolution ceiling it operates under. The standard tier — all models before Claude 4.7 — downsizes any image whose long edge exceeds 1,568px and caps out at 1,568 visual tokens. The high-resolution tier — Claude 4.7 and later — raises the long-edge limit to 2,576px and the cap to 4,784 visual tokens. Per the same docs, “High-resolution support is automatic on the listed models and requires no beta header or client-side opt-in,” and a high-resolution image can use “up to roughly three times more visual tokens than the same image on a standard-tier model.” Read that as a billing event: upgrade models with no code change, and large-image workloads can cost up to roughly 3× more input tokens.

Anthropic also publishes its own dollar arithmetic, which we cite rather than restate as ours: at Claude Haiku 4.5’s $1 per million input tokens on the standard tier, a 1000×1000 image costs about $1.30 per thousand images; at Claude Opus 5’s $5 per million on the high-resolution tier, the same image costs about $6.48 per thousand, and a 4K image about $23.92 per thousand. For our 1024×1024 test image, the formula yields ⌈1024/28⌉² = 37×37 = 1,369 visual tokens on both tiers — about $0.0068 per image at Opus 5’s rate, our arithmetic from Anthropic’s published formula and published price.

Google’s image understanding docs publish a tile rule with a twist: images with both dimensions at or under 384px cost a flat 258 tokens, and larger images are cut into 768×768px tiles that each also cost 258 tokens. The tiling uses a crop unit of floor(min(width, height) / 1.5) — the docs’ own worked example runs a 960×540 image to a 360px crop unit and 3×2 = 6 tiles. A media_resolution parameter “determines the maximum number of tokens allocated per input image or video frame” — detail traded for tokens, vendor-documented.

Video is where Gemini stands alone in this set: the video understanding docs publish an actual per-second meter. Default sampling is 1 frame per second; at default media resolution each frame costs 258 tokens and audio adds 32 tokens per second (≈290 per second of video by component sum — the docs round to ≈300); at low media resolution each frame costs 66 tokens plus the same 32 for audio.

On price, Gemini’s structure is worth naming precisely: the conversion differs per modality (the formulas above), but the resulting tokens bill at one uniform rate. As of August 26, 2026, Gemini 3.7/3.6 Flash standard input is $0.75 per million tokens through December 31, 2026, with a published rise to $1.50 per million on January 1, 2027. Our 1024×1024 test image works out to a 682px crop unit, 2×2 = 4 tiles, 1,032 tokens — about $0.00077 at the standard rate, our arithmetic from Google’s published rule and published price. That published price step-up also means every image and video figure on this page priced in Gemini dollars is scheduled to double in about four months, with no change to the token math.

Alibaba’s Model Studio vision docs publish Qwen’s conversion outright: Image Tokens = h_bar × w_bar / token_pixels + 2, where the dimensions are the image’s size after Qwen’s internal scale-down and token_pixels is the pixel area per visual token — 32×32 pixels on the qwen3.x families and Qwen3-VL, 28×28 on Qwen2.5-VL and QVQ. A 16,384-token-per-image ceiling applies, with a vl_high_resolution_images switch and per-family max_pixels defaults governing how large an image stays before preprocessing shrinks it. Our test image needs no downscale: 1024×1024/1,024 + 2 = 1,026 tokens.

What makes Qwen singular in this set is video. The docs describe an fps parameter — frames extracted every 1/fps seconds — and run those sampled frames through the same published image formula. That makes Qwen the one vendor here whose video input accounting is fully derivable from its own image math, rather than requiring a separately published video rate. (We deliberately publish no dollar figure for Qwen here: the per-million pricing we found is corroborated only by third-party trackers, not by a direct Alibaba pricing-page quote in this pass, so per the rules of this reference it stays out.) For where the hosted Qwen API line sits against today’s open-weights release, see our Qwen3.8-Flash open-versus-hosted split post.

DeepSeek takes the opposite documentation strategy: no formula, a hard ceiling. Its vision guide for deepseek-v4-flash-vision-exp states: “there is an upper bound of 384 tokens per image: for example, a 2000×2000 image and a 5000×5000 image consume the same number of tokens after resizing.” Small images scale up toward roughly 384×384px, large ones scale down toward roughly 800×800px before the cap applies — so our 1024×1024 test image, above that threshold, bills the flat 384. This is the one case in this reference where more pixels provably buy zero extra billed tokens once past a threshold. The model, its peak/off-peak pricing clock, and the launch context are covered in our DeepSeek V4 Flash Vision launch reference — the single-vendor instance of exactly the problem this page treats class-wide.

A detail most cost models miss: when an open-weight vision model is served through a gateway, the gateway’s image accounting applies — not the model author’s. Two gateways document theirs.

Together.ai publishes its own formula for the vision models it serves: “Each image breaks into a tile grid (capped at 2×2 of 560-pixel tiles)” at 1,601 tokens per tile — image_tokens = min(2, max(width//560, 1)) × min(2, max(height//560, 1)) × 1601, capping at 6,404 tokens per image. Run the arithmetic and the cap binds early: any image measuring 1,120px or more on both sides — a 4K screenshot included — bills the identical 6,404-token maximum. Our 1024×1024 test image lands in a single tile: 1,601 tokens, the most expensive published conversion in this reference for that image.

Fireworks.ai maintains a dedicated FAQ page titled “How many tokens per image?” and answers it with an empirical table — but only for Qwen2.5-VL. For other vision families it hosts, Fireworks states the count “varies by model and resolution” and recommends running the model’s own tokenizer. That is a notably honest posture: publish what you measured, name what you did not.

Three vendors in this set sell multimodal input at a per-token price while publishing no way to compute how many tokens an image becomes. Naming them precisely — including exactly what was and was not checkable — is the most useful thing this reference does.

Mistral is the strangest case: a locatability failure rather than a documented absence. Mistral’s own vision docs carry an FAQ entry with the literal heading “How many tokens correspond to an image and/or what is the maximum resolution?” — and on two independent automated fetch attempts on August 26, 2026 (a plain fetch and a scrape with a JavaScript wait), the question heading rendered while the answer body did not. The same page does publish other limits precisely: up to eight images per request and PNG/JPG/JPEG/GIF/WEBP support. A “500 to 2,000 tokens depending on resolution” range circulates across third-party pricing sites for Mistral’s vision models, but we could not trace it to any quotable sentence on Mistral’s own docs — it is excluded from every table here and should be treated as unverified. To be clear about what this is not: we are not claiming Mistral hides its conversion deliberately, only that the answer was not retrievable by automated fetch on this date.

xAI publishes no conversion at all. The models reference states only size constraints — “Maximum image size: 20MiB,” “Maximum number of images: No limit” — with no tile size, patch size, or per-resolution token table anywhere on the fetched page. Secondary coverage describes Grok image input as billed at the model’s standard per-token input rate with no separate per-image fee, but we did not confirm that against a vendor pricing page on this pass, so no dollar figure for Grok appears anywhere on this page. The verified finding is the absence: there is no published way to know what an image costs on Grok before sending it.

Z.ai’s GLM-5.3-Flash — revealed today as the model behind the ox-alpha stealth listing; our reveal-day post has the full story — documents the request format and nothing more. Its API guide shows how to pass an image (“Add a content block with type: image_url…”) with no formula, tile size, or per-image token count anywhere in the guide. On the OpenRouter listing as of August 26, vision is folded into one unified per-token price regardless of modality: $0.075 per million input tokens promotional through September 9, 2026, and $0.15 per million list price after — a price you can quote, on a conversion you cannot.

One 1024×1024 screenshot, run through every accounting regime that publishes one. Every derived count is recomputed from the vendor’s own stated rule — the basis column says whose arithmetic each number is. Where no conversion is published, the cell says so; nothing in this table is estimated.

The trend this table interprets is a divergence, not a convergence. Text token billing slowly standardized around comparable BPE-family tokenizers; image billing is moving the other way — OpenAI just migrated its own line from tiles to patches, Anthropic added a second resolution tier this year, and the newest multimodal launches (GLM-5.3-Flash today among them) ship with no conversion documentation at all. The unit of purchase is getting less comparable across vendors over time, not more — which makes per-vendor unit references like this one, and the discipline of reading a pricing page correctly, more load-bearing every quarter.

Video input is images at scale plus audio, and the documentation picture is starker than for images: one vendor publishes a per-second meter, one vendor’s video cost is derivable from its image formula, and everyone else in this set publishes no separate video input rate we could locate. Again — this table is about feeding video in for understanding; generating video out is priced in the output-side companion reference.

Two things jump out of the normalization. First, at Gemini’s published $0.75-per-million standard rate (through December 31, 2026), a minute of default-resolution video costs about $0.013 of input tokens, and a minute at low resolution about $0.0044 — our arithmetic from Google’s published components. Second, the Qwen example row shows why frame-sampled billing punishes resolution: a minute of 1fps 1024×1024 frames runs roughly 3.5× Gemini’s default-resolution token count for the same wall-clock minute, because each Qwen frame bills like a full image while Gemini’s per-frame rate is a flat 258. The lesson generalizes: for video, the sampling and per-frame rule dominate the bill far more than the per-token price does.

One capability-side note to keep the frame honest: none of this says which model reads images best — token cost and vision quality are independent axes, and the capability side has its own reference in our multimodal benchmarks roundup. For teams running image- or video-heavy AI workloads in production, this is exactly the class of unit-economics audit our AI transformation engagements start with: measure the real billed tokens per workload unit on your own traffic, then route by meter, not by headline rate.