Sume Auto image aspect_ratio 21:9 returns 400: what to send

sume/auto rejects aspect_ratio 21:9 and lists nine accepted values. Use image_size, or pin a model that lists 21:9, such as Nano Banana Pro or Flux 2 Pro.

4 min readSume
All posts

POST /v1/images with model: "sume/auto" and aspect_ratio: "21:9" returns 400 invalid_request. The error keeps the model as sume/auto and lists what it accepts: auto, 1:1, 16:9, 9:16, 4:3, 3:4, 5:4, 9:8, and 4:5. For an ultrawide image you have two options: send a custom image_size such as 2304x992, or pin a model whose catalog list includes 21:9.

The page for sume/auto says Sume picks the family and never discloses which one ran, and it also notes that Auto routing continues to use ChatGPT Image 2.5's Flare endpoint. The nine-value list matches the GPT Image catalog in Sume's repository, which is consistent with that note. The outputs below were run against the request normalizer on 2026-10-03.

What works for 21:9?

Custom pixels are the route that keeps Auto. GPT-style custom sizes need both edges to be multiples of 16, a maximum edge of 3840, an aspect ratio of at most 3:1, and a pixel count between 655,360 and 8,294,400. 2304×992 is about 2.32:1 and 2,285,568 pixels, so it fits those rules.

Do not put the pixels in aspect_ratio on Auto. In the same run, aspect_ratio: "2304x992" was snapped to 16:9, while image_size: "2304x992" was passed through unchanged.

Normalizer results for a 21:9 target, run 2026-10-03. Rules for GPT custom sizes from docs.sume.com/models/images.
RequestResult
sume/auto, aspect_ratio: "21:9"400 invalid_request, nine accepted values listed
sume/auto, image_size: "2304x992"Accepted; image_size passed through
sume/auto, aspect_ratio: "2304x992"Accepted, but snapped to 16:9
google/nano-banana-pro, aspect_ratio: "21:9"Accepted as 21:9
google/nano-banana-2, aspect_ratio: "21:9"Accepted as 21:9
black-forest-labs/flux.2-pro, aspect_ratio: "21:9"Accepted as 21:9

Should I pin a model for ultrawide work?

If the exact ratio matters across a series, yes. Auto can change with the catalog, and it never tells you the family, so a shape rule that holds today is not part of its contract. Pinning also gives you a catalog entry to read: GET /v1/images/models returns each model's aspect_ratio descriptor.

Pinning has a cost: you take on that model's other rules. Nano Banana models list no quality field, for instance, and sending one returns 400 unsupported_parameter. Read the descriptors for every field you set, not only the aspect ratio.

How do I read the supported list in code?

The 400 body carries details.field and details.supported. Log both on a rejected call, and keep the request_id from the error envelope. A pipeline that targets several ratios can try the target against the list first and choose between image_size and a pinned model before it submits anything.

Does the 400 reveal the model behind Auto?

No. The error message names the public model, sume/auto, and lists the values. The Image API page says Sume never discloses which family ran and that job.model stays sume/auto. The list is the only hint, and you should not build logic on it: if you need to know what a request will accept, pin a model and read its descriptors.

That is also the reason to test a ratio before a campaign. A 400 at submit costs nothing, since failed generations are not billed, but it stops a script halfway through a batch.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume