List Seedance and Kling ids, lengths and inputs from one API call

To see which Seedance and Kling models Sume offers right now, call GET /v1/videos/models and filter the data array on the id. Each row carries the supported durations, resolutions, aspect ratios, frame images and input reference types, so a short script answers the length and input questions without reading a blog post (including this one).

This matters this month because the catalog moves: Seedance 2.5 is listed with a 4 to 30 second range while other rows stop at 15, and a new Kling generation is expected to arrive. A script that reads the live catalog stays correct when a page you bookmarked does not.

What does the models endpoint return for each model?

The video generation docs show the descriptor: id, name, supported_resolutions, supported_aspect_ratios, supported_durations, supported_frame_images, supported_input_references, generate_audio, seed and pricing_skus. Use the dedicated video endpoint rather than the general model catalog, because these are the fields the generation request is validated against.

Limits are not uniform across the catalog. The docs say seedance-2.5 accepts 4 to 30 seconds at 480p, 720p and 1080p, and that every other catalog model tops out at 15 seconds except the few that are named (such as wan-3.0 at 2 to 30). They also say seedance-2 offers 1080p and that audio and video references are honored by the Seedance 2.x models.

What does the script look like?

The script below uses only the standard library, so it runs as is. It prints one line per Seedance or Kling row and sets a non-zero exit status if any id starts with kling-4, which makes it usable in a scheduled job that tells you when a new Kling generation shows up.

import json, os, sys, urllib.request

req = urllib.request.Request(
    "https://api.sume.com/v1/videos/models",
    headers={"Authorization": "Bearer " + os.environ["SUME_API_KEY"]},
)
with urllib.request.urlopen(req, timeout=30) as resp:
    models = json.load(resp)["data"]

found_kling_4 = False
for m in models:
    mid = m["id"]
    if not mid.startswith(("seedance", "kling")):
        continue
    d = m.get("supported_durations") or []
    span = f"{min(d)}-{max(d)}s" if d else "n/a"
    refs = ",".join(m.get("supported_input_references") or []) or "none"
    frames = ",".join(m.get("supported_frame_images") or []) or "none"
    res = ",".join(m.get("supported_resolutions") or [])
    print(f"{mid:18} {span:8} res={res} refs={refs} frames={frames} audio={m.get('generate_audio')}")
    if mid.startswith("kling-4"):
        found_kling_4 = True

sys.exit(1 if found_kling_4 else 0)

What should you do when a kling-4 id appears?

Do not assume it behaves like kling-3. Read its row: the durations, whether it lists image_url, video_url or audio_url references, and whether generate_audio is true. Then send a 480p or 720p test clip before moving production traffic. Sume's catalog, not a vendor announcement, decides what you can request.

Until a row exists, requesting an unlisted id fails. The docs note that ids not in the catalog are rejected on generate, and that Sume uses bare ids such as kling-3 and not org/slug names. If you do not want to pin an id at all, sume/auto lets Sume pick, but it never says which family ran, so it is the wrong tool when you need a specific Kling or Seedance behavior.

What does the endpoint not tell you?

It does not tell you price per second in plain dollars: pricing_skus carries a provider list SKU (for example a per-1000-video-tokens value on Seedance rows) and Sume bills list times 1.25 on every model. It does not rank quality, and it does not list models you are not entitled to see. For billing detail, read usage.cost on a finished job; for the full model comparison, use the Seedance and Kling pages in this blog.

The Video Router route, GET /v1/video-router/models, returns the same ids in Sume's own envelope with capabilities, and the docs recommend reading those rather than assuming one envelope. New code should prefer /v1/videos/models, which the Video Router docs describe as the same catalog behind an OpenRouter-compatible wire.

A simple way to run the script is a daily scheduled job that mails you only when the exit status is non-zero. Keep the output of a normal run in a file too, and diff it against yesterday's: a changed supported_durations list or a new supported_input_references entry is as interesting as a new id, because limits move without a new model name.