The correct answer is **the number of vision tokens the encoder and tiling produce**, which scales with resolution.
The key idea: a language model pays for tokens, not bytes. When you send an image, the vision encoder converts it into a fixed number of vision tokens, and the LLM attends over those tokens just like text. That token count is what shows up on your bill and in your latency.
The other three options are storage details that never reach the model.
- **File size in megabytes** is just how the image is stored on disk. A 5 MB and a 500 KB version of the same photo at the same resolution produce the same token count.
- Color depth and JPEG compression change how the bytes are packed, not how many tokens the encoder emits.
- Aspect ratio relative to a screen is irrelevant; the model does not know or care what screen captured it.
What actually moves the cost is resolution. A higher-resolution image, processed with tiling (AnyRes), is split into multiple tiles, each emitting its own block of tokens, plus a downscaled global view. More tiles means more tokens means more cost.
The token cost of an image is driven by **the number of vision tokens** the encoder emits. That number scales with resolution and tiling, not with anything about how the file is stored.
The reasoning starts from what the LLM actually consumes. It attends over a sequence of tokens, and a vision encoder turns an image into a fixed block of vision tokens that join that sequence. Those tokens are billed and prefilled exactly like text tokens, so they are the unit of cost. A standard encoder pass might emit a few hundred tokens for one image.
Resolution enters through tiling. High-resolution schemes like AnyRes split the image into a grid of tiles, encode each tile separately, and usually add a downscaled global view. Each tile contributes its own block of tokens, so a 3x3 tiling plus a global view costs ten encoder passes worth of tokens for a single image.
The three distractors are all about bytes, not tokens. File size, JPEG quality, and color depth change the on-disk representation. But they are decoded away before the encoder runs, so the same scene at the same resolution yields the same token count regardless. Aspect ratio relative to a capture screen has no effect at all. The mental model to carry: cost tracks resolution and tile count, because those set how many tokens the model must attend over.
Quick reference
TL;DR
An image's token cost is set by how many vision tokens the encoder emits, which scales with resolution and tiling, not by file size, compression, or aspect ratio.
Imagine you pay a reader by the number of index cards they have to read, not by how heavy the folder is. You could compress a photo into a tiny file or a huge one, but the reader still turns it into the same number of cards. What actually changes the card count is how finely you slice the picture. A quick low-detail look becomes a few cards. A high-detail look, where you cut the photo into many tiles so the reader can see the fine print, becomes many cards. So the price tracks how many tiles and how much detail you asked for, not the size of the file sitting on your disk.
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.
Estimating bandwidth or upload latency rather than model inference cost For network transfer, file size in megabytes genuinely matters; the token-count framing only applies once the image reaches the encoder.
A provider that flattens all images to a single fixed token price regardless of resolution Some APIs bill a flat per-image token block with no high-detail tiling option, so the resolution-scaling story does not apply to their pricing tier.
Pure document storage or archival pipelines with no model in the loop If nothing encodes the image into tokens, compression and color depth are the only costs that matter; there is no vision-token bill at all.
Quick scan · 2–4 min
Everything important, quickly.
Establish that the model bills in tokens not bytes, trace where file size and compression get decoded away, and explain how tiling turns resolution into a token-count multiplier that drives both cost and prefill latency.
Real-world examples
Real products, models, and research that use this idea.
1OpenAI's GPT-5.5 image pricing charges by tile: a base block plus added blocks per 512-pixel tile at high detail, so a large image costs many times a small one.
2Gemini 3.1 Pro bills images by token equivalents that climb with resolution, so a full-page document scan costs far more than a thumbnail.
3AnyRes in LLaVA-style models splits high-resolution inputs into tiles plus a global view, each tile emitting its own block of vision tokens.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy does prefill cost, not just billing, make the vision-token count the real lever?
Sign in or go Pro to see the approach for this follow-up.
QIf a user uploads a 12 MP photo, what actually determines its cost?
Sign in or go Pro to see the approach for this follow-up.
QHow would you cut the image cost of a high-volume VLM feature without losing needed accuracy?
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 a smaller file means a cheaper image. Compressing the JPEG changes bytes on disk, but the encoder still emits the same number of vision tokens.