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.

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.
| Request | Result |
|---|---|
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
- sume/auto video returns 400 unsupported_capability: 2 s, 11 s, 480p
Why a sume/auto video request fails with 400 for 2 or 11 seconds, 480p, 768p or generate_audio false, and which pinned model takes the value instead.
- sume/auto, auto and auto-: three spellings, and two ids it never picks
Video Router accepts auto-, sume/auto and auto as the same Auto pipe. Genjutsu and H3 Max Recast stay explicit picks. Defaults, limits and what to pin instead.
- Sume Auto video: an idempotent replay prices and routes the same
sume/auto resolves from the normalized request and catalog version, so a replay with the same Idempotency-Key prices and routes the same. Retry design.
- Retrying a sume/auto video submit: same key, same job, same price
Auto routing is a pure function of the normalized request and the catalog version, so an idempotent replay routes and prices identically. What changes it.
Written by Sume