Which Sume video models list auto or adaptive aspect for a start image

Seedance 2.5, 2, Fast and Mini, and Wan 3.0, list auto and adaptive among their aspect ratios, and MiniMax H3 and H3 Max list adaptive. Kling 3 lists only 16:9, 9:16 and 1:1, and Gemini Omni Flash 1.1 lists only 16:9 and 9:16. So if your start image is not one of those fixed shapes, the first group is where to look, and with Kling or Omni you pick the nearest listed ratio or crop the still before you send it.

The aspect lists side by side

These lists are from the Sume catalog capabilities, read 2026-10-08. What auto and adaptive do for a given start image is defined per model in the catalog, so read the model entry before you rely on either.

Stills that are not on the list

A 4:5 portrait still, common for social feeds, is not named by any of the five rows above. Choose between adaptive or auto where a model lists it, and a 3:4 or 9:16 crop where it does not. The Video generation page also names 3:2, 2:3 and 9:21 as values the API vocabulary knows, but each model accepts only the subset in its own supported_aspect_ratios. Anything outside that subset is rejected, so check the field first.

Does the ratio change the price?

For Seedance 2.5 the grid is keyed by ratio. At 10 s and 720p, 9:16 and 1:1 both cost $5.78. At 480p and 10 s, 9:16 costs $2.69 and 1:1 costs $2.57. Wan 3.0, MiniMax and Omni rows use "any" in the grid, meaning the ratio does not enter the price. Kling 3 is keyed by the audio setting instead of ratio.

What to send

For a vertical product still going to Kling 3, send aspect_ratio: "9:16" with the still as the first frame. For an odd-shaped still going to Seedance or Wan, test adaptive on a 480p draft first; a 480p 5 s Seedance 2.5 draft is $1.35 and a Wan 3.0 one is $0.32. Then run the final at the resolution you need. The field list is on Video generation.

Check it before you run it

Every figure above is a catalog list price times 1.25, rounded up to the cent, as of 2026-10-08. Catalogs change, so before a large batch, read the current model entry in the docs and recompute the one line that matters for your case. Write the arithmetic next to the job in your own notes: list rate, seconds or characters, multiplier, rounding. If the result differs from the wallet charge by more than a cent, the catalog entry has changed, and the docs page is the place to find out why.

Run one small job first. Submit a single request with the pinned model id and the settings in the tables, poll the returned polling_url until it finishes, and compare the charge with your estimate. Then scale up. Using a pinned id for the test matters, because sume/auto never names the family, so you cannot tie its charge to the row you priced.