Know the day Sume lists a new video model: a catalog check script

The reliable way to know when Sume lists a new video model is to read GET /v1/videos/models with your own key and search the returned ids and names. The script below does that in under 20 lines and exits non-zero when a term is missing, so cron or CI can alert you when it flips.

Do not infer Sume's catalog from a vendor's launch page. Vendor launches and Sume listings are separate events.

Why a vendor launch is not a Sume listing

This week xAI's documentation lists a Lite tier of Grok Imagine video next to the 1.5 model, and Vidu's site describes Q4 with native audio (both read 2026-10-10). Sume's API registry has neither a Grok Lite id nor a Vidu id; its Grok row is grok-imagine-video-1.5.

Sume's catalog can also differ between workspaces and environments. The Veo and Tencent rows are behind environment switches, so they show up only where those switches are on. That is why you should query your own key, not read a doc and assume.

The script

The endpoint returns a data array, and each entry has id, name, supported_durations, supported_resolutions and more, per the Video Generation docs. The script matches search terms against the id and name, case-insensitively, so vidu finds vidu-q4 and any later variant.

It prints the durations and resolutions for every hit, which is the first thing you need when deciding whether a new row fits your pipeline.

import os, sys, requests

terms = sys.argv[1:] or ["vidu", "lite", "happyhorse", "ltx"]
r = requests.get(
    "https://api.sume.com/v1/videos/models",
    headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"},
    timeout=30,
)
r.raise_for_status()
models = r.json()["data"]
missing = 0
for term in terms:
    hits = [m for m in models
            if term.lower() in f"{m['id']} {m.get('name', '')}".lower()]
    if not hits:
        print(f"{term}: not listed")
        missing += 1
    for m in hits:
        print(f"{term}: {m['id']}",
              m.get("supported_durations"), m.get("supported_resolutions"))
sys.exit(1 if missing else 0)

Running it on a schedule

Run it daily from cron or a CI schedule. A non-zero exit means at least one term is still unlisted; once the exit is zero, all your terms have a hit. Pass only the terms you care about, since a broad term such as lite can match unrelated rows, for example a Veo Lite or WAND-Vega Lite entry where those are listed.

Store the previous output and diff it. A change in supported_durations for an existing id matters as much as a new id, because limits differ per model: Seedance 2.5 and Wan 3.0 list up to 30 seconds, Gemini Omni Flash 1.1 lists 3 to 10.

• Terms are substrings, so keep them specific.
• A 401 means the key is wrong; a 429 means back off, per the Errors and rate limits page.
• The legacy GET /v1/video-router/models returns the same model vocabulary in the older envelope.

What to do when a row appears

When your term finally hits, do three checks before you route traffic. First, read the row's supported_input_references and supported_frame_images to see which inputs it takes. Second, read pricing_skus and estimate one real clip. Third, submit one short test job with an Idempotency-Key and compare usage.cost with your estimate.

If the row is gated by an environment switch in some workspaces, you may see it in one key and not in another. Test with the key you will run in production. The Errors and rate limits page lists the status codes you may meet while testing, such as 402 when the balance is short.

Alerting without noise

A plain exit code is enough for a first version. In CI, fail the scheduled job when the exit is non-zero for a term you expect to appear soon, and ignore it for terms you only watch. In cron, mail the output only when it changes from the last run, so you hear about a listing once rather than every day.

Keep the key in a secret store and pass it as SUME_API_KEY. The script reads only the catalog, so a key with no spending on it is enough, and the call does not create a job or reserve any balance.