Jev Doom

Doom from structured text

The launch post's Doom demo feeds a text description of the game state. Jev does not see the framebuffer. At about 10 queries per second the cost lands around $7 per hour on the published input price, with output tokens free. That rate is a demo figure, not a required production QPS. The point is that a 70ms-500ms decision model can sit in a loop that used to wait on a slow generative call.

Build the state from whatever your engine already knows: health, visible entities, objectives. Ask Nouls and Choices that a planner can consume — should I shoot, which door, is this item useful — and keep movement math in the engine. If you find yourself asking Jev to count ammo, you have hit the math jagged edge. Count in code; ask Jev whether the current tactic still fits the goal.

The same loop applies to other simulations. Cloudflare's typesafe/jev listing is a catalog entry for workers, not a Doom host. There is no Steam app. Run the bot against api.typesafe.ai with jev-latest pinned or with jev-1.13.0 if you have tuned the gates.

Wikiracing over high cardinality

Wikiracing chooses the next Wikipedia link toward a target page. Cardinality runs from hundreds to thousands of links. A single Choice only accepts 255 options, so the demo scores first, then chooses among a shortlist. That two-stage pattern is the practical answer whenever a catalog is larger than the Choice cap.

Stage one: Score or Noul each candidate, or score batches, for "how useful is this link toward the target." Stage two: Choice over the top K names. Your code owns K, the sort, and the visit. Jev never has to emit the URL as generated text. If a page has 40 links, one Choice is enough. If it has 800, do not raise maxOptions in your head — the cap is 255.

Keep the page text in state, not the entire dump of every linked article. Large state full of irrelevant detail is a listed failure mode. Send the current page summary plus the candidate titles. Extract dates or counts in code if the race depends on them.

Smart home fan-out and where Jev runs

The official smart-home assistant demo evaluates each user request against a long list of questions, including many that will be irrelevant for most utterances. "Turn off all of the lights in the house" still asks category, domain, device, and action in one call. The action question is speculative: it assumes lights before that fact is known. Code keeps the answers that match and ignores the rest. Sequential API calls would wait to ask action only after device is known and would lose the latency win.

TypeSafe embeds a Loom walkthrough on the demo doc. Watch that recording on docs.typesafe.ai/demos/smart-home rather than a copy here. Pair the pattern with confidence-gated routing so a low-confidence device Choice does not flip a real switch. Confirm high-stakes actions in your home controller, not in Jev's payload.

Jev runs as an API: TypeSafe console, HTTP, and official SDKs. YouTube's Typesafe AI channel has no uploads yet, so there is no official YouTube trailer to facade. Instagram is typesafeai. Discord invite WUujKYBp8s. GitHub org typesafe-ai. Early-access legal terms say customer data is not used for training. If you need a public race number, TypeSafe's homepage cites 193.6x faster and 444.6x cheaper on four workflow evals versus Astra and Fable averages.

Workflow evals beside the demos

evals.typesafe.ai shows workflow families TypeSafe uses in public comparisons: Security Incidents, Agent Trace Observability, Invoice Processing, and Customer Service. The homepage 193.6x / 444.6x figures are averages against Astra and Fable on those families, not a live meter on your traffic.

Use the evals viewer to see how a System One path can sit next to chat and reasoning models on the same job. Jev still only returns typed answers. The eval harness is TypeSafe's, not a third benchmark this site re-ran.

When you build your own demo, keep the three official loops in mind: a tight text state at about 10 Hz (Doom), a cardinality problem over the 255 Choice cap (Wikiracing), and a speculative question map (smart home). Those are the shapes TypeSafe actually shipped, and they all refuse pixels as input.

Rebuild a demo only if you can name which of the three loops it is. Text state at a few queries per second, a catalog larger than 255, or a speculative question map. If your demo needs frames, you are not demoing Jev 1.13 yet.

Cost math for Doom uses the public input price and free output. Ten queries per second is a demo rate, not a quota. Stay inside 1,200 RPM and 250,000 tokens per second unless sales has raised your cap. The $7/hour figure is TypeSafe's illustration, not an invoice from this wiki.

Link out to the launch post for Doom and Wikiracing, and to the smart-home doc for the fan-out walkthrough. This page is the field guide; those pages are the first-party recordings.

The homepage video is the public recording. Doom, Wikiracing, and smart home are the three loops that recording is meant to sell.