image_size, aspect_ratio or size: which field wins on Sume

Sume's image routes have three size-related fields. image_size carries named presets or custom pixels and has priority over aspect_ratio. aspect_ratio is a normalized ratio like 4:5. size is only a shorthand for a resolution tier and rejects WxH. Use aspect_ratio plus resolution for most requests, and image_size when you need custom pixels on a model that takes them.

What each field accepts

The docs describe size as shorthand for a resolution tier (512, 1K, 2K, 4K), and say not to put custom pixels there. Custom pixels belong on image_size, and are honored on GPT, Seedream, Flux, Qwen and Recraft. Every value has to be listed in the model's catalog descriptors, or the request returns 400 unsupported_parameter.

Two examples

On openai/gpt-image-2.5, a custom size must be 655,360 to 8,294,400 pixels in total. Note that 1080 is not a multiple of 16, so 1080x1350 itself does not follow the rule. On Nano Banana the pixel pair maps to the native aspect_ratio (1080x1350 becomes 4:5), and the exact pixel size comes from a documented post-step through the job's target_pixels, not from the model.

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":"fashion lookbook cover, model in a trench coat","image_size":{"width":1088,"height":1360},"quality":"high"}'

Why 1088x1360 above

A GPT custom size of 1080x1350 does not follow the stated multiple-of-16 rule. 1088x1360 is the nearest valid pair at the same 4:5 ratio, and you crop to 1080x1350 afterwards. The related post on the GPT 1080x1350 custom-size rule covers the handling Sume documents.

Rule of thumb

Send aspect_ratio and resolution first. Add image_size only when you need exact pixels and the model's descriptors allow it. On edits, pass aspect_ratio: "auto" to match the reference, because omitting the field is not the same thing.

Common mistakes

What usually goes wrong:

• Putting 1080x1350 on size, which rejects pixels.
• Assuming 4:5 means 4:3.
• Sending both image_size and aspect_ratio and expecting the ratio to win.