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.

4 min readSume
All posts

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.

Aspect ratio facts (ElevenLabs changelog read 2026-10-03; Sume docs read 2026-10-03)
ItemElevenLabs GPT Image 2.5Sume normalized vocabulary
Fixed ratios1417
Provider choiceautoauto
Output tiers1K, 2K, 4K512, 1K, 2K, 4K (normalized tiers)
Reference imagesUp to 10See 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 auto on 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

All Developers posts

Written by Sume