Detail Level and the Token Cost of Looking Closely

Why an image has a price

The single idea that reframes vision work is this: an image is not a free attachment. It becomes tokens, and those tokens are billed and counted against the model's context exactly like words are. Vision-enabled models accrue charges like other chat models — a per-token rate on prompts and completions — and the pixels you send are part of the prompt.

Once you accept that, a whole family of decisions opens up. How much of the picture does the model actually need to look at? What does extra looking cost? And when does looking harder stop paying for itself? Foundry gives you one explicit dial for this, and understanding it is the difference between a demo and something you can afford to run.

The three detail settings

Inside the image content part you can set a detail value alongside the image reference. It takes one of three values.

auto is the default. The model decides between low and high based on the size of the image input. It is a reasonable starting point and a poor place to stay, because it makes your cost profile depend on whatever your users happen to upload.

low skips high-resolution processing entirely. The model works from a downscaled 512x512 version of the picture. Responses come back faster and consume fewer input tokens. For questions like "is there a person in this frame?", "is this a receipt or a business card?", or "which of these three room types is this?", the downscaled view is plainly enough.

high turns on high-resolution mode. The model first takes in the low-resolution image to get the overall scene, then works through detailed 512x512 segments cut from the input. Each of those segments carries its own token cost — Microsoft states plainly that each segment uses double the token budget in exchange for a more detailed interpretation. That is the whole trade in one sentence: finer reading, multiplied spend, and more latency.

What low resolution actually costs you in accuracy

The documentation is candid that the saving is not free. Low-resolution analysis allows faster responses and uses fewer input tokens for certain use cases, but it can degrade the accuracy of object and text recognition within the image. Both halves of that sentence matter.

Text is the first casualty. Small print — a serial number on a label, a line item on an invoice, a handwritten note in a margin — depends on pixels that the 512x512 downscale simply throws away. If your task is reading, start at high and only step down if you can demonstrate that low still reads correctly on your own sample.

Small or distant objects are the second. A defect on a component, a crack in a weld, one sign in a crowded street scene: these are exactly the cases where the segmented high-resolution pass earns its cost.

The useful mental model is triage. Run a cheap low-detail pass to classify or filter, and escalate only the images that matter to a high-detail pass. That two-stage pattern is far more economical than paying high-resolution rates on every frame, and it is a pattern you can describe in an interview or an exam answer without any code.

The other budget: output length

Detail level governs what goes in. A separate limit governs what comes out, and confusing the two is a classic source of "the model got worse" reports. You set a maximum completion length on the request — and for the o-series reasoning models you set it with the completion-specific parameter rather than the older one. If you omit it, the returned output can simply be cut off.

This is why reading finish_reason is not optional. A value of stop means you got the whole answer. A value of length means the output was truncated because of your maximum-token setting or the model's own limit — the model did the work, you clipped the result. A value of content_filter means content was omitted because a filter flagged it. Three very different situations that all look like "a short, unsatisfying answer" if you only read the text.

How to reason about cost before you write code

A rough cost estimate for a vision call has three components: the tokens for your instruction text, the tokens for the image at whatever detail level you chose, and the tokens for the answer you asked for. You control all three. Shorter system messages, a lower detail setting, and a tighter output specification — "answer in one line, no explanation" — each reduce the bill, and the last one often improves the answer as well.

Common mistakes

Leaving detail on auto and then being startled by the bill when users start uploading high-resolution photos.

Choosing low for an OCR-flavoured task and blaming the model for misreading digits it was never shown.

Reading a truncated answer as a comprehension failure instead of checking finish_reason and raising the output limit.

And assuming that resizing an image before upload is only about the 20 MB ceiling. It is also, and mostly, about what you are willing to pay for the model to look.