GPT Image 2.5 1080x1350: why the size fails and what to send
1080x1350 breaks GPT Image 2.5's multiple-of-16 size rule. 1080 is not a multiple of 16. 1088x1360 (exact 4:5) meets the listed rules. Per OpenAI and Sume docs.

1080x1350 is not a valid custom size for GPT Image 2.5, because 1080 is not a multiple of 16 (1080 / 16 = 67.5). One pair that satisfies the listed rules is 1088x1360 (our own arithmetic, not a figure from either doc); it is exactly 4:5.
The rule comes from OpenAI's image generation guide, and Sume's Image API docs state the same limits for image_size on GPT models. Both pages were read 2026-09-30.
What are the custom size rules?
OpenAI's guide lists four constraints for custom sizes: "Width and height must be multiples of 16", "The aspect ratio must be between 1:3 and 3:1", "Neither edge may exceed 3840 pixels", and "The total pixel count must be between 655,360 and 8,294,400 (4K)".
Sume's docs give the same numbers for GPT custom pixels: both edges multiples of 16, a maximum edge of 3840, aspect ratio at most 3:1, and 655,360 to 8,294,400 pixels. On ChatGPT Image 2.5, image_size accepts named presets, auto, or custom pixels.
| Size | Edges multiple of 16? | Pixels (655,360 to 8,294,400) | Passes? |
|---|---|---|---|
| 1080x1350 | No (1080 / 16 = 67.5) | 1,458,000 | No |
| 1088x1360 | Yes (68 x 16, 85 x 16) | 1,479,680 | Yes |
How do I request an exact 4:5 image?
Sume's docs say image_size accepts custom pixels on GPT models; the WIDTHxHEIGHT form is shown on the Image 1.0 page, so check the catalog descriptor if it is rejected. 1088x1360 is one pair that meets the rules by our arithmetic: 1088 = 68 x 16, 1360 = 85 x 16, and 1088 / 1360 = 0.8, the same ratio as 4:5. Neither doc names this pair.
curl -X POST https://api.sume.com/v1/images \
-H "Authorization: Bearer $SUME_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-image-2.5",
"prompt": "Product on a soft daylight table, room for a headline at the top",
"image_size": "1088x1360"
}'Can I just send aspect_ratio 4:5 instead?
Sume's Image 1.0 page says 4:5 is Instagram portrait (1080x1350), not 4:3, and that gpt-image-2 also accepts 5:4, 9:8 and 4:5 as aspect_ratio. That is documented for gpt-image-2; for gpt-image-2.5 read the aspect_ratio descriptor from GET /v1/images/models before pinning it. The docs describe exact 1080x1350 as a post-step only for Nano Banana, through the job's target_pixels.
What if a size is rejected?
A request that sets a parameter the selected model does not list is rejected with 400 unsupported_parameter. Check the model's supported_parameters, then fix the size to a multiple-of-16 pair. OpenAI's guide is the source for the rule, so re-read it if the limits change.
How do I check this myself?
Try a small test first: request 1088x1360 at quality: "low", confirm the returned dimensions, and only then run the final. Resizing afterward is a client-side step that Sume's docs do not describe for GPT models. The linked docs pages and the catalog endpoint show the current values, and this post reflects them as of 2026-09-30.
Sources
Related posts
More in Developers
- GPT Image 2.5 Batch API: not supported, so fan out jobs
OpenAI's model page lists Batch as unsupported for GPT Image 2.5. On Sume, submit many async or webhook jobs to /v1/images and collect the results.
- GPT Image 2.5 mask edit: does the mask need an alpha channel?
OpenAI's API says the mask must contain an alpha channel. Sume's docs list a public HTTPS mask_url for GPT Image 2.5 edits but state no mask format rule.
- GPT Image edit with a mask and several images: which is masked?
OpenAI applies the mask to the first of several input images. Sume forwards input_references in order with mask_url, so put the image to edit first.
- GPT Image 2.5 moderation low: can you send it through Sume?
OpenAI lists a moderation parameter (auto or low) for GPT Image 2.5. Sume's request table does not list it, so check the catalog before sending it.
Written by Sume