Explain how vision-language APIs price image inputs, what determines the per-image token count, and why a hi-res photo can outweigh several pages of text on the input-token bill.
Free · 2 AI evals / day
When you send an image to a vision-language model, the model does not look at raw pixels. There is a small image encoder in front of the language model that turns the image into a sequence of tokens, just like a tokenizer turns text into tokens. The language model then reads those image tokens the same way it reads word tokens.
The encoder tiles the image. It splits the picture into fixed-size squares, often 512 by 512 pixels, and produces a fixed number of tokens per square. Each square becomes something like 100 to 300 tokens depending on the model. A small picture is one or two squares; a high-resolution photo is many squares; a 4K screenshot can be dozens of squares.
The bill follows directly from this. Every image token counts as an ordinary input token at the standard per-token rate. So a single high-resolution image often costs 1000 to 3000 tokens, more than a multi-paragraph prompt. People sending a 4K photo and a one-line question are paying mostly for the image.
Providers give you a knob. Most APIs expose a detail parameter, sometimes called resolution or fidelity, that forces the image to be processed at low resolution. In low-detail mode the encoder uses one shrunken tile and emits a few hundred tokens regardless of the source size. That is a big cost cut when you only need the rough scene. For fine-grained tasks like reading text in an image, you need high detail and the higher bill.
Image input to a vision-language model is not free and not flat-priced. The model has an image encoder, typically a CLIP-style or SigLIP-style vision transformer, that processes the image as a sequence of patches and emits an embedding sequence the language model attends to. That sequence is what the API calls image tokens, and every image token is billed at the model's standard input rate.
The encoder tiles the image at a fixed resolution per tile, typically 512x512 pixels. A small image fits in one tile. A larger image is split into a grid of tiles, and the encoder also typically adds one low-resolution overview tile so the model sees the whole image at once before attending to the high-resolution detail. Each tile produces a fixed number of tokens, often somewhere between 100 and 300 depending on the model's patch size and any compression in the projector. A 1024x1024 image therefore produces about 4 high-detail tiles plus 1 overview, landing around 1000-1500 tokens. A 4K image produces dozens of tiles and can exceed 5000 tokens. Comparable text would need to be 7500+ words.
This matters because input pricing is structured around tokens, not images. A short user question with a 4K photo can cost more than the same model reading the entire text of a long article. Real applications discover this the hard way when they ship a feature that uploads phone-camera photos at native resolution and watch the API bill jump 5-10x.
The mitigation lever is the detail or resolution parameter. OpenAI's vision API exposes detail set to low, high, or auto; Anthropic's API distinguishes hi-res from a single small tile internally. In low-detail mode the encoder uses a single down-scaled tile (typically 85 tokens for OpenAI), an order of magnitude smaller than the high-detail path. The right discipline is to choose detail per task: low detail for scene description or rough classification, high detail for OCR, chart reading, or any task where small visual structures carry
Quick reference
TL;DR
Vision encoders tile each image into fixed patches and emit hundreds of tokens per tile, all billed at the standard input rate.
Picture a postcard rack at a store. Text prompts are like letters, the cashier counts each word. Images are not letters, so the store cuts each photo into small squares and counts the squares. A small photo is one or two squares; a giant printed poster is many dozens. You pay per square just like you pay per word. A poster can easily cost more than a long letter because it has so many squares. The store offers a thumbnail option: print a tiny version that is only one square, much cheaper, but you lose detail. The trick is matching the photo size to how much detail the cashier actually needs to do their job.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Task is OCR, chart reading, or anything depending on small visual structure Low-detail mode discards the resolution that the task depends on, the answer quality collapses, and you pay for retries on top of the cheaper per-image cost.
Diagram or document analysis where layout precision matters Aggressive resizing destroys spatial relationships and tabular structure that the model needs to ground its answer in.
Single hero image in a long text-heavy chat The image is the focal point of the request; under-resolving it to save tokens makes the whole turn lower-value.
Real-time camera feed where every frame matters Some safety and tracking tasks legitimately need full-resolution frames; the cost is the price of the task, not waste, and frame sampling is the lever instead.
Quick scan · 2–4 min
Everything important, quickly.
3 min: image encoder turns the picture into a token sequence (tile-grid + overview), bill is image-tokens at standard input rate, hi-res images hit 1000-3000+ tokens, detail mode and client-side resizing are the levers.
Side-by-side
Image setup
Tiles
Approx tokens
Good for
Bad for
512x512 low detail
1 overview only
~85
scene classification, rough description
OCR, fine text, small icons
512x512 high detail
1 tile + overview
~255
small photos, simple icons
high-resolution sources downscaled and losing detail
1024x1024 high detail
4 tiles + overview
~765
typical product photos, charts
fast turnaround on bulk image jobs
2048x2048 high detail
16 tiles + overview
~2805
detailed documents, dense charts
any task where low detail suffices
4K photo high detail
32-48 tiles + overview
~5000+
rare cases needing full resolution
default uploads from phone clients
Real-world examples
Real products, models, and research that use this idea.
1OpenAI's vision pricing on GPT-5.5 uses 170 tokens per 512x512 high-detail tile plus an 85-token overview; a 1024x1024 image at high detail is 765 input tokens.
2Anthropic's Claude Opus 4.7 vision API charges per image with high-resolution and low-resolution modes; a single hi-res photo commonly lands at 1500-2500 input tokens.
3A SaaS app processing user-uploaded screenshots at native 4K resolution discovered its monthly bill tripled after adding the image feature, traced entirely to tile-count explosion.
4OCR-style features on receipts and invoices that must read fine print legitimately need high-detail mode; the cost is the price of the task, not waste.
5Video understanding pipelines like Gemini 2.5's video mode sample roughly 1 frame per second to keep frame-tokens bounded; raw 30 fps submission would multiply token cost 30x.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does aspect ratio interact with the tile grid to inflate token cost?
Sign in or go Pro to see the approach for this follow-up.
QWhy does Anthropic charge differently from OpenAI for the same image?
Sign in or go Pro to see the approach for this follow-up.
QWhen does prompt caching help with image-heavy workflows?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Assuming image inputs are free or flat-priced. Every image is decomposed into image tokens billed at the standard input rate; a hi-res photo can quietly outprice the entire surrounding text prompt.