VideoJev: A Video Model That Answers With a Number Instead of a Sentence

VideoJev is a family of video-understanding models that never writes an answer. Ask it for the timestamp of an event and it returns an interval assembled from scored candidate slots; ask it a multiple-choice question about a video and it returns the option with the highest score. There are two released checkpoints — VideoJev-4B on Qwen3.5-4B and VideoJev-35B-A3B on Qwen3.6-35B-A3B — and they were not launched. Nobody put out a press release. A paper appeared on arXiv on 2026-10-13, weights went up on Hugging Face on 2026-10-10, and the repository was still being tidied four days later: as of 14 October it was getting commits like "Restore inline README video with a public attachment" and "Add arXiv paper link and official BibTeX citation." That is what a quiet ship looks like — the artefacts are real and inspectable, and there is no announcement to tell you what the authors think matters.

Everything below comes from one of three places: the arXiv preprint (2610.18615, cs.CV, submitted 13 October 2026), the model cards and code the authors published, and the paper's own footnotes about how the numbers were measured. I have tried to keep those three clearly separated, because the interesting thing about this release is not the headline number — it is how thin the ground under it is.

What the paper actually claims

VideoJev takes a pretrained multimodal LLM, deletes the final MLP and the language-model output head, and puts a candidate scorer in their place. Two new tokens, <|option_end|> and <|decide|>, produce readouts. The decision state and each candidate state are projected to 512 dimensions, normalised, and dotted together; temporal intervals are scored with a sigmoid and assembled into a span, answer options are scored and normalised with a softmax. Both tasks run through the same head. Nothing is decoded autoregressively, because there is nothing to decode.

The paper's three headline figures, all vendor-reported and all from the authors' own evaluation harness:

• Grounding quality — VideoJev-4B reaches 65.3 mean mIoU across three temporal-grounding benchmarks, 6.7 points above its Qwen3.5-4B backbone. VideoJev-35B-A3B reaches 67.7, 10.8 points above Qwen3.6-35B-A3B.

• QA parity without reasoning — on four video-QA benchmarks the two models sit at 74.3 and 79.5 mean, within 0.6 points below and 0.7 points above their backbones in Thinking mode respectively.

• Latency — 2.8–3.1× faster than those backbones on grounding, and over 100× on QA. The measured figure for QA is 129× at 4B and 100× at 35B-A3B.

The honest framing of the speed claim is that it is a comparison against a reasoning model doing something much harder than the task requires. Qwen3.5-4B in Thinking mode burns 144.9 seconds per question on LVBench to score 74.9; VideoJev-4B spends 1.123 seconds to score 74.3. The 129× is real arithmetic on the paper's own latency table, and it is also the arithmetic you would get from any model that declines to think. The interesting question is not whether the speedup is real — it is whether a system can be built where that trade is correct.

The argument underneath it: decisions, not generations

Where this gets more interesting than a benchmark table is the architectural claim. The authors fine-tuned an ordinary autoregressive Qwen3.5-4B on exactly the same post-training data, in the same single stage, with the same settings, and had it generate intervals or answer letters. Table 3 in the paper says VideoJev-4B beats that control by 1.3 points of mean grounding mIoU and 1.9 points of mean QA score. Both models saw identical supervision; only the readout shape differed.

If that holds, the gain is not data and not scale — it is that asking a model to emit a probability distribution over structured candidates is a better fit for a structured decision than asking it to produce a string and then parsing the string back into a decision. That is the same bet TypeSafe made with Jev 1.13 and its System One family, generalised from text states to video. The paper is explicit that it is building on that line of work rather than inventing the category.

Two implementation details are worth more than the headline numbers, because they are what make it usable rather than merely fast. Cached inference encodes and prefills the video once and lets arriving queries branch from that cached prefix — one forward pass per query. Joint inference puts several queries behind a single video prefix and reads out a separate <|decide|> for each, so a group of questions costs one forward pass total. On ten grounding queries against one video the paper measures 0.39 s for VideoJev versus 5.98 s for an Instruct baseline; on the QA side, ten queries come in at 1.67 s. The paper also checks the obvious failure mode of joint inference — that an earlier question leaks its answer into a later one — and reports that it verified no reference or predicted answers are inserted into the shared prefix. It is worth noting that this is the authors' own verification, and that joint inference scores better than the isolated cached mode (65.3 vs 64.5 mIoU at 4B), which they attribute to training on the same joint layout.

What the card does not tell you

Four things are conspicuously absent, and they matter more than anything above if you are deciding whether this is production-ready.

• Training data is undisclosed. The repo documents the format and gives you the tooling to build your own JSONL, but the corpus, its size and its provenance are not stated. You cannot assess contamination against the seven benchmarks it reports on.

• The 35B weights start at FP32. The project page notes FP32 for Cached inference and BF16 for Joint — so the larger model's headline configuration is the one with the heavier memory footprint, and the page does not give a VRAM figure for either.

• Confidence is overconfident. The paper reports mean calibration error of 8.65 points for 4B and 8.13 for 35B-A3B. The score is a usable ranking signal, not a probability you should branch on without a threshold you have tuned yourself.

• Nobody has run the numbers independently. Every figure here is from the group that trained the models. As of this writing there is no third-party replication, no leaderboard entry and no framework support landed — the inference path is trust_remote_code=True against a custom architecture, requiring PyTorch 2.8/CUDA 12.8 and FlashAttention 2 at minimum.

That last point extends to the smaller model too, and it cuts against the obvious assumption. VideoJev-4B is the one you would expect to run on modest hardware, and the card's own quickstart assumes an H200 at 2 fps with up to 2,048 frames. There is a cheaper demo — a ten-second clip, ten candidate intervals, printed probabilities — but the paper's long-video results use a fixed 262,144-token context with frames capped at 640×640. The 4B is small in parameters, not necessarily in serving cost.

Trying it without betting on it

Because the checkpoints are what actually exist, the low-risk way in is to run VideoJev locally against your own footage before you build anything on it — the demo path is a download and a dozen lines, and the failure cases the paper itself documents (small-object counting on Video-MME, where both sizes miss a four-book answer) are exactly the ones you want to hit on your data rather than on Charades. VideoJev-4B and VideoJev-35B-A3B are Apache-2.0, so nothing stops you.

Where OrcaRouter fits is the other half of the workflow. A video decision interface is rare on its own; what is common is a pipeline that also needs a generative model to write the summary, a cheap classifier to gate the expensive call, and something to route between them. OrcaRouter puts 200+ models behind one API with 0% markup — provider list price passed through, so a vendor price cut is live here the same day — with automatic failover across providers, a routing DSL for composing several models into one call, and model fusion for panels. Neither VideoJev checkpoint is hosted here, and this article is not going to pretend otherwise; the two places it earns its place are as the second leg of a pipeline whose first leg is a local model, and as the reason a research model like this can be tried without a second vendor contract for everything around it.

What would make this a bigger story

The gate on this piece is unusually clean, so it is worth stating plainly: VideoJev is a research release, not a product launch. There is no changelog, no pricing page, no hosted endpoint, no waitlist and no vendor blog post. What exists is a preprint submitted on 13 October 2026, two Apache-2.0 checkpoints uploaded on 10 October, and a repository that was still being edited on 14 October — the day before this article. The absence of an announcement is not evidence of a problem, but it does mean the framing has to be "what the artefacts say," not "what the vendor claims."

Three developments would change the shape of this. A third-party evaluation reproducing the +6.7 and +10.8 mIoU gains against the same backbones under the same protocol. A vLLM or SGLang implementation, which would move it from a trust_remote_code curiosity to something servable at throughput. Or a hosted endpoint from someone, which would make the 100× claim a number you can measure on your own video rather than one you take from a table on page six. Until one of those lands, the useful position is the one the paper itself takes: the direct-scoring interface is a genuinely different way to build a video agent, and the evidence for it is currently one group's nine-page preprint.

Keep the demo notebook open, run it on the least flattering footage you have, and treat the confidence scores as a ranking until you have calibrated them yourself.

A release is also the moment to check what has gone wrong before: the documented AI incidents and agent failures around models in this class are collected in the OrcaRouter AI Incident Archive , where each entry carries its own sources, severity, confidence grade and disputed flag.