Methodology

How we measure

Every number on this site comes from requests we sent to the provider's OpenAI-compatible chat completions API. The current data was measured on 2026-10-31.

One limit at a time

A real video request can hit several limits at once: the image count, the request size, the decoded pixels, the context window. To tell them apart, each probe sends a minimal request ("Reply with OK", 16 output tokens) carrying synthetic media designed to stress only one of them:

• Images per request: tiny 64×64 solid images, so bytes and pixels stay negligible and only the count grows.
• 768×432 frames: real-size frames. 768 px on the long edge is a common working size for video pipelines (providers tile or rescale images around it), and 432 px makes it 16:9, the shape of most video. This reports whichever limit a realistic workload hits first. Limits on pixels and tokens scale with frame size: 1280×720 frames would fit about 2.8× fewer; image-count limits don't change.
• Inline request body: tiny images padded with JPEG comment segments, which decoders ignore. The body grows; the pixels don't.
• Images by URL: the same padded images, hosted and sent as https links, so the provider downloads them itself.
• Video file size: a 5-second clip padded with an MP4 free box, which players ignore. The file grows; the content doesn't.

For each limit we double the size until a request fails, then bisect between the last pass and the first failure. We also check which request fields are accepted, and whether tool results for parallel tool calls must directly follow the assistant message.

Video density: how much of a video the model sees

Sending a video doesn't tell you how much of it reaches the model. Providers sample frames themselves, and for the same model id the amount differs by more than 100×. To measure it we send one real reference clip (5 minutes 8 seconds) as a video_url, twice, and read the provider's own billing:

• Video tokens per minute = prompt tokens with the video − prompt tokens for the same prompt without it, divided by the clip's length. This is exact and works for any model.
• ≈ frames per minute divides by the model's tokens per video frame. We only show it where that is documented: Qwen3-VL family ~169 (338 per 768×432 frame, halved by its 2× temporal merge) and Gemini 66 (its default media resolution). Gemini comes out at exactly 60, its documented 1 frame per second.
• Ignored means the provider accepted the video with HTTP 200, but it added no tokens: the model never saw it.
• Some providers reject the 40 MB original for size. They get the same clip re-encoded to 360p (under 10 MB), and the result says so. For Gemini this doesn't change the number; for token-per-pixel models it may.

OpenRouter upstreams

OpenRouter serves one model id from many upstream providers and picks one per request. We pin each upstream in turn (provider.order with fallbacks off) and measure it separately. When a pinned upstream can't take a request, OpenRouter answers "no endpoints found"; after smaller requests passed, we treat that as the upstream's limit.

Evidence

Every request and response is recorded: the request body (images replaced by their SHA-256 and size), the status, headers and body, timings, and the provider's request id (OpenRouter's X-Generation-Id, or x-request-id / cf-ray). That lets a provider look up the exact request behind any number here.

Reading a value

• A number is the largest request that passed. The first size that failed, and the provider's error text, are in the tooltip and on the model page.
• ≥ a number means nothing failed up to our probe's cap (16 MB inline, 128 MB by URL, 512 MB video, 384 frames). The real limit is higher.
• ? means the search stopped on a timeout or a transient error, so the limit is unknown.
• No video means a video_url was rejected or couldn't be routed. Ignored means it was accepted but never reached the model.

Caveats

• Limits change. Providers update deployments without notice. Check the date, and leave headroom.
• Limits can depend on your account. Plan, region, or a bring-your-own-key setup may change them.
• Inline sizes depend on upload speed. Some gateways give up if the body takes too long to arrive, so very large inline requests are capped by bandwidth as much as by the provider.
• OpenRouter results are per upstream. We pin each route to one upstream provider. Auto-routed requests can land on providers with different limits.
• Compatibility, not quality. These numbers say what a provider accepts, not how well the model understands it.

What's not here

Self-hosted deployments (for example your own vLLM server) are left out: their limits are set by your configuration, such as --limit-mm-per-prompt and VLLM_MAX_MEDIA_REQUEST_DECODE_BYTES.

Corrections

Found a limit that's wrong or out of date? Open an issue with the request you sent and the error you got.