Skip to main content
Models that accept video take it inside a chat message, next to your text, the same way vision models take an image. Pass a list of content parts instead of a plain string: one text part and one video_url part. The model watches the video and answers in text. Not every model can do this. A model accepts video when video is in its input_modalities on GET /v1/models (see model discovery). The first model that does is MiniMax-M3.1-Flash. A model that reads images does not necessarily read video, so check the list rather than assuming.

Example

Video sources

The video_url.url field accepts either a public http(s) URL or a base64 data URL. Use a data URL when the video isn’t already hosted somewhere. Any other scheme, such as file:// or ftp://, is refused with a 400.
Python
The gateway does not download your video itself: the model’s serving engine fetches the URL or decodes the data URL. That is why a URL it can’t reach comes back as an error rather than being retried for you (see Errors).

Limits

These are the limits on MiniMax-M3.1-Flash. Other video models may differ, so treat this table as that model’s, not the API’s. The gateway does not count the videos in your request. The per-request limit is set by the model’s serving engine, and a request with more videos than that comes back as the engine’s 400. A longer video is sampled into more frames and so uses more of the model’s context window. One video can add up to roughly 195,000 prompt tokens, so a long clip leaves less room for your text and for the answer.

Usage accounting

Video is billed as prompt tokens, the same way image tokens are. The usage block in the response includes the tokens the video was encoded into in prompt_tokens, and there is no separate per-video or per-second charge for video input (video generation is a different product, priced per second of output). Before a request runs, the gateway reserves credit for the largest the video could cost, then settles to the real usage when the request finishes. A balance below that reservation is refused with a 402 before any GPU time is spent; see Errors.

Errors

  • Model doesn’t accept video. Send a video_url part to a model whose input_modalities doesn’t list video and you get a 400 naming the model, before anything runs and without a charge. Pick a model from the discovery list that does list it.
  • Unsupported URL scheme. Anything other than http://, https:// or data: is a 400 on messages[i].content[j].video_url.
  • Unfetchable or undecodable video. A video that times out, a response that isn’t a video we can decode, or a video over the size limit comes back as a 400 that starts The provided video_url could not be fetched or decoded. A host that can’t be reached at all (a DNS or connection failure) can come back as a plain 400 Invalid request. instead, the same as for an unreachable image_url. Either way, check that the URL is public, returns a video file, and is within the limits above. Genuine gateway failures on a video request still return 5xx, so treat these 400s as “fix the video”.
  • Too many videos. More videos than the model’s engine allows per request (see Limits) is the engine’s own 400, not a gateway message.
Each of these is documented with its exact response body in the error reference.