Aspect ratio auto on Sume: 6 image models list it, 8 edit models don't
Which Sume image models accept aspect_ratio auto when you edit a photo, which edit models reject it with a 400, and how to pick a ratio in code instead.

Six models in the Sume image catalog list auto as an aspect_ratio value: openai/gpt-image-2, openai/gpt-image-2.5, openai/gpt-image-2.5-sunburst, google/nano-banana-2.1, google/nano-banana-pro and bytedance-seed/seedream-4. Eight other models can edit a photo but do not list it, so a request with aspect_ratio: "auto" to them fails with a 400 instead of matching your source image.
That matters because the Image API docs say that on edit and image-to-image calls, auto matches the reference, and that leaving the field out is not the same thing. If your pipeline sends auto everywhere, it works on six models and breaks on the rest.
The six that list auto, and the eight that do not
The split below comes from the capability descriptors in the Sume image catalog, read on 2026-10-10. A model is an edit model here if its input_references range allows at least one reference.
| Model id | Lists auto | Max references |
|---|---|---|
| openai/gpt-image-2 | yes | 10 |
| openai/gpt-image-2.5 and -sunburst | yes | 16 |
| google/nano-banana-2.1 | yes | 10 |
| google/nano-banana-pro | yes | 10 |
| bytedance-seed/seedream-4 | yes | 10 |
| bytedance-seed/seedream-4.5 | no | 10 |
| bytedance-seed/seedream-5-lite | no | 10 |
| black-forest-labs/flux.2-pro and flux.2-flex | no | 10 |
| ideogram/ideogram-v3 | no | 10 |
| ideogram/ideogram-v4.5 | no | 5 |
| qwen/qwen-image | no | 10 |
| x-ai/grok-image | no | 10 |
What the failure looks like
When a model has an aspect_ratio list and your value is not in it, Sume answers 400 invalid_request. The message names the model and the value, and details.supported holds the full list for that model. This is different from unsupported_parameter, which means the model does not advertise the field at all. Sume does not silently swap in a nearby value.
So the error is cheap to handle: catch the 400, read details.supported, choose again. It is better to avoid the round trip by reading the list from GET /v1/images/models before you send.
What to send for the eight
For Ideogram 4.5, the docs state that an edit without aspect_ratio keeps the shape of the source image, so leaving the field out is the right move there. For the other seven, the docs do not promise that an omitted ratio follows the source, so pick a ratio on purpose.
The simple rule is to measure your source image, find the nearest ratio in the model list, and send that. A landscape photo at 4000 by 3000 is 4:3, which every one of the eight lists. A 1080 by 1350 portrait is 4:5, which all of them except Grok Image list; there the nearest entry is 3:4.
def nearest_ratio(width, height, supported):
target = width / height
best = None
for value in supported:
if value == "auto":
continue
w, h = (float(x) for x in value.split(":"))
gap = abs(w / h - target)
if best is None or gap < best[0]:
best = (gap, value)
return best[1]
supported = ["1:1", "16:9", "9:16", "4:3", "3:4", "4:5", "5:4", "3:2", "2:3"]
print(nearest_ratio(4000, 3000, supported))
print(nearest_ratio(1080, 1350, supported))Why the field exists on only some models
The Image API publishes what each model accepts as a capability descriptor: an enum for discrete values, a range for integers, a boolean for presence. For aspect_ratio the enum is the model's real list, and auto is one entry in it, not a universal switch. The same catalog entry tells you whether references are accepted at all, so one call to the models endpoint answers both questions before any money is spent. See the Image API docs for the descriptor format.
When the nearest ratio is not close enough
A nearest-ratio pick changes the shape a little. For a 1000 by 1100 source, 1:1 is the closest entry on most lists, and the result is a square. If you must keep the exact frame, the choice is a model that lists auto, then crop or resize afterwards in your own step.
A second option is to stop trusting one request shape. Keep a small table in your code of ratio support per model, filled from the catalog at start-up, and build each edit request from it. That way a model swap, for example from Seedream 4 to Seedream 4.5, changes the ratio field in the same commit as the model id instead of failing in production on the first photo.
Also note the order of choices. Do not pick a model for its price and then discover it lacks auto. Put the ratio requirement in the filter at the start, with the reference count, as a capability check against the catalog.
- If the source shape must be preserved with no crop, choose from the six that list
auto. - If you have chosen Ideogram 4.5, omit the field on edits.
- For the other seven, compute the nearest listed ratio and send it.
- Log the ratio you sent next to the source size so a reviewer can see why the shape changed.
Sources
Related posts
More in Models
- Sume image catalog on 2026-10-10: 19 ids from 0.5 to 26 cents
All 19 Sume image model ids sorted by base price, with how many take references, lists auto, offer a quality field, a resolution field, or a mask.
- Is Utopai X on Sume? It is built on MiniMax H3, which Sume lists
Utopai X runs inside Utopai's PAI platform and is post-trained on MiniMax H3. Sume does not list Utopai X; it lists minimax-h3 and minimax-h3-max.
- Veo 3.1 4K needs an 8-second clip; Sume's Veo rows stop at 720p
Google offers Veo 3.1 1080p and 4K only at 8 seconds. Sume's Veo rows run 720p at 4, 6 or 8 seconds. See the gap and which Sume row reaches 4K.
- Veo 3.1 Lite (Preview) on Sume: what the preview label means
Sume's catalog names the row 'Veo 3.1 Lite (Preview)'. Its limits, the audio rates, and how it differs from the Gemini API's Lite lines for 720p and 1080p.
Written by Sume