GPT Image 2.5 custom size for a 4:5 post: why 1080x1350 is rejected

On Sume's openai/gpt-image-2.5, a custom image_size needs both edges to be multiples of 16, with a maximum edge of 3840, an aspect ratio of at most 3:1 and between 655,360 and 8,294,400 pixels. Instagram's portrait size of 1080 by 1350 breaks the first rule, because neither number divides by 16. The simple fix is aspect_ratio: "4:5"; if you need exact pixels, ask for 1088 by 1360 and crop on your side.

This comes up when a shop wants listing and feed images that match a platform's stated size. ChatGPT's new shopping images (read 2026-10-03, OpenAI pages) are made inside the chat, but a store producing its own images works to its own pixel targets, and the model's rules decide what you can ask for.

The arithmetic

Divide each edge by 16. 1080 divided by 16 is 67.5 and 1350 divided by 16 is 84.375, so both fail. The nearest multiples are 1088 (68 times 16) and 1360 (85 times 16). That pair has the same 4:5 ratio, 1,479,680 pixels, and sits inside the allowed range. Cropping 4 pixels per side horizontally and 5 vertically gives exactly 1080 by 1350 without resizing.

Two routes

Route one is aspect_ratio: "4:5", which the Sume docs name as Instagram portrait, 1080 by 1350, and let the model choose its native size. Route two is a custom image_size of 1088 by 1360 followed by a crop in your own pipeline. The Sume guide does not show the exact string syntax for custom pixels, so read the catalog's supported_parameters and the API reference before you send one.

On edits, prefer aspect_ratio: "auto" to match the reference, as the auto versus omitted post explains; use 4:5 only when you need a new frame shape. Do not put pixel values in the size field, which is shorthand for a resolution tier.

def fits_16(w: int, h: int) -> bool:
    px = w * h
    return (w % 16 == 0 and h % 16 == 0 and max(w, h) <= 3840
            and max(w, h) / min(w, h) <= 3
            and 655_360 <= px <= 8_294_400)

for size in [(1080, 1350), (1088, 1360), (1024, 1024), (2160, 2700), (3840, 2160)]:
    print(size, fits_16(*size))

Unsupported parameters

Sending a parameter the model does not serve returns 400 unsupported_parameter. seed and output_compression are in the schema but not served in v1, so do not rely on them to make a 4:5 crop repeatable. stream: true returns 400 streaming_not_supported. If you need the same framing across a catalogue, keep the same prompt, reference and aspect setting, and compare outputs yourself.

Check what the model returned rather than what you asked for: read the image's real dimensions from the stored file before you crop. A pipeline that crops blindly will cut off the wrong edge if a result comes back at a different size than you expected. See also the image-not-fetchable post for URL errors on the input side.

A cropping step that is safe

If you take the crop route, do it from the centre unless the product sits off-centre, and check the result visually on a sample before running a batch. Four pixels off each side is invisible on most images, but a product that touches the frame edge can lose a sliver. Keep the original 1088 by 1360 file next to the cropped one so you can redo the crop if a platform changes its size.

Do not upscale to hit a size. If a destination asks for a larger image than the model's range allows, raise the request to a size inside the range and let the platform scale it, or check the Image API docs for a model that serves a larger edge. The maximum edge on 2.5 is 3840, which is already large for a feed post.