Image token calculation across OpenAI, Claude, and Gemini

The same screenshot costs 2,448 tokens on one model and 1,120 on another. The reason is not image quality. The three big providers now use three unrelated rules, and one of them ignores your image's dimensions completely.

Why image token counts differ

Every vision pipeline transforms the image before the model sees it. What differs is what each provider charges for afterwards:

• OpenAI charges for patches. The image is cut into 32-pixel squares and the count is capped.
• Anthropic charges for patches too, but with 28-pixel squares and two different caps, split by model generation.
• Google charges a flat budget per image. Dimensions do not enter the calculation at all on Gemini 3.

Compressed file size never appears in any of the three. A 200 KB JPEG and a 2 MB PNG of the same dimensions cost the same.

One image, five models

A 1920 × 1080 screenshot—the most common thing anyone actually sends—priced at each model's standard input rate:

GPT-6 Astra costs 29 times more per image than Gemini 3.8 Flash. Two of these models are from the same vendor and differ by a factor of 1.73 on token count alone.

OpenAI: 32-pixel patches with a cap

The current rule has three steps. Count raw patches as ceil(width / 32) × ceil(height / 32). If that is above 2,500, shrink the image to fit the budget and recount. Multiply the patch count by 1.2 and round up.

OpenAI publishes two worked examples, and both reproduce exactly: 1024 × 1024 is 1,024 patches and 1,229 tokens; 2048 × 2048 shrinks to 1600 × 1600, lands on the 2,500-patch cap, and costs 3,000 tokens. The cap is the important part. Past about 1.6 megapixels, a bigger image costs nothing more, so sending a 4K screenshot buys no extra detail and no extra cost.

One practical gap: OpenAI's patch table lists GPT-6 Astra and the GPT-5.6 family, but not GPT-6 Sol, GPT-6.1 Sol, or GPT-6 Luna. Those three accept images with no published budget. This site counts them with the Astra rule and labels the result an estimate, rather than presenting an unsourced number as a fact.

The older tile rule—85 tokens plus 170 per 512-pixel tile, or a flat 85 for low detail—still applies to the GPT-4o and GPT-5 generations. If you copied that formula into your own code two years ago, it is now wrong for every current model.

Claude: 28-pixel patches in two tiers

Anthropic counts ceil(width / 28) × ceil(height / 28) after resizing the image to fit two limits at once: a maximum edge and a maximum token count. Claude 4.7 and later get the larger limits—2,576 pixels and 4,784 tokens—while Claude 4.6 and earlier are held to 1,568 of each.

The old approximation width × height ÷ 750 still circulates widely. It is close for small images and wrong for large ones, because it has no cap in it. For the 1920 × 1080 screenshot above it predicts 2,765 tokens: about 3 percent off for Claude Sonnet 5.5, and 77 percent too high for Claude Haiku 4.5.

The tier split has a real consequence for migration. Moving a screenshot-heavy workload from Haiku 4.5 to Sonnet 5.5 raises the image token count by three quarters, on top of the roughly 30 percent more text tokens the newer Claude tokenizer produces. Both effects point the same way, and neither shows up on a price-per-million comparison.

Gemini: a flat budget per image

Gemini 3 does not look at your dimensions. Each image spends a fixed budget: 280 tokens at media_resolution low, 560 at medium, 1,120 at high and by default, and 2,240 at ultra-high. A thumbnail and a 4K frame cost the same.

That makes Gemini the simplest of the three to budget and the easiest to over-spend on. Four images at the default setting cost 4,480 tokens whether they are icons or photographs, so lowering media_resolution to low on image-heavy pipelines cuts the visual bill by three quarters with one parameter.

Gemini 2.x is a different scheme entirely: 258 tokens when both sides are under 384 pixels, otherwise 768-pixel tiles at 258 tokens each after fitting the image into 3072 × 3072. The two generations can differ by more than 400 tokens on the same photograph, so a Gemini 2.x estimate must not be reused for Gemini 3.

A defensible comparison workflow

1. Record the exact pixel dimensions you will send, not the file size.
2. Name the exact model ID and the detail or media_resolution setting.
3. Measure locally in the image token calculator.
4. Reconcile against the usage block of one real API response.
5. Store both numbers with the model ID and the date. Do not carry a result across model families, or across generations inside one family.

The full formulas, including the published verification tables, are in the vision-token documentation. For the other non-text inputs, see audio, video, and PDF tokens.