The Jev Demos
A model that cannot write text has a demo problem. TypeSafe solved it with two games that make latency and cardinality visible rather than tabular.
Jev Doom demo
The Jev Doom demo plays in real time from structured game state — not from pixels. TypeSafe reports roughly 10 queries per second at about $7 per hour of play.
What it demonstrates: Latency low enough for a real-time loop, and a cost per decision small enough that ten calls a second is unremarkable.
Jev Wikiracing demo
Navigate from one Wikipedia article to another by choosing links. Each page offers a long list of candidates, and the model picks from it.
What it demonstrates: High-cardinality choice without fabrication — the model cannot invent a link that is not on the page, which is the whole argument for constrained output.
Why the Jev demos are games
Every launch in the past four years has had the same demo: a chat window, a clever prompt, an impressive paragraph. That option was unavailable to the Jev demo team, because the entire Jev output is a typed value. A screenshot of a filled-in schema is accurate and completely unpersuasive.
Games solve that, which is why both Jev demos are games. The Jev Doom demo makes latency legible in a way that a millisecond figure never will — either the thing keeps up or it visibly does not, and the viewer judges for themselves without needing to trust a benchmark. Ten queries a second is an abstraction; a Jev demo that plays without stuttering is evidence.
The cost figure attached to the Jev Doom demo does similar work. Roughly seven dollars an hour of continuous Jev Doom play, at ten decisions a second, is thirty-six thousand decisions for the price of a sandwich. That is the pricing argument made concrete, and it lands harder than a per-token rate card.
Why the Jev Doom demo uses state, not pixels
One Jev Doom detail is easy to skim past and matters a great deal: the model is not looking at the screen. It receives structured game state — positions, health, what is visible — and returns a decision. The Jev Doom run is not a vision demo, and reading it as one overstates what was shown.
That is consistent with the architecture rather than a shortcut. The whole premise is unstructured state in, typed decisions out, where "unstructured" means the input has no fixed schema, not that it is raw sensor data. A game state blob is exactly the kind of messy, application-specific input the Jev demo is designed to read.
The Jev demos also set the right expectation for your own use. If your pipeline has a perception step, no Jev demo covers it — that step is still yours to solve. What this replaces is the judgement that comes after — given everything you know about this case, which action, which category, which score.
The Jev Wikiracing demo and cardinality
The second Jev demo is quieter and arguably more relevant to real work. The Jev Wikiracing demo means navigating from one Wikipedia article to another using only the links on each page. Every step presents a long list of candidates, and the task is to pick the one that moves you closer.
Ask a language model to do this and you hit a familiar failure: it confidently proposes a link that would be perfect if it existed, and does not. Every hop then needs validation against the actual page, and the retry loop becomes most of your latency budget. A model that selects from the provided list rather than generating a title cannot make that mistake — not because it is better informed, but because inventing an option is not something it can express.
That is the constrained-output argument in its clearest form, and the Jev demo generalises directly. Routing to one of two hundred queues, matching to one of a hundred SKUs, assigning one of fifty policy codes — all the same shape, all prone to the same fabrication problem, all solved the same way. The Jev demo reports cardinality support up to 255 options, implemented with two-stage scoring.
What the Jev demos do not show
Accuracy on anything resembling your data. Both Jev demos are chosen to make speed and constrained choice visible, and they do that well, but neither is an accuracy benchmark. A Jev demo that plays Doom competently tells you the loop keeps up; it tells you nothing about whether the decisions were good ones compared to an alternative.
Calibration is likewise absent. The confidence score is the property most likely to determine whether the model is useful in production, and no Jev demo published so far exposes it. You cannot see, from watching either one, whether a stated 0.9 means anything.
That is not a criticism of the Jev demo choices — a calibration curve makes a terrible launch video. It is a reminder that the demos are an argument about architecture, not evidence about performance, and the evidence still has to come from running it on cases you have labels for.