OpenAI Vision API

Images are an input type, not an endpoint

OpenAI has no separate vision endpoint. An image goes into the same call you already make, answered by the same model that answers your text requests.

That is worth saying because "the Vision API" sounds like a product you adopt. It is a content type on a request you are already sending, and most of what you need to know about it is arithmetic.

Multimodal AI covers the ways media reaches a request, the detail parameter and its naming trap, and what vision models read badly. This page is the provider specifics: what an image costs on OpenAI, and which limit you hit first.

Cost is a patch count against a budget

OpenAI bills images by patch rather than by pixel, and each model caps how many patches it will spend. An image larger than the cap is resized down to fit before anything is counted.

On gpt-6-astra at detail: high, a 1024×1024 image costs 1,229 tokens. A 2048×2048 image costs 3,000, after resizing to fit a 2,500-patch budget.

Read those two figures together and the shape of the pricing appears. Four times the area produces under two and a half times the cost, because the budget intervenes. Above the cap, sending a bigger image stops buying you anything: you pay the ceiling and the model sees a downscaled copy either way.

This is the opposite of the trap on Anthropic, where image understanding shows cost climbing with area until a resolution tier caps it, and a model upgrade tripling the bill. On OpenAI the budget is the thing to know; on Claude it is the tier.

Find your own numbers before you size anything

Per-image figures vary by model, and the multiplier is model-specific. A cost computed for one model is wrong for the next one you try.

So measure rather than infer. Send a representative image to the model you call, read the usage figures off the response, and multiply by your expected volume. A feature processing a few thousand images a day puts a real line on the bill rather than a rounding error, and cost and latency monitoring argues for recording those figures per request anyway. An image-heavy feature is exactly where a token total computed from text alone comes out wrong.

The published limits, and the one that binds

• Up to 1,500 images per request
• Maximum 30,000 patches per image
• Maximum payload 512 MB per request

None of these is the limit you will meet. A request carrying even fifty images runs into a latency budget or a cost ceiling long before it runs into 1,500, and 512 MB of payload is slow to upload before it is anything else.

Treat the published numbers as the boundary of what the API accepts rather than as headroom to plan against. The real ceiling is whatever your users will wait for.

Send a file ID when the image recurs

Three sources work: a URL, a base64 data URL, or a file ID from the Files API. The choice matters in one situation.

In a conversation, every turn resends the history. A base64 image is therefore re-uploaded on each turn for the rest of the exchange, and the payload grows with the conversation. A file ID is a short string that stays short.

So reach for the Files API whenever an image appears in more than one request, and use base64 for one-shot calls where the upload happens once. Supported formats are PNG, JPEG, WebP and non-animated GIF.

Porting to or from another provider

The common path moves cleanly. A message carrying an image block and a question works on every major provider.

What does not move is detail. Anthropic has no counterpart, because resolution there is a property of the model rather than a request parameter. OpenAI-compatible APIs covers why a field like this one is the kind that a compatible endpoint drops without telling you: the request still succeeds, and the cost you budgeted for is not the cost you get.

Further reading

• OpenAI, Images and vision: the sources, the token examples, and the published limits.
• Multimodal AI: the detail parameter, and what vision models read badly.
• Image understanding: the same cost question on Anthropic, where the mechanism differs.
• DALL·E API: the other direction, images out.