4 of Sume's 17 aspect ratios exceed 3:1, GPT Image 2.5's size cap

Sume normalizes 17 aspect ratios; 1:4, 4:1, 1:8 and 8:1 are wider than the 3:1 limit on GPT Image 2.5 custom sizes. A check script and the 2 other rules.

5 min readSume
All posts

Four of the 17 aspect ratios in Sume's normalized list are more extreme than 3:1: 1:4, 4:1, 1:8 and 8:1. The Sume Image API docs state that GPT Image 2.5 custom pixel sizes must keep the aspect ratio at 3:1 or less, so a 4:1 banner is a ratio the Sume list knows about but a GPT Image 2.5 custom size cannot be. The docs also say that a model accepts only the values its catalog entry lists, so the normalized list is a ceiling and not a promise for every model.

This matters when a banner or a tall strip is on your plan. You can pick the aspect ratio from the normalized list and then discover that the model you chose does not offer it.

The 17 values and the four that run long

The normalized list in the docs is 1:1, 16:9, 9:16, 4:3, 3:4, 3:2, 2:3, 4:5, 5:4, 1:2, 2:1, 1:4, 4:1, 1:8, 8:1, 9:21 and 21:9. The long side divided by the short side gives the number in the second column.

Most elongated Sume aspect ratios against the 3:1 GPT Image 2.5 custom-size limit, as of 2026-10-09
RatioLong side / short sideAgainst the 3:1 limit
21:92.33within
9:212.33within
2:12.00within
1:22.00within
4:14.00over
1:44.00over
8:18.00over
1:88.00over

Three GPT Image 2.5 custom-size rules together

The same docs give three rules for custom pixels on GPT Image 2.5. Both edges must be multiples of 16. The maximum edge is 3840. The image must hold between 655,360 and 8,294,400 pixels. The 3:1 limit is the fourth condition on top of those. A 3840 by 1280 image is exactly 3:1 and holds 4,915,200 pixels, so it passes. A 4096 by 1024 image fails on the edge limit even though it is only 4:1 in shape.

For wider shapes you have two options. Generate at the widest legal size and crop, or pick a model whose catalog entry lists the ratio you need. The ratio-specific posts on this blog cover individual cases, and the descriptors from GET /v1/images/models remain the source of truth. Treat the generated crop as part of the plan: a 3840 by 1280 render cropped to 4:1 keeps 3840 by 960 pixels, which is still a large banner for most web slots.

If the output is for print or a very large display, run the result through an upscale step afterwards instead of asking the model for an edge it will not accept.

A validator in Python

The function below applies all four rules to a width and height, and returns a list of the rules that fail. An empty list means the size is legal for a GPT Image 2.5 custom size under the Sume docs.

def gpt_size_errors(width, height):
    errors = []
    if width % 16 or height % 16:
        errors.append("edges must be multiples of 16")
    if max(width, height) > 3840:
        errors.append("max edge is 3840")
    pixels = width * height
    if not 655_360 <= pixels <= 8_294_400:
        errors.append("pixels must be 655,360 to 8,294,400")
    if max(width, height) > 3 * min(width, height):
        errors.append("aspect ratio must be 3:1 or less")
    return errors

for size in [(3840, 1280), (4096, 1024), (1920, 1080), (1920, 1088)]:
    print(size, gpt_size_errors(*size) or "ok")

Where to read the real list

Call GET /v1/images/models/{model_id}/endpoints for the model you plan to use and read supported_parameters.aspect_ratio. If a ratio is not in the enum, Sume answers 400 unsupported_parameter rather than silently changing the shape, as the Image API docs describe.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume