262,144-token context · 32k max output · full-rate 2 fps
native video · zero data retention · OpenAI-compatible API ·
pricing · served as Qwen/Qwen3.8-27B
Set chat_template_kwargs.reasoning_effort to low, medium, or xhigh (the default). high is accepted as an alias for xhigh and uses the same reasoning budget. The top-level reasoning_effort field accepts the same alias. See the API parameters.
Their p50s are text-dominated traffic (OpenRouter published stats); ours is measured on full-rate video with thinking enabled — the hardest case we serve. Both sides refresh nightly.
Time to first token. Theirs is OpenRouter's published p50 on text traffic; ours is measured nightly on a short clip, so it carries a video's prefill and theirs does not. Read it with the scaling plot: most of these endpoints get faster on long clips by reading less of them.
| input | video tokens | TTFT |
|---|---|---|
| 4 s clip | 931 tokens | 0.47 s |
| 10 s clip | 2,299 tokens | 0.82 s |
| 60 s clip | 13,749 tokens | 2.97 s |
| 600 s clip | 137,909 tokens | 23.44 s |
The same clip ladder sent to us and to every other OpenRouter provider of this model, re-measured weekly. The top plot is the one that matters: video tokens ingested. Ours climbs with the clip, because we tokenize every frame at 2 fps. Most others flatten — they do not refuse a long video, they accept it, silently sample a fraction of the frames and answer confidently about footage they never saw. A flattened line is drawn dashed from the length where it stops keeping up, with a dotted marker showing where full rate would have put it.
Which is why time-to-first-token below must be read together with the plot above, never on its own: a provider that drops nine frames in ten answers faster. Being slower on a long clip is the cost of having read it.
Video becomes prompt tokens. At 2 fps the processor merges frame
pairs into one temporal frame per second, and each contributes (H∕32)×(W∕32)
tokens — ~220 at the 640×360 presentation, ≈229 tok/s with the per-second
timestamp. A whole-clip pixel budget,
size.longest_edge = 351,462,400 (T·H·W, sized as 1,560 frames ×
640×352), keeps presentation clips at native resolution across the whole
contract; oversized inputs are downscaled together, so tokens plateau at ~160k
rather than overflow — served at reduced resolution, never refused.
| knob | recommended | why |
|---|---|---|
| resolution | ≤ 640×360 | ~220 tokens/temporal-frame; larger input is downscaled past the budget |
| clip length | ≤ 13 min (1,560 frames) | full-rate 2 fps to 780 s; longer clips sample sparser |
| longest_edge | 351,462,400 | whole-video T·H·W budget; video plateaus at ~160k tokens |
| context | 262,144 tokens | ~80k left for prompt + full 32k output at the video plateau |
Measured, not theoretical: a maximum-size 13-minute clip serves at 160,584 prompt tokens in ~137 s cold / ~86 s warm, and back-to-back maximum-size requests are stable.
Measured against every other OpenRouter provider of this model, not asserted: five of eight silently cap what they ingest — four at ~14.6k video tokens and one at ~3.7k — so a ten-minute clip reaches them as 3–10% of its frames, with a 200 and no indication that the rest was dropped. One ingests at full rate but refuses a ten-minute clip outright, and one refuses video entirely. At ten minutes we are the only endpoint still tokenizing every frame, and we retain nothing.
Charts are drawn from a snapshot the nightly canary measures against this endpoint's public API, paired with what OpenRouter publishes for the other providers of this model. Each carries the date it was taken. The clip ladder is re-measured weekly.