Exact 16:9 sizes on GPT Image 2.5: 1280x720, then steps of 256

The smallest exact 16:9 size that GPT Image 2.5 accepts on Sume is 1280x720, and every larger exact 16:9 size has a width that is a multiple of 256: 1536x864, 1792x1008, 2048x1152, 2560x1440, up to 3840x2160. 1024x576 is too small and 1920x1080 is not a multiple of 16, so both fail.

The reason is arithmetic, not taste. The Image API docs (read 2026-10-06) say both edges must be multiples of 16, the longest edge is at most 3840, the aspect ratio is at most 3:1, and the image must have 655,360 to 8,294,400 pixels.

Why 256

For 16:9 the height is nine sixteenths of the width. If the width is 16 times k, the height is 9 times k. For the height to be a multiple of 16, k must be a multiple of 16, so the width must be a multiple of 256. That is why 1080 never works: 1920 divided by 16 is 120, and 120 times 9 is 1,080, which is not a multiple of 16.

The pixel floor removes the small ones. 1024x576 is a clean 16:9 box with all edges multiples of 16, but 589,824 pixels is below 655,360.

The sizes, checked

Check before you send

A five-line check saves a failed call. This one encodes the documented rules and prints the result for each exact 16:9 width.

def legal_gpt_image_25_size(w, h):
    # Rules from the Sume Image API docs (read 2026-10-06).
    ok = w % 16 == 0 and h % 16 == 0
    ok = ok and max(w, h) <= 3840
    ok = ok and max(w, h) / min(w, h) <= 3
    return ok and 655_360 <= w * h <= 8_294_400

for w in (768, 1024, 1280, 1536, 1792, 1920, 2048, 2560, 3840):
    h = w * 9 // 16
    print(f"{w}x{h}", legal_gpt_image_25_size(w, h))

What to do when you need 1920x1080

Render at 1792x1008 or 2048x1152 and resize, or ask for 1920x1088 and crop 8 pixels. 1920x1088 is not exact 16:9, but it is within half a percent of it. This post covers the blog-hero case, and the 1080p thumbnail post covers YouTube.

The tradeoff is a resize step in your pipeline. The benefit is that you pay for one legal image, not a retry.

Check it on your own account

Do not budget from a blog table alone. GET /v1/images/models lists every model with its descriptors, and GET /v1/images/models/{id}/endpoints shows the pricing line for one model. Then run one small request and read usage.cost on the response, which is the billed amount in USD; the token counts in usage are reported as 0 on this route.

Run the test at the quality and size you plan to ship, because both move the price. A single test at low quality costs under a cent for most sizes here, so it is a cheap way to confirm your assumptions before a batch.

Sync, async and failures

The /v1/images route waits up to 30 seconds for the image. If the job finishes in that window you get the result directly; otherwise you get a 202 and an async job to poll. Write your client to branch on the status code, since larger sizes and higher quality are the likely cases for a 202.

Requests are strict. A parameter the chosen model does not list returns 400 unsupported_parameter, stream returns a 400, and provider.only or provider.order accept only sume. Treat a 400 as a bug in the request, not a transient error, and do not retry it unchanged.