Vision tokens and cost

The first product instinct is "just attach the image." The first engineering question is "how many tokens is this image on this model after this resize?" Providers do not bill "per image" in the abstract. They bill image tokens after resizing. Vision features that skip that question ship a delightful demo and a terrifying invoice.

The big idea

Claude-style vision treats an image as a grid of patches, documented as 28×28-pixel patches. After the API downscales oversized images to a model-specific max long edge:

visual_tokens ≈ ceil(width / 28) × ceil(height / 28)

A ~1000×1000 image lands on the order of ~1.3k visual tokens before text. Check the arithmetic: ceil(1000 / 28) = 36, and 36 × 36 = 1,296. At about $1 / million input tokens, a thousand such images cost roughly a dollar of image input alone. At higher-priced tiers the same volume is several dollars.

OpenAI-style high detail vision historically resized to fit a box, scaled the short side, then charged a base token count plus a per-tile cost, commonly described as 512×512 tiles. Low detail collapses to a cheap fixed token count. That is fine for "what animal is this?" and poor for dense screenshots.

Exact formulas change by model revision. Use the provider's calculator or token-count API for production budgets. Remember the orders of magnitude:

Walking through a resize

Too low — unreadable fonts, merged table cells, lost icons. Too high — token blowups, slower prefill, and diminishing returns after the model's cap downscales you anyway. Crops — for "read this error toast," crop the toast. Pointing the model at the region beats sending a 4K desktop wallpaper.

Downsample before upload when the task does not need pixel-peeping. You cut tokens, latency and sometimes improve accuracy by removing noise, until small text becomes unreadable. That is the trade-off you must eval.

Put instructions that refer to the image after, or clearly linked to, the image block ("In the screenshot above, …"), depending on API conventions. Keep the question specific.

Prompting that helps:

• Say what to look at. "Read the red banner at the top" beats "what's wrong?"
• Ask for transcription before interpretation when text in the image matters.
• Disallow invention. "If the total is unreadable, set total_cents to null."
• Limit the job. One image, one schema, one decision.

You see one receipt image.
1) Transcribe vendor, date, total, tax exactly as printed.
2) Do not convert currencies.
3) If multiple totals appear, prefer the final amount due near the bottom.
4) status=incomplete if vendor, date or total cannot be read confidently.

For UI screenshots, few-shot examples that include images help more than adjectives about being careful, when the API supports image examples.

Common mistakes

• Budgeting by number of uploads. A 12 MP phone photo is not one cheap unit.
• Sending the whole desktop for one toast. Crop first.
• Low-detail mode on a dense screenshot. You paid less and cannot read the labels.

Check yourself

• A 1000×1000 image with 28×28 patches: about how many visual tokens? ceil(1000/28) = 36, and 36 × 36 = 1,296, about 1.3k.
• When is low-detail vision the wrong setting? When you need to read small UI text or a full-page screenshot.

Key takeaways

• Images become tokens after a resize. Resolution policy is a cost and quality lever.
• Downsample and crop on purpose. Tiny text is the limit.
• Transcribe then reason. Point at the region the model must read.

Further learning

Next, see how PDFs and tables use those tokens in document understanding.