How Many Images Fit in a Single GPT-4o Request

There is no single documented number for “images per request” that answers this the way people expect. The ceiling is set by arithmetic: images are converted to tokens by a published formula, and tokens are bounded by the context window. Do that arithmetic and you get a real answer, with the assumptions visible.

What actually limits you

Four constraints stack, and only the last one is usually the one people hit:

• Per-image constraints. OpenAI’s vision guide documents the accepted formats, the maximum file size, and the maximum dimensions for a single image. These are per-image and do not interact with the count — the resolution limits are their own subject.
• Request body size. A base64-encoded image inflates by about a third over its byte size, so twenty large images inline can hit an HTTP body limit before they hit anything model-shaped. Passing URLs instead of base64 removes this one entirely.
• Any documented per-request image cap for the specific endpoint and model you are calling. Check this on the model page for your id; it has differed between the Chat Completions, Responses and Assistants surfaces.
• The context window. Images become tokens in the same budget as your text — for the GPT-4o family, the documented 128,000-token window — and this is what binds in practice.

The documented token cost of one image

OpenAI documents image cost as a function of the detail field on the image content part, which takes low, high or auto. For the GPT-4o family, as documented at the time of writing:

• detail: “low” — a flat 85 tokens, whatever the image is. The image is reduced to a single low-resolution representation. Resolution-dependent detail is gone; the model sees layout and gross content.
• detail: “high” — the same 85-token base, plus 170 tokens for each 512×512 tile the scaled image is divided into. The scaling is documented in two steps: fit the image inside 2048×2048 preserving aspect ratio, then scale so the shortest side is 768 pixels.
• detail: “auto” — the default, which picks between the two based on the input size. Convenient and non-deterministic for budgeting, so set it explicitly wherever the cost matters.

Two things about that formula are worth internalising. It is a step function, not a smooth one, so an image one pixel over a tile boundary costs a whole extra 170 tokens. And it depends on aspect ratio as much as on size: a square and a panorama with the same pixel count tile differently.

A worked example

Take a 1024×1024 screenshot at detail: “high”. Every step below is the published rule applied in order:

Start                 1024 x 1024
Fit within 2048x2048  1024 x 1024   (already inside; unchanged)
Shortest side to 768   768 x  768   (scaled by 0.75)
Tiles of 512x512      ceil(768/512) = 2 across, 2 down = 4 tiles

tokens = 85 + (170 x 4)
       = 85 + 680
       = 765 tokens

Now a wide one: 1920×1080, the same setting.

Start                 1920 x 1080
Fit within 2048x2048  1920 x 1080   (already inside)
Shortest side to 768  1365 x  768   (scaled by 768/1080 = 0.711)
Tiles                 ceil(1365/512) = 3 across, ceil(768/512) = 2 down = 6

tokens = 85 + (170 x 6)
       = 85 + 1020
       = 1105 tokens

Same file size class, 44% more tokens, purely from the aspect ratio. The same image at detail: “low” is 85 tokens — a 13x reduction, and the decision that dominates every other image-related cost decision you will make.

How many fit

Assumptions, stated: the GPT-4o family’s documented context window of 128,000 tokens; images only, no text prompt; nothing reserved for output. That gives the absolute ceiling, which is not a number to build on but is the right starting point:

detail: "low"    128,000 / 85    = 1,505 images  (ceiling)
1024x1024 high   128,000 / 765   =   167 images  (ceiling)
1920x1080 high   128,000 / 1,105 =   115 images  (ceiling)

Now make it realistic. Reserve 4,000 tokens for the prompt and the instructions around the images, and reserve the output — the GPT-4o family’s max output tokens come out of the same window, so a 4,096-token answer is 4,096 tokens of images you cannot send. Call it 8,000 tokens of overhead:

(128,000 - 8,000) / 765 = 156 images at 1024x1024 high detail
(128,000 - 8,000) / 85  = 1,411 images at low detail

So the honest answer to the question in the title is: on the order of a hundred and fifty high-detail screenshots, or over a thousand low-detail thumbnails, before the context window stops you — assuming no lower per-request cap applies on your endpoint, which is the one thing you must check rather than derive.

Two adjustments before you use those numbers. The multipliers in the formula are per model family: gpt-4o-mini in particular is documented with different image token multipliers from gpt-4o, which is why the cheaper model is not automatically the cheaper choice for a vision workload — the price per token is lower and the tokens per image are not. And if any of the images are passed as base64 data URLs, the encoded string sits in the request body but the token cost is still computed from the decoded image, so the body size and the token count are two separate ceilings that bind at different points.

Verifying the count against usage

Do not ship a budget built on arithmetic you have not checked against the API. The usage object prices the request that actually happened, and one request tells you whether your model of the formula is right:

{
  "model": "gpt-4o-2024-08-06",
  "max_tokens": 1,
  "messages": [{
    "role": "user",
    "content": [
      { "type": "text", "text": "." },
      { "type": "image_url",
        "image_url": {
          "url": "https://example.com/shot-1024x1024.png",
          "detail": "high"
        }
      }
    ]
  }]
}

Subtract the token cost of the one-character text part and the fixed per-message overhead, and what remains should be the 765 tokens derived above for a 1024×1024 image. Run the same request with detail set to low and the remainder should be 85. If either disagrees, the multipliers have changed for your model and every number on this page needs re-deriving with the new ones — which takes about a minute, because the structure of the calculation does not change.

Do this once per model you send images to, and keep the result in a test. A vision cost model built on a formula nobody re-checks is how a workload quietly triples in price after a model migration.

Why the practical number is lower

The arithmetic gives you a ceiling. Three reasons the number you should actually send is well below it:

• Cost is linear and unforgiving. 150 high-detail images is roughly 115,000 input tokens on a single request. Multiply by your input rate and by your request volume before deciding this is a design you want. Batching images into one call is not a saving; it is the same tokens in fewer HTTP requests.
• Attention over a full window is not attention over a small one. Retrieval quality across a very long multimodal context degrades in ways that are workload-specific and worth measuring on your own task. Filling the window because it fits is not the same as it working.
• Latency scales with prefill. 115,000 input tokens is a long prefill and shows up directly in time to first token, which is usually the number a user experiences.

The design that usually wins is a cheap pass at detail: “low” over everything to find the few images that matter, then a second call at high over only those. Two requests, a fraction of the tokens, and a much shorter prefill on both.