Check a new Sume video model against your clip spec before you pay

To find out whether a newly launched video model fits your pipeline, read its entry in GET /v1/videos/models and compare four fields to your clip spec: supported_durations, supported_resolutions, supported_aspect_ratios, and supported_input_references. No job is submitted and nothing is reserved, so the check costs nothing. The Python below returns a list of problems, and an empty list means the model accepts the spec.

Limits differ by model, and Sume's docs say so directly: seedance-2.5 accepts 4 to 30 seconds, wan-3.0 accepts 2 to 30, minimax-h3 accepts 5 to 15, and gemini-omni-flash-1.1 accepts 3 to 10. A pipeline built around 12-second clips fits three of those four and fails the fourth.

The fields to read

Reference types differ as well. The Seedance 2.x models, Wan 3.0, MiniMax H3, and MiniMax H3 Max accept audio and video references. Gemini Omni Flash 1.1, higgsfield-genjutsu, and h3-max-recast accept video references but not audio.

The check

Run it with SUME_API_KEY set and uncomment the last line to read the live catalog. As written it uses a sample entry shaped like the one in Sume's docs, so the file prints a result offline: a 20-second clip is outside 4 to 15 seconds, and audio references are not in the sample's list.

import json, os, urllib.request

def fetch_models():
    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=20) as r:
        return {m["id"]: m for m in json.load(r)["data"]}

def problems(m, seconds, resolution, ratio, refs=()):
    out = []
    if seconds not in m["supported_durations"]:
        out.append(f"duration {seconds} not in {m['supported_durations']}")
    if resolution not in m["supported_resolutions"]:
        out.append(f"resolution {resolution} not supported")
    if ratio not in m["supported_aspect_ratios"]:
        out.append(f"aspect ratio {ratio} not supported")
    for kind in refs:
        if kind not in m["supported_input_references"]:
            out.append(f"{kind} references not accepted")
    return out

sample = {"supported_durations": list(range(4, 16)), "supported_resolutions": ["480p", "720p", "1080p"],
          "supported_aspect_ratios": ["16:9", "9:16"], "supported_input_references": ["image_url", "video_url"]}
print(problems(sample, 20, "1080p", "9:16", refs=("audio_url",)))
# live: print(problems(fetch_models()["seedance-2.5"], 12, "720p", "9:16"))

What the check cannot tell you

Run the check in CI on a schedule, not only on launch day. A failing check on a Tuesday morning is a cheap way to learn that a model changed its limits.

• Whether the output looks right. Run one cheap, short test clip for that.
• Price. Each catalog entry has pricing_skus, and Sume bills the provider list price times 1.25. Read the live number before you plan a batch.
• Whether your key can call the model today. A model appears in the catalog only when its provider is configured, as the docs note for higgsfield-genjutsu.

After the check passes

Submit one job with an Idempotency-Key that includes the model id, then poll about every 30 seconds. Video generation usually takes from 30 seconds to several minutes depending on model and parameters. When the job is completed, download from unsigned_urls[0] with your API key in the header.

Wiring it into a launch routine

Keep your clip spec in one small dictionary: seconds, resolution, aspect ratio, and the references you plan to send. Run the check against every model id you might route to, not only the new one. The output is a table of model ids and problems, and it tells you in one run which models can serve as fallbacks and which cannot.

Treat the result as advice about the catalog, not a promise about a job. The catalog describes what the API accepts. A request that passes the check can still fail for reasons the catalog does not list, such as a prompt a provider refuses. Read the error object of a failed job and its request id when that happens.

When a launch adds a model, add its id to the list, rerun, and read the diff. A model that fails only on duration may still be worth using if you can trim the clip.