Which aspect_ratio values do Sume video models list: 9:16 and 16:9

The Sume docs name two aspect_ratio values on the video routes: 9:16 and 16:9. Video Router Auto and gemini-omni-flash-1.1 list both, and the other catalog models can differ, so read capabilities from GET /v1/video-router/models before you send a value.

What the docs say

The Video Router docs say limits are different for each model and tell you to read capabilities from the catalog, because each model can have a different envelope. The same page shows a seedance-2.5 request with aspect_ratio: "9:16". The Video generation docs describe the Auto path with model: "sume/auto", which defaults to 720p and 8 seconds with 3 to 10 second clips at 16:9 or 9:16.

What the platforms list

Two platform pages ask for the same shapes. TikTok's in-feed ad page (read 2026-10-05) lists 9:16 at 540x960 or larger, 16:9 at 960x540 or larger and 1:1 at 640x640 or larger. Meta's Reels ad page (read 2026-10-05) lists 9:16 only.

What that means for you

So for a Reels ad or a vertical TikTok, the value you want is 9:16, and both of the models named above accept it. For a square TikTok ad, 1:1 is on TikTok's page, but I did not see 1:1 on the Sume video route pages I read, so for a square file you would reframe a 9:16 or 16:9 result instead of asking for it.

Read the envelope

Ask the catalog, not memory. The catalog has a list route and a per-model route:

curl https://api.sume.com/v1/video-router/models \
  -H "Authorization: Bearer $SUME_API_KEY"

curl https://api.sume.com/v1/video-router/models/seedance-2.5 \
  -H "Authorization: Bearer $SUME_API_KEY"

Why read it in code

The response lists capabilities for the model. A script that reads this before it builds a request cannot send a ratio the model does not list, which turns a rejected job into a check at the start of the script.

Edits keep the source shape

An edit is different from a new generation. For gemini-omni-flash-1.1 video_to_video, the docs say you send video_url and a prompt, and you do not send aspect_ratio or duration. The edit keeps the shape of the source. So if your source is 16:9 and you need 9:16, edit is not the way to reframe it.

Keep the ratio in one place

Two habits make this less error-prone. First, put the ratio in one place in your code, as a constant, so a campaign that switches from 16:9 to 9:16 changes one line. Second, store the ratio next to the job id of every clip you generate. When you review results later, the ratio is part of the record, and you do not have to open the file to know what you asked for.

When to pin a model

Auto is a reasonable starting point if you do not yet know which model you want. The docs describe Video Router Auto as the recommended path for new integrations, through POST /v1/videos with model: "sume/auto". Its controls default to 720p and 8 seconds, with 3 to 10 second clips at 16:9 or 9:16. When you need a longer clip, or a specific model's look, pin a catalog model on Video Router instead, and use the 4 to 30 second range of seedance-2.5 or the 2 to 30 second range of wan-3.0.

Ratio is not the whole spec

Last, a vertical file made by a model is only the start. The platform pages also list minimum pixel sizes, bitrates and file types, and those are about the file, not the ratio. A 9:16 request does not by itself tell you the pixel size you will get back, so probe the file and compare it to the page for the placement you plan to use.

Test with one request

If you are unsure whether a model accepts a ratio, send one short request at the lowest resolution it lists and read the answer. A refusal comes back fast and tells you what the model allows, and a success gives you a cheap clip to inspect. Either result is better than building a whole batch on a guess.

The takeaway

Send 9:16 for vertical, read the catalog before you hard-code any other value, and measure the file you get back with video inspect.