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:Test Results: Image Size vs. Outcome
On 2026-10-20 we sent the same image at different sizes togpt-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
image_url.url. After resizing, an image is usually a few hundred KB and returns within seconds.
FAQ
Why does the same model work fine for other users?
Why does the same model work fine for other users?
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.
Am I charged for these failures?
Am I charged for these failures?
Requests rejected by the provider (
429, 400) do not create a consumption record. You can confirm this in your usage logs.Will a longer client timeout fix it?
Will a longer client timeout fix it?
No. A longer timeout only means you wait until the provider rejects the request; it still fails. The fix is to resize the image.
Do Claude, Gemini, and other models have limits too?
Do Claude, Gemini, and other models have limits too?
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.Related Docs
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