Same video model, different limits: OpenRouter vs Sume rows

Yes, a model with the same name can accept different durations and resolutions on OpenRouter and on Sume, and for eight of the ten pairs below it does. Kling v3 Pro, Hailuo 3 Max, Grok Imagine Video 1.5, the Seedance 2.x rows and the Veo rows differ, while Wan 3.0 and Seedance 2.0 Mini match.

The OpenRouter figures come from its video models listing, read on 2026-10-11. The Sume figures come from the catalog code on main and the Video Generation docs. Neither side is a promise about your key: Sume's catalog is read per request at GET /v1/videos/models.

Where do the limits differ?

Durations are whole seconds on both sides. Resolutions are the tiers each side names. Where Sume lists a tier OpenRouter's listing does not, that does not prove the upstream model lacks it; it only shows what each catalog accepts.

Which differences break a ported request?

Three kinds matter in practice. First, a floor: Kling asks for at least 3 seconds on OpenRouter and 4 on Sume, and Grok drops from 1 to 4. A 2-second clip that worked before is rejected.

Second, a ceiling on resolution. Sume's Veo rows stop at 720p in the catalog code, which the code comment ties to the one mode that was proven, and they offer no image, reference or last-frame input. A 1080p or 4K Veo request has no equivalent.

Third, a mode. The Grok row on Sume needs image_url or a first frame and offers no text-to-video, no end frame and no aspect_ratio. Kling on Sume renders 1080p only; a 720p request from an older caller is still accepted but renders 1080p, according to the catalog notes.

What about the rows that match?

Wan 3.0 and Seedance 2.0 Mini match on both numbers, which makes them the lowest-risk swaps. Seedance 2.5 is a superset on Sume at the resolution tier. Billing is a separate question: Sume reserves the provider list price times 1.25 at submit, per the docs, so the same clip is priced differently even where limits agree, and usage.cost on the finished job is the figure to log.

Which swap should you test first?

Start with the pair where the numbers match and the model is the same, then move to the ones that differ only by an extra tier on Sume. For a Seedance 2.5 or MiniMax H3 Max workload, the extra Sume tier is optional: a request that stays inside the OpenRouter limits is also inside Sume's. For Kling, Grok and Veo, the Sume limits are narrower in at least one direction, so those need a changed request, not just a changed base URL.

Run one clip per row at the shortest duration and the lowest resolution your product ships. That keeps the test cheap, and it exercises the same field checks as a full batch. Then compare the supported_durations and supported_resolutions arrays on the Sume row with your request, which is what the script in the next section does.

A pre-flight check that reads both sides

Before a port, read each row's supported_durations and supported_resolutions from Sume and compare them with the request you used to send. The check below prints any duration or resolution that a model in your config would no longer accept.

A mismatch is a 400, not a silent clamp, so catching it in CI is cheaper than discovering it in a batch. The first post in this pair, which of OpenRouter's 26 ids have a Sume id, covers the rows that have no Sume twin at all.

import os, requests

WANT = {"kling-3": (3, "720p"), "grok-imagine-video-1.5": (1, "1080p")}
r = requests.get("https://api.sume.com/v1/videos/models",
    headers={"Authorization": "Bearer " + os.environ["SUME_API_KEY"]}, timeout=30)
r.raise_for_status()
rows = {m["id"]: m for m in r.json()["data"]}
for mid, (secs, res) in WANT.items():
    m = rows.get(mid)
    if m is None:
        print(mid, "not listed for this key")
        continue
    if secs not in m["supported_durations"]:
        print(mid, secs, "s not accepted")
    if res not in m["supported_resolutions"]:
        print(mid, res, "not accepted")