GPT Image 2.5 on ElevenLabs: 14 ratios plus auto. Sume lists 17
ElevenLabs offers 14 fixed ratios plus auto for GPT Image 2.5. Sume's normalized list has 17 plus auto. Read what each model accepts before sending one.

ElevenLabs' September 21 changelog says gpt-image-2.5-flare and gpt-image-2.5-sunburst output 1K, 2K or 4K in 14 fixed aspect ratios plus auto. Sume's image docs describe a normalized list of 17 ratios plus auto, but they also say a model accepts only the values its own catalog descriptor lists, so the 17 is a vocabulary and not a promise for every model.
The practical rule is the same on both platforms: read the accepted values for the model you call and validate your ratio against them before you submit.
The two lists side by side
The ElevenLabs entry gives the count of fixed ratios but not the ratios themselves, so this table compares counts and rules only. Sume's list is quoted from its Images page.
| Item | ElevenLabs GPT Image 2.5 | Sume normalized vocabulary |
|---|---|---|
| Fixed ratios | 14 | 17 |
| Provider choice | auto | auto |
| Output tiers | 1K, 2K, 4K | 512, 1K, 2K, 4K (normalized tiers) |
| Reference images | Up to 10 | See the model's descriptor |
The Sume list
Sume's Images page lists these normalized values for aspect_ratio: 1:1, 16:9, 9:16, 4:3, 3:4, 3:2, 2:3, 4:5, 5:4, 1:2, 2:1, 1:4, 4:1, 1:8, 8:1, 9:21 and 21:9. It adds that 4:5 is Instagram portrait at 1080 by 1350 and not 4:3, and that a model only accepts the values its catalog descriptors list.
For edits the docs advise aspect_ratio: "auto" to match the reference, and note that omitting the field is not the same as auto. They also say not to put custom pixels on size; use image_size or aspect_ratio instead.
Check a ratio against the live descriptor
Sume's Images page shows a per-endpoint record at /v1/images/models/{id}/endpoints whose supported_parameters.aspect_ratio.values lists the accepted ratios. This script reads it and refuses a ratio the model does not list. The model id openai/gpt-image-2.5 comes from the same docs.
import os
import requests
def accepted_ratios(model_id):
url = f"https://api.sume.com/v1/images/models/{model_id}/endpoints"
r = requests.get(url, headers={"Authorization": "Bearer " + os.environ["SUME_API_KEY"]}, timeout=30)
r.raise_for_status()
values = set()
for ep in r.json().get("endpoints", []):
spec = ep.get("supported_parameters", {}).get("aspect_ratio", {})
values.update(spec.get("values", []))
return values
if __name__ == "__main__":
ok = accepted_ratios("openai/gpt-image-2.5")
wanted = "4:5"
print(wanted, "accepted" if wanted in ok else "not listed", sorted(ok))Why this matters for ad sets
A multi-placement ad set usually needs squares, portrait and landscape from one concept. If your pipeline hard-codes ratios, a model that lists fewer values will reject one of them mid-batch. Validating up front turns that into a config error you see before any job is submitted.
- Fetch the accepted values once per model and cache them for the batch.
- Use
autoon edits, not an omitted field. - Do not infer support from a vendor count; two models can share a count and differ in values.
- Keep the ratio in the job metadata so a rerun uses the same one.
Edits and drift
Ratio mismatches are most costly on edits. A source image edited with a requested ratio that differs from its own may not match the source, which is why the Sume docs push auto for edits. Treat the ratio as part of the edit contract: store the source ratio next to the image, and send auto unless you intend to reframe.
For a first generation the choice is yours, and the safest list is the intersection of what your target placements need and what the model's descriptor offers. Anything outside that intersection should be generated at a nearby ratio and cropped as a documented post step.
Sources
Related posts
More in Developers
- ElevenLabs TTS output_format: 192 kbps needs Creator, PCM needs Pro
The ElevenLabs text to speech reference ties 192 kbps MP3 to Creator and PCM or WAV to Pro. A format table, a fallback chooser in Python, and the seed range.
- Gemini 3.8 Live audio: wrap 24 kHz PCM in WAV, resample to 16 kHz
Gemini 3.8 Live takes 16-bit 16 kHz PCM in and returns 24 kHz out. A Python WAV wrapper, an ffmpeg resample command, and the Sume detach settings that match.
- Gemini CLI v0.63 plan execution in CI: gate paid Sume calls first
Gemini CLI preview v0.63.0 adds autonomous plan execution in non-interactive mode. Before unattended runs, gate Sume paid tools with dry_run and max_spend_usd.
- Google's June 15 deprecation notice gave 15 and 63 days: run a drill
Google announced Veo and Imagen 4 deprecations on Jun 15, 2026 with shutdowns Jun 30 and Aug 17. Here is a five-step drill that fits inside the shorter window.
Written by Sume