Jev in 10 Minutes: What a Fast Decision Model Is, and When It Is Worth Using

You see a red light and your foot is already on the brake. Nobody spends an hour on that. Deciding whether to change jobs is different: you take days, write out the pros and cons, ask people you trust. People get both kinds of decision right because they use each mode where it fits. Deliberate carefully at a red light and you crash.

Many AI agents today deliberate at every red light. Is this support ticket urgent? Which team should get it? Does this tool call look safe? Each of those small judgments often goes to the same large model that writes code, as a full generated answer. That is slow and expensive for a question with four possible answers.

Jev, which TypeSafe released on September 15, is built for the fast mode. Its documentation puts it plainly: "System One models are built for fast, focused judgments. Ask for a judgment a knowledgeable person makes in a second given the right context."

What Jev does

You send a state, the thing being judged, often a JSON object holding a conversation or a record, and a set of typed questions. There are three types:

Yes or no (Jev calls it noul): returns the probability that the answer is yes.
Choice: returns a probability for every option. TypeSafe says a choice can have up to 255 options, and an independent test found requests with 256 or more fail.
Score: returns a probability for each level of an ordered scale.

It returns no text, so there is nothing to parse and no answer can fall outside the options. TypeSafe's launch post puts the end-to-end response time at 70 to 500 ms.

The probabilities are the useful part. They let you act on the answers the model is sure of and hand only the unsure ones to a slower, more capable model.

A request goes to a fast decision model that returns a probability per option. Confident answers are acted on immediately; unsure ones are handed to a large, slower model.

How a model answers without writing

TypeSafe describes Jev's internals only in outline: "a new model architecture, parallel sampler for maximum efficiency, and training method we call Reinforcement Learning for Calibrated Decisions (RLCD)", with all outputs generated in a single query. The details are not public. Open-source projects that offer the same kind of interface do it in two ways.

A classifier head on an encoder. laya reads the state and the options together with a 421M ModernBERT encoder and scores every option in one forward pass. It calls its own training method RLCD as well.
A one-step read from a diffusion language model. A vLLM pull request writes the answer template onto DiffusionGemma's canvas, leaves one slot blank, runs one denoising step and reads the probability of each label in that slot. openjev wraps this in a Jev-compatible API.

Both answered in 23 to 120 ms per request on one GPU in my runs (DiffusionGemma with one noise draw), because neither generates text token by token.

What happened when I measured it

Over three posts I ran these on public datasets labelled by people, one request at a time on one A100. I do not have Jev access, so Jev's own figures below come from other people's tests on other samples.

Two bar charts. On TREC with 6 options, laya 86.6%, openjev 66.0%, trained classifier 90.4%. On BANKING77 with 77 options, laya 37.0%, openjev 66.9%, trained classifier 90.3%, and a dashed line for Jev at 76.3% from a third-party test on a different sample.

Three things stood out.

The number of options decides the winner. On TREC, where each question has six possible types, laya answered 86.6% correctly in 23 ms, although TREC is not in its published training data. On BANKING77, with 77 banking intents, the same model fell to 37.0%: its input gives all the options one shared token budget, and 77 labels squeeze each other out. (The two fixes its documentation recommends help: a 512-token budget reached 46.1%, and cutting the list to 20 candidates with an embedding model first reached 59.1%.) The DiffusionGemma-based openjev was the best open option there, at 66.9%. (Details)

The labels are part of the prompt. With bare label names, DiffusionGemma answered almost none of TREC's "human" questions correctly; it read human too literally. Adding one line of description per label moved the vLLM example server by 20 points and openjev by 14. The wording around it matters too: one added sentence of context took the example server from 54.5% to 31.8% on BANKING77. (Labels, context sentence)

A small trained classifier is hard to beat. Sentence embeddings plus a logistic regression, trained on the dataset's own labelled examples, reached about 90% on both tasks in under 10 ms on a CPU. On 77 options it beat every decision model I ran and also Jev's third-party figure, which came from a different sample. (BANKING77, TREC)

When a decision model is worth it

It fits well when:

You have no labelled examples yet, and the question has a handful of options. Urgent or not, which of five teams, safe or unsafe. A decision model answers zero-shot. Once you have labels, even with six options a small trained classifier scored higher on TREC (90.4% against laya's 86.6%; 57 against 38 on the questions only one got right, p = 0.06, just short of significance).
You want to route by confidence. Act on sure answers, send the rest to a larger model or a person.
The same judgment repeats many times. Tens of milliseconds per call add up differently from seconds.

Think twice when:

There are dozens of options. If you have a few thousand labelled examples, train a small classifier. On both tasks above it was the fastest and the most accurate; on TREC, laya with label descriptions came within two points (not a significant difference).
Label names are ambiguous. Write a one-line description for each option, then test on your own data.
You will act on the probability itself. laya's own documentation says it ships over-confident and recommends fitting a temperature on your data first. I did not measure calibration.
You are reading someone's benchmark. Check whether the dataset was in the model's training data. laya's documentation, for instance, lists AG News in its training mix, where it scored 94.5%.

Sources: TypeSafe's launch post (architecture outline, 255-option limit, 70–500 ms) and documentation. The failure at 256 options and the 76.3% BANKING77 figure are from nibzard's decision-model benchmark. All other numbers are from the three linked posts: one A100 80GB, one request at a time, measured 2026-09-18 to 2026-09-23.