9:16 cover still: 1080x1920 fails GPT Image 2.5, 1088x1920 passes

For a vertical cover still on GPT Image 2.5, 1080x1920 is not a valid custom size because 1080 is not a multiple of 16, while 1088x1920 passes. The Sume Images API docs set three conditions: both edges are multiples of 16, the maximum edge is 3840, and the total is 655,360 to 8,294,400 pixels, with an aspect ratio of at most 3:1.

Check the common vertical sizes

The rule is in the Image API docs for openai/gpt-image-2.5 and openai/gpt-image-2.5-sunburst. I checked each candidate size against all three conditions with simple arithmetic; the table shows the results (docs read 2026-10-05).

Which to choose

Three of the passing sizes are exactly 9:16: 864x1536, 1152x2048 and 2160x3840. That is useful because a cover that is exactly 9:16 can be placed in a 1080x1920 timeline frame with no crop. 1088x1920 is slightly wider than 9:16, so a cover fit would trim a few pixels at the sides.

A request

Send the size in image_size. The Images API accepts named presets, auto, or custom pixels. A request for a 1152x2048 cover:

curl -X POST https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: cover-1152-001" \
  -d '{
    "model": "openai/gpt-image-2.5",
    "prompt": "A clean product cover on a soft gray backdrop, centered, room for a title at the top",
    "image_size": {"width": 1152, "height": 2048},
    "quality": "high"
  }'

Quality and budget

The default quality is high if you omit it. The docs list low, medium, high, xhigh, max and auto, and note that auto reserves max. Because auto size also reserves the upper bound of output tokens, a fixed size and quality is easier to budget.

Which field takes the size

The Image API reference lists image_size as an enum or a {width,height} object, and says it takes priority over aspect_ratio. The size field is only a tier shorthand and rejects WxH, so never put custom pixels there. Confirm the live shape in the OpenAPI at https://api.sume.com/reference/json before you ship code.

Another route

If the cover is a still for a video, Ideogram 4.5 is the other option in the docs. It takes resolution: 1K|2K and an aspect_ratio, and an edit without aspect_ratio keeps the shape of the source. Its list price is $0.03, $0.06 or $0.22 per image by quality, before Sume's markup.

Check the rule in your own code

Why does the rule exist? The docs do not say, and I will not guess at the reason. What matters in practice is that the API will reject a size that breaks it, and that failure should be caught by your own check first. A tiny function that tests the three conditions runs in a few microseconds and saves a failed call.

Do the three tests

The arithmetic is simple enough to do by hand. Divide each edge by 16 and look for a whole number. Multiply the edges and compare with 655,360 and 8,294,400. Divide the long edge by the short edge and compare with 3. A vertical 9:16 frame has a ratio of about 1.78, so the 3:1 limit never matters for it, and the two things that do matter are the multiple of 16 and the minimum pixel count.

Using the still in a timeline

After you generate the still, you can use it as a first frame or a cover in a later step. If you place a 1152x2048 still in a Timeline 1.0 slot at the default 1080x1920 output, the still is a static hold, and the fit field decides how it fills the frame: cover is the default, with contain, stretch and blur also listed. Because the still is exactly 9:16, cover removes nothing.

A limit to know

Still images are static holds in a timeline. The job accepts a motion field for stills but ignores it and reports motion_ignored, so do not rely on a zoom or pan from the timeline itself.

Keep a size table

Keep the passing sizes in a small table in your own repo, next to the code that builds the request. When someone later asks for 1080x1920, the table answers the question without a failed call, and it records that the three tests were checked against the docs on a given date.

The takeaway

Pick 1152x2048 or 864x1536 for an exact 9:16 cover, and avoid 1080x1920 as a custom size.