Skip to main content

Short Answer

Most likely, yes. GPT models process images in 32×32-pixel patches, so a larger image means more patches. When a single image exceeds roughly 30 megapixels (for example 6700×4500), some routes reject it outright. Above roughly 60 megapixels, the request is often queued for several minutes before being rejected during peak hours, so your client times out first and the request looks like it “never responds”. These failures are deterministic: retrying or switching API keys will not help. Resize the image so its longer side is about 2048 pixels before uploading. Recognition quality stays the same, and input tokens drop to a small fraction of the original.

Three Typical Symptoms

The same oversized image can fail in any of these ways, depending on the route and time of day:
Do not ramp up retries when you see 429. Read the error message first: if it mentions maximum usage size or patches, the request itself is too large, and retries only keep occupying concurrency and waiting.

Test Results: Image Size vs. Outcome

On 2026-10-20 we sent the same image at different sizes to gpt-6.1-sol (JPEG, uploaded as Base64 through image_url on the OpenAI-compatible chat endpoint): What this shows:
  • Tokens grow linearly with pixels, roughly “pixels ÷ 1024 × 1.2”. The 9000×6000 image costs about 19 times as many tokens as the 2048 version, with identical recognition results.
  • Whether a large image passes depends on the route and the time of day. The table above was measured off-peak on a single route. Another route enforces a hard limit of 30,000 patches (about 30 megapixels) per image, and the threshold is lower during peak hours.
  • So do not treat “it passed in a test” as a safe limit. For image understanding, a longer side of 2048 pixels is enough.

How to Tell If the Image Is Too Large

1

Check the request body size

Base64 encoding inflates the size by about 1.33×. A request body of several MB, or more than 10 MB, almost certainly means the image was not resized.
2

Check the error message

Search for patches, maximum usage size, or image exceeds. Any of these means the image is too large.
3

Compare with a resized image

Resize the same image to a longer side of 2048 and send it again. If it returns within seconds, the problem is the image size, not the model or the network.

Fix: Resize Before Uploading

Put the return value in image_url.url. After resizing, an image is usually a few hundred KB and returns within seconds.
If you need to read very small text (such as footnotes on a full-page scan), split the page into several tiles and upload them separately, or crop to the region you need, instead of uploading one huge original. Each tile stays within the safe range, and recognition is often better.

FAQ

Most users upload screenshots or phone photos that end up at a few megapixels. The per-request usage limit is only hit when someone uploads originals of tens of megapixels, so other users are not affected at the same time.
Requests rejected by the provider (429, 400) do not create a consumption record. You can confirm this in your usage logs.
No. A longer timeout only means you wait until the provider rejects the request; it still fails. The fix is to resize the image.
Yes, with different rules: Claude rejects any single image over 10 MB (also with a 429), Kimi errors when one image exceeds 16,384 tokens, Seed caps total pixels at 36 megapixels, and Gemini downscales automatically. See the “Downscale large images first” section of Vision Understanding.

Vision Understanding

How to send images to each model, large-image handling, and test results

How Can I Troubleshoot Model API Errors?

Locate problems by error type

How Do I Avoid API Timeouts?

Timeout configuration and long-request troubleshooting

What Are the API Concurrency Limits?

Tell real concurrency limits apart from other 429s