Seedream 4.5 on Sume: edits return one image, 4:5 is 1920x2400

On Sume, bytedance-seed/seedream-4.5 behaves differently from the other Seedream rows in two ways you can check in the request path. When you send reference images it asks the provider for exactly one output image, whatever n you set, and it only passes on the first 10 reference URLs. And a ratio such as 4:5 is turned into an explicit pixel box of 1920x2400 instead of being sent as a named size.

None of this is in the public docs table, so this post records what the Sume code does and how to confirm it from your own response.

What happens to n on a Seedream 4.5 edit?

The catalog publishes n as a range of 1 to 4 for Seedream 4.5, so a request with n: 4 and references passes validation. The provider payload for an edit call, however, sets num_images to 1. Text-to-image calls without references pass your count through, so the same n: 4 gives four images there.

I could not confirm from the docs how billing treats the difference between the requested count and the returned count on that path, so do not assume. Count the entries in data[], compare them with what you asked for, and read usage.cost on a first test. If you need four edited variants, make four calls, or choose a row that returns the count you ask for.

import os, requests

r = requests.post(
    "https://api.sume.com/v1/images",
    headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"},
    json={
        "model": "bytedance-seed/seedream-4.5",
        "prompt": "Same product, soft daylight studio background",
        "input_references": [{"type": "image_url", "image_url": {
            "url": "https://example.com/product.png"}}],
        "n": 4,
    },
    timeout=60,
)
print(r.status_code)
body = r.json()
if r.status_code == 200:
    print("asked 4, got", len(body["data"]), "cost", body["usage"]["cost"])

How are 4:5 and other ratios sent?

Seedream 4.5 takes an image_size in the provider payload. Sume maps the five common ratios to named presets and everything else to explicit pixels, with each edge held between 1920 and 4096. The pixel boxes below come from the repo's helper functions.

Why does the pixel box matter?

A 4:5 image at 1920x2400 is larger than Instagram's 1080x1350, so you downscale rather than upscale, which keeps edges clean. The docs say exact 1080x1350 is a post-step for Nano Banana, and for Seedream 4.5 you get 4:5 at the larger box and resize it yourself. A pixel string such as 1080x1350 sent as image_size is scaled into the legal box: each edge is raised to at least 1920 and the long edge is capped at 4096, so 1080x1350 becomes 1920x2400.

The two other Seedream rows do not use this function. Seedream 4.0 lists auto as an aspect value and Seedream 5.0 Lite goes through the generic image-size path, so do not assume the table above holds for them.

What should I do in practice?

For a batch of variants from a reference, loop single calls on bytedance-seed/seedream-4.5, saving each returned URL, and keep your own copy of each result. For 4:5 social images, keep the 1920x2400 original and export the 1080x1350 copy from it.

Pass at most 10 reference URLs. The catalog already enforces 10 and returns a 400 above it, so the cut to 10 inside the payload is a second guard, not something you will normally meet. The Seedream image API post covers the basic call and the model ids.

What else is different about the other Seedream rows?

Seedream 4.0 lists auto among its aspect values, and Seedream 4.5 and 5.0 Lite do not, so an auto edit works on 4.0 only. The aspect-ratio auto post has the full table.

Treat the three rows as three models when you test, not as one family with a version number. Their ratio handling, their request path and their prices are separate, so a prompt tuned on one needs a short re-test on the others before you move a production job.