size vs image_size on Sume's Image API: where custom pixels go

On POST /v1/images, size is only a shorthand for a resolution tier (512, 1K, 2K, 4K). Do not put custom pixels on it; use image_size or aspect_ratio, and explicit pixel size is not advertised by any model in v1, so it returns 400 unsupported_parameter.

From Sume's Image API docs and Image 1.0 docs, read 2026-09-30.

What does each field do?

The docs separate tiers from pixels.

Where do custom pixels work?

Image 1.0 documents image_size as named presets or { width, height } / WIDTHxHEIGHT on models that accept custom pixels (GPT, Seedream, Flux, Qwen, Recraft). For GPT custom sizes both edges must be multiples of 16, the maximum edge is 3840, the aspect ratio at most 3:1, and pixels between 655,360 and 8,294,400. On Nano Banana, WxH maps to the native aspect_ratio, and exact pixels are a documented post-step via job target_pixels.

What does a valid request look like?

Custom pixels on image_size, not size:

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": "Wide banner of a mountain lake",
    "image_size": "2048x1024"
  }'

What if I want auto on edits?

On edit and image-to-image calls, prefer aspect_ratio: "auto" to match the reference; omitting the field is not the same as auto. Read each model's descriptors before pinning a tier or ratio.

How do I check this myself?

When in doubt, read the model's descriptors first: they are the only list of what a given model accepts, and a parameter it does not list is rejected with 400 unsupported_parameter rather than silently dropped. The linked docs pages and the catalog endpoint show the current values, and this post reflects them as of 2026-09-30.