Video API 400 unsupported_parameter: size, seed and provider.options

Sume's POST /v1/videos answers 400 unsupported_parameter when the body carries size, seed, or a non-empty provider.options, because none of the v1 models supports them. The fix is to describe the picture with resolution and aspect_ratio, drop the seed, and drop provider options. These are three of the differences from the OpenRouter video wire that the Sume video docs list, so a client written for that wire can fail on any of them.

Why does each field fail?

The docs give a reason for each one. Every v1 model reports supported_sizes: null, so size has nothing to match and is refused. No v1 model accepts seed; each reports seed: false and rejects the field. And v1 runs a single backend per model, so there is nothing for provider.options to be forwarded to, which makes a non-empty value a 400 as well.

What if my client always sends them?

Filter the body before it leaves your process. The function below drops size and seed and removes an empty provider wrapper, and the check at the end prints the keys that survive, which is what you want in a unit test for your video client.

REFUSED = ("size", "seed")

def clean(body):
    body = {k: v for k, v in body.items() if k not in REFUSED}
    opts = body.get("provider", {}).get("options")
    if not opts:
        body.pop("provider", None)
    return body

req = {
    "model": "wan-3.0",
    "prompt": "A paper boat crossing a puddle",
    "size": "1280x720",
    "seed": 7,
    "resolution": "720p",
    "aspect_ratio": "16:9",
    "provider": {"options": {}},
}
print(sorted(clean(req)))

Is this the same as a capability error?

No. A model-level capability problem, such as sending reference images to a model that takes none, is a different class of rejection, and the Sume docs treat the catalog's capabilities as the place to look. The three fields above are refused for every model, so no choice of model avoids them. A request that passes the filter can still fail on model limits, for example a 3-second reference-video rule on Omni, or a duration below a model's minimum.

What do I send for a different take?

Because there is no seed, a rerun is the way to get another take. The docs list the Idempotency-Key header as the retry guard: send one so a retry of the same request returns the original job, and use a fresh key when you actually want a new generation. Rewording the prompt is the other lever, and it changes the result more than a seed would.

The same reasoning applies to resolution. The v1 models advertise a resolution and aspect_ratio pair and no free-form pixel size, which keeps the price knowable: each catalog row prices by second and, for most models, by resolution. A 720p 5-second Wan clip is $0.63 on Sume and the same clip at 1080p is $1.25, which is why the size is a named tier rather than a number you pick.

What does a clean request look like?

The minimal body for any of the models is model, prompt, plus the fields the catalog says that model accepts. For wan-3.0 that is resolution of 480p, 720p or 1080p, duration of 2 to 30, and aspect_ratio from its list. Add Idempotency-Key as a header, not a body field, and mode: "async" if you want to poll.

Keep your client's defaults free of OpenRouter-only habits. If you wrap both providers behind one function, build the Sume body in its own branch rather than deleting keys at the last moment, so a new field added for the other provider cannot leak across.

When a 400 arrives, read the error code and the field it names. unsupported_parameter points at the field to remove. A capability or range error points at the model's limits instead, and the catalog entry for that id is the place to read them.

How do I find the limits for the model I pinned?

Read GET /v1/video-router/models/{model_id} for the catalog entry: its capabilities, accepted resolutions, duration_seconds, aspect_ratios and pricing. The same catalog backs both routes, and bare ids such as wan-3.0 are used, never an org/slug pair. Because the output size comes from resolution and aspect_ratio together, the pixel size of a 720p 9:16 clip is chosen by the model, not by you.