Cost per token vision model math looks simple until you actually run it: OpenAI, Anthropic, and Google all charge the same per-token rate for an image as they do for text on a given model. There's no image surcharge line item on any of their pricing pages. What changes is the token count feeding into that rate, and it changes by an order of magnitude depending on which provider's encoder touches the file. The same JPEG can become 87 tokens on one provider and 6,636 on another, before the model has generated a single word of output, which means the real lever in vision-model cost isn't the price list, it's the tokenization formula sitting in front of it.
TL;DR: What Cost Per Token Vision Model Math Actually Looks Like
- Rate: GPT, Claude, and Gemini all bill image tokens at the same per-million-token input rate as text tokens on a given model, so there's no separate image surcharge to shop for.
- Three formulas, one image: patch-based, area-based, and tile-based tokenization schemes coexist across providers, which is how the same JPEG lands anywhere from 87 to 6,636 tokens.
- Self-hosted VLMs turn this into a dial: Qwen2.5-VL's dynamic-resolution encoder can tokenize the same image at anywhere from 4 to 16,384 tokens, depending on how its resolution parameters are set.
- Spheron's H100 on-demand rate is $2.65/hr as of 24 Sep 2026, the fixed hourly number self-hosting math divides against. Compare A100 on-demand rates.
Why the Same Image Produces Wildly Different Token Counts
An image isn't billed as "one image." Every provider first runs it through a vision encoder that converts pixels into a sequence of tokens, and it's that sequence length, not any per-image fee, that determines what the request costs. Get the token count wrong in your head and every cost estimate downstream is wrong before you've touched a price list.
How GPT, Claude, and Gemini Each Tokenize an Image (Three Different Formulas)
The three major API providers don't share a tokenization method. Roboflow's engineering comparison of GPT, Claude, and Gemini found each lab settles on a different mechanical answer to "how many tokens is this image": OpenAI's models generally work from fixed image patches, Google's from image tiles, and Anthropic's from total pixel area. Anthropic is the most explicit of the three about the area-based approach: its own vision documentation shows cost scaling with pixel count rather than a flat per-image charge, illustrated with a 1000x1000 image costing roughly $1.30 per thousand images on Haiku 4.5's $1-per-million-token standard tier, and roughly $6.48 per thousand images on Opus 5's $5-per-million-token high-resolution tier, a gap that tracks the price-per-token difference between the two tiers rather than a change in how the image itself tokenizes. A 4K image on that same Opus 5 tier runs about $23.92 per thousand images, per Anthropic's own worked example.
The result of three different formulas measured against the same inputs: one cross-provider test found a 1024x1024 image produced roughly 765 tokens on a GPT-5-family model, 1,032 on Gemini, and 1,399 on Claude, what the source calls "nearly a 1.8x difference" for the identical input. None of that spread comes from a different per-token price. It comes entirely from how each provider counts.
A Real Example: One JPEG, 87 to 6,636 Tokens Depending on the Provider
Roboflow's engineering team ran the same files across GPT, Claude, and Gemini and found the spread gets more extreme as resolution rises. A batch job processing 100,000 images a month doesn't have one cost per image, it has a cost per image per provider, and switching providers without checking the encoder can move your input-token bill by multiples with the exact same source images and the exact same output quality target.
Self-Hosted VLMs Tokenize Images Differently Too (Dynamic-Resolution Encoders)
Open-weight vision-language models add a fourth wrinkle: some let you set the formula yourself. Qwen2.5-VL uses a dynamic-resolution vision encoder built from 14-pixel-square patches. Hugging Face's documentation of the underlying processor walks through an example where setting min_pixels and max_pixels to 256×28×28 and 1024×28×28 pixels "ensures each image gets encoded using a number between 256-1024 tokens," and explains that "the 28 comes from the fact that the model uses a patch size of 14 and a temporal patch size of 2 (14 x 2 = 28)." Left at its defaults, the swing is far wider: the Qwen2.5-VL-7B-Instruct model card states plainly that "the default range for the number of visual tokens per image in the model is 4-16384," a more than 4,000x spread between the low and high end of the same unconfigured encoder.
That's not a limitation, it's a lever the closed APIs don't give you. On GPT, Claude, or Gemini, you accept whatever token count their encoder assigns to your image at your chosen resolution. On a self-hosted Qwen2.5-VL deployment, you set the ceiling, which means you can trade image detail for token cost directly, per request type, instead of resizing images and hoping the provider's formula responds the way you expect.
The Real $/Image Math: Cost Per Token Vision Model, Self-Hosted vs API
What the Big Three API Providers Actually Charge Per Image
None of the three major labs publish a flat "$X per image" rate, because none of them charge one. Each resolves to a token count first, then applies that model's standard per-token input price.
Anthropic publishes the clearest worked math of the three. At Claude Haiku 4.5's standard $1-per-million-token tier, a 1000x1000 image costs roughly $1.30 per thousand images processed. Move to Claude Opus 5's high-resolution $5-per-million-token tier and the same-size image costs roughly $6.48 per thousand images, and a 4K image on that tier runs roughly $23.92 per thousand images, all figures Anthropic states directly in its own vision documentation.
Google's Gemini API pricing page lists $0.30 per million tokens (covering text, image, and video input alike) on Gemini 2.5 Flash, and $1.25 to $2.50 per million tokens on Gemini 2.5 Pro depending on prompt length, with image tokens billed at those same input rates once the encoder has converted the file. Since a typical image runs somewhere in the low thousands of tokens, the per-image cost on Flash lands well under a tenth of a cent for most resolutions, and rises with both resolution and the Pro tier's higher per-token rate.
OpenAI doesn't publish a separate per-image rate either. Image tokens bill at the same input-token rate as text on whichever model handles the request, per Roboflow's provider comparison, so the number that actually determines cost is the token count your specific image and resolution produce, not a line item you can look up in isolation. Check the current per-token input rate on the model you're calling before estimating a per-image cost, since none of these three providers hold rates fixed for long.
Self-Hosting Cost Per Image on Rented GPUs
The self-hosting version of this math uses the same cost-per-million-token formula this blog covers in detail: CPM = (GPU cluster $/hour) ÷ (measured tokens/sec × 3,600 ÷ 1,000,000). Image tokens don't change the formula, they change what's flowing through it. An image's tokens land in the prompt at prefill time, the same slot a long text context occupies, so a heavier image (more tokens) behaves exactly like a longer prompt: it eats more compute per request and takes up more KV cache, which lowers how many concurrent requests the same GPU can hold. That mechanism is the same one behind Llama 3 70B's KV cache growing from 0.313GB at 1,000 tokens of context to 39.06GB at 128,000 tokens, a 125x jump documented in this blog's cost-per-token formula post. An image sized at the top of Qwen2.5-VL's 16,384-token ceiling consumes prefill compute and cache space the same way a 16,384-token wall of text would.
That's why the self-hosting side of this math can't be reduced to a single published number the way an API rate card can. It depends on your own measured tokens-per-second, at your own batch size, on your own hardware, exactly the argument made in this blog's cross-GPU, cross-model benchmark methodology: plug in what you actually measure, not a vendor's peak-batch figure. What you can fix ahead of time is the GPU's hourly rate. Spheron's on-demand rate for an H100 SXM5 is $2.65/hr as of 24 Sep 2026, and an A100 80GB on-demand is $1.48/hr, both billed per minute with no minimum contract, so the fixed half of the CPM formula is known before you run a single benchmark; the throughput half still has to come from your own vLLM or SGLang deployment.
Worked example, so the formula isn't left abstract: say your own vLLM benchmark on a single H100 measures 2,800 tokens/sec sustained at batch size 16 for an image-heavy Qwen2.5-VL-7B workload (a number you'd pull from vllm bench serve against your own prompts, not a vendor's spec sheet). At an illustrative $2.50/hour GPU rate, that's 2,800 × 3,600 = 10,080,000 tokens/hour, so CPM works out to $2.50 ÷ 10.08, or roughly $0.25 per million tokens processed, image tokens and text tokens alike. Swap that placeholder rate for Spheron's live on-demand figure above and your own measured throughput in place of 2,800, and the same formula gives you a real number instead of someone else's benchmark.
Where API Pricing Beats Self-Hosting, and Where It Doesn't
The API side wins on low or spiky image volume, the same pattern this blog has already documented comparing Groq's per-token API pricing against renting the underlying hardware: a GPU sitting mostly idle between requests is a fixed cost you're paying regardless of throughput, while a per-token API scales its bill down to zero when nobody's calling it.
Self-hosting starts winning once sustained image volume is high enough that the fixed hourly GPU rate, spread across a large and steady request count, undercuts the API's per-image total, the same crossover point already worked out for Claude's own API-versus-self-hosted comparison on text models. Vision workloads hit that crossover at a different volume than text does, because image tokens are heavier per request, which raises the API side of the comparison faster than it raises the self-hosted side (where the fixed GPU rate doesn't care how many tokens a single request contains, only how much aggregate throughput the fleet sustains).
Spheron's part in that math is the GPU rental, not a managed vision-inference endpoint. There's no vision-specific product here: it's the same on-demand and spot capacity, from RTX 4090 through B200, that any self-hosted workload runs on, with per-minute billing and no long-term commitment so you can size a deployment against your own measured image volume before committing to reserved capacity. What it doesn't do is run vLLM or SGLang for you; deploying and operating the serving stack for a self-hosted VLM is still your job, unlike a fully managed per-image API call to OpenAI, Anthropic, or Google. Below the breakeven volume, or with genuinely spiky traffic, a managed API stays cheaper regardless of the GPU rate underneath it, the same caveat that applies to every self-hosting-versus-API comparison this blog has run for text models.
How to Cut Image Token Cost Without Losing Accuracy
Every lever here reduces token count rather than asking a provider for a discount, because token count is the only variable actually moving the bill.
Resize and Cap Resolution Before You Send the Request
Most vision tasks don't need the original file's full resolution to answer correctly. A 4032x3024 phone photo carries more pixels than a document-reading or object-detection task typically needs, and every one of those tokenization formulas produces more tokens at higher resolution. Downscaling to the smallest resolution that still holds accuracy on your own eval set is the single cheapest lever available, and it works identically across GPT, Claude, and Gemini since all three formulas scale with input size in some form.
Use Low-Detail or Flat-Rate Modes When Precision Isn't the Point
Where a provider offers a lower-fidelity processing mode for tasks that don't need fine-grained visual reasoning, that mode exists specifically to trade token count for cost. A thumbnail classification task or a rough scene description doesn't need the same token budget as a task reading small text out of a document photo. Match the mode to the task rather than defaulting every request to the highest-fidelity option.
Cap Max Resolution on Self-Hosted Encoders
On a self-hosted deployment with a configurable encoder, the lever is explicit. Qwen2.5-VL's max_pixels parameter caps how many patches, and therefore tokens, any single image can generate, and lowering it from the 16,384 x 28 x 28 pixel default directly lowers prefill compute and KV cache pressure per request, which raises how many concurrent requests the same GPU can hold under the CPM formula covered above. Test the lowest max_pixels ceiling that still clears your accuracy bar rather than leaving it at the model's default maximum, the same way you'd tune context length on a text-only deployment.
Pricing fluctuates based on GPU availability. Spheron rates above are live as of 24 Sep 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing → for live rates.
Whether the right move is resizing your images, switching providers, or moving a high-volume vision workload onto rented GPUs comes down to the token math this post walks through, run against your own request volume.
Once your image volume is high enough to make the self-hosting math worth running, an on-demand H100 gives you the fixed hourly rate half of that formula without a contract to sign first.
Frequently Asked Questions
Not because image tokens are priced higher. OpenAI, Anthropic, and Google all bill image tokens at the same per-million-token input rate as text tokens on a given model, with no separate image surcharge. The cost premium comes entirely from volume: a single image can consume hundreds to thousands of tokens where a text prompt carrying comparable information would use far fewer. A 1024x1024 image can tokenize to anywhere from roughly 765 to 1,399 tokens depending on the provider, and none of that volume shows up until you send the request.
It depends heavily on both the provider and the image's resolution. At the smaller 1024x1024 size, a separate test measured about 765 tokens for a GPT-5-family model, 1,032 for Gemini, and 1,399 for Claude, near a 1.8x spread. There is no single answer independent of both the image and the model.
It depends on volume and how much control you need over the token-to-accuracy tradeoff. API pricing wins at low, spiky volume because there's no idle GPU to pay for between requests. Self-hosting wins once sustained image volume is high enough that a fixed hourly GPU rate, divided across more images, beats the per-image API total. Spheron's H100 on-demand rate is $2.65/hr as of 24 Sep 2026, which is the fixed cost that self-hosting math has to divide by your own measured throughput, not a vendor benchmark.
Resize and downscale before you send the request rather than letting the API's encoder process a full-resolution original; most task categories don't need 4K input to answer correctly. Use a provider's low-detail or flat-rate mode when the task doesn't need fine-grained visual reasoning. On self-hosted encoders with a configurable resolution ceiling, like Qwen2.5-VL's max_pixels parameter, cap the ceiling to the lowest value that still holds accuracy on your own eval set instead of leaving it at the default maximum.
