Read capabilities from the Video Router models list before you pin

The Video Router page ends its limits paragraph with an instruction: read capabilities from GET /v1/video-router/models rather than assuming one envelope. That is good advice because the catalog's models do not share one request shape. Durations, resolutions, ratios and input types differ per model, and the docs list differences as large as a 2-second minimum on one model and a 30-second maximum on another.

This post turns that instruction into a short routine you can run before you pin a model id in code.

How the limits differ

The numbers below are quoted from the Video Router page on 2026-10-03. They show why a single hard-coded envelope breaks.

A routine before you pin

First, call the models list and find your id. If you only need one model, GET /v1/video-router/models/{model_id} returns its row. Second, compare your intended request against that row: duration inside the range, resolution in the list, and any reference types the model supports. Third, fail in your own code with a clear message when the request does not fit, rather than discovering it as a 400 after your retry wrapper has already queued the job.

Gemini Omni Flash 1.1 shows why this matters. One id is routed by the shape of the request: text, image, reference or edit. In edit mode (video_to_video) you send video_url and a prompt, resolution is optional with a 720p default, and aspect_ratio and duration are not accepted. The same model id therefore has different rules in different modes.

What the legacy route still does

New integrations should use POST /v1/videos, which is the same catalog and the same jobs behind an OpenRouter-compatible wire. Video Router stays available and unchanged. The two routes share model ids, so reading capabilities from either list is valid. Use the Video Models list on the new route for the OpenRouter-shaped fields, and the Video Router list when you need the capability names.

Reading one model instead of the list

If you pin one model, fetch its row by id and cache it with a short lifetime, for example a day. Refresh on a deploy and when a submit returns an unexpected 400. That is cheaper than reading the full list on every request and still catches a change before your users do.

Log which fields you checked when you rejected a request locally. Over a few weeks that log tells you which limits your users hit most often, which is a better guide for product copy than any table.

Limits

This post does not reproduce the full model catalog, because it changes. Treat the table as a snapshot from one date, and read the live list before you ship a hard-coded value.