Seedance size parameter returns 400 on Sume: use resolution

Do not send size to /v1/videos. The Sume docs say every v1 model reports supported_sizes: null, so a size value such as 1280x720 returns 400 unsupported_parameter. Send resolution and aspect_ratio instead.

The error is easy to miss because a library written for another provider will often add size by default.

Why does this trip people up?

The Sume video route follows the OpenRouter Video Generation API field for field, and in that API size is accepted where a model advertises supported_sizes. A client written for it can therefore send size and expect it to work. On Sume no v1 model advertises sizes, so the field is rejected.

If you use an SDK that targets the OpenRouter video wire, check whether it sets size from a config value. Some wrappers send it whenever you pass a width and height. Printing the final JSON body before the request goes out is the fastest way to see exactly what Sume receives.

What do I send instead?

The table maps the pixel intent to the two fields. The pairing of the two fields is described in the docs as interchangeable with size, in the sense that together they express the same target.

Read the table as an intent map rather than a pixel guarantee. For the exact pixel count each ratio produces, the pixel post linked below lists them, and the model entry is the final word. The rule of thumb is that resolution names the quality tier and aspect_ratio names the shape.

A square clip at 720p is not 1280 by 720; it is whatever the model produces for 1:1 at that tier. If an exact frame size matters for a platform, generate at the nearest listed tier and conform the file afterwards in your editor.

Does every Seedance id take every resolution?

No. seedance-2.5 accepts 4 to 30 seconds at 480p, 720p and 1080p per the docs, and seedance-2 also offers 1080p. Read supported_resolutions from GET /v1/videos/models for the id you pin.

How do I fix an existing client?

Search your code for the key size in video payloads and replace it. If you map from a pixel string, split it into a lookup like the table above. The related resolution-in-pixels post covers the actual pixel counts by ratio. Sume also rejects non-empty provider.options and the seed field in v1, so strip those from OpenRouter payloads at the same time.

A quick test after the change: submit one 480p request with only the two new fields and confirm a 202 and a job id come back. Then run your real payload. Keeping the check at 480p keeps the cost of the test low, and the error, if any, will name the parameter at fault.