HomeBlog › Vision token cost by provider

Same image, different bill: what a picture costs on GPT-4o vs Claude vs Gemini

Published 2026-08-08 · reference numbers, verify before budgeting

Send the exact same 1024×1024 image to GPT-4o and to Claude and you get two different token bills for two identical pixels. GPT-4o comes out to roughly 765 tokens. Claude comes out to roughly 1,400 tokens — nearly double. Nothing about the image changed. Only the formula the provider uses to turn pixels into tokens changed, and most teams pricing "GPT-4o vs Claude" never get past the text rate card to notice.

Three providers, three completely different formulas

Vision pricing depends on resolution — pixel dimensions — not file size. A heavily compressed JPEG and a crisp PNG at the same width and height cost exactly the same, because the model never sees the file, it sees decoded pixels. What differs is how each provider converts those pixels into billable tokens.

ProviderFormula1024×1024 imageThe catch
OpenAI GPT-4o (high detail)85 base + 170 per 512px tile≈765 tokenstiling means cost scales with pixel area, not linearly with size
OpenAI GPT-4o (low detail)flat 85 tokens, any size85 tokensimage is downsampled to a thumbnail first — fine text won't survive
Anthropic Claudewidth × height ÷ 750≈1,400 tokensno low-detail escape hatch — every image pays the full pixel-area price
Google Geminiflat 258 tokens up to 384×384, tiled beyond that258 + tilingcheapest for small images, but the exact tile count above 384px isn't published as cleanly as the other two

Reference formulas as published by each provider, 2026. Providers round and revise tile/pixel rules over time — report outdated price →

Look at the middle two rows. OpenAI's high-detail mode and Anthropic's only mode land on the same 1024×1024 image nearly 2× apart — 765 tokens against roughly 1,400 — because GPT-4o counts fixed-size tiles while Claude divides raw pixel area by a constant. Neither number is wrong. They're just not the same kind of number, and a team that priced a Claude migration off GPT-4o's vision line will be short by close to double once images start flowing.

Why this hides inside a "text pricing" comparison

Model pricing comparisons default to text: dollars per million input and output tokens, the numbers on the rate card. Vision gets bolted on as an afterthought, if it's modeled at all. That's backwards for a lot of real products — a document-QA app, a receipt scanner, a support tool that takes screenshots — where every request carries at least one image and the image easily outweighs the prompt around it. A 1024×1024 screenshot at 1,400 Claude tokens can be larger than the text question asking about it.

The gap compounds with volume the same way any per-request cost does. At 100,000 images a month, GPT-4o high-detail runs about 76.5M image tokens; the same corpus on Claude runs about 140M — an extra 63.5M tokens a month that never shows up if the cost model was built off text pricing alone. Compare that against text-only numbers like the ones in GPT vs Claude vs Gemini: which AI API is cheapest and a vision-heavy workload can flip the ranking entirely.

Two levers that matter more than picking a "cheaper" model

Because tiling scales with pixel area, doubling both width and height roughly quadruples the tile count and the cost — a 2048×2048 screenshot costs several times more than a 768×768 crop would, for a task that never needed the extra resolution in the first place. Downscaling to the smallest resolution that still contains the detail you need is the single biggest lever on vision cost, ahead of which provider you pick.

The second lever is detail mode, and it only exists on OpenAI: low-detail charges a flat 85 tokens regardless of image size, because the picture is downsampled to a thumbnail before the model reads it. That's fine for "what is this generally" — a receipt, a chart, a cat — and useless for reading fine print or small labels, where you need high-detail's preserved resolution. Routing images to low-detail wherever the task only needs the gist is a 5–10× cut versus defaulting every image to high-detail, which is what most integrations do without thinking about it.

What we'd actually do with this

The takeaway

Two providers can tile or divide the exact same pixels into token counts that differ by close to 2×, and that gap is invisible until an image-heavy product actually ships. The fix costs nothing: separate the vision line item from the text line item, downscale before sending, and pick detail mode on purpose instead of by default.

Methodology: formulas and reference token counts are as published by each provider's documentation, cross-checked against this site's own vision cost calculator. Providers periodically revise tile sizes and per-tile rates — treat the specific counts here as a snapshot to verify, not a permanent constant. The 100,000-image monthly comparison is an illustrative scenario built from the per-image figures above, not telemetry from a production system.