Jev Model Explained: System One Models

The name comes from psychology, and TypeSafe says so directly: their docs cite Daniel Kahneman's Thinking, Fast and Slow. System 1 is the fast, automatic kind of thinking — recognizing a face, finishing a familiar phrase. System 2 is slow and deliberate, the kind you use to solve a math problem or plan a trip.

Most models released in the last few years aim at System 2. Long reasoning chains, elaborate generations, deep analysis. Jev is a System One model, built for the near-reflexive judgments that make up most of the decisions inside a software product.

What it is optimized for

A System One model is optimized for a different objective than an LLM.

Decisions in routers and guardrails sit on the hot path of every request, so the model has to answer fast rather than think aloud. Jev never writes replies, code, or explanations; the output is typed values and probability distributions your code consumes directly. Its probabilities are trained against real outcomes to reflect genuine uncertainty, which TypeSafe calls calibration and measures across groups of predictions rather than single answers. And each question asks one well-scoped thing, with complex judgments decomposed and recombined in your code.

The three primitives

Every Jev question is one of three types, and you can mix them in a single call.

Primitive	Question it asks	Returns
Choice	Which option from a described list?	`choice`, `probabilities`, `confidence`
Score	Where does this fall on a rubric?	`score`, `probabilities`, `confidence`
Noul	Is this statement true?	`noul`, a 0–1 value

For a refund request, TypeSafe's own example workflow asks three independent questions at once: was a refund requested? (Noul), does the evidence indicate a duplicate charge? (Noul), and does the policy support a refund? (Noul). The answers are then combined by deterministic code.

Two properties make that composition work. Questions are evaluated in parallel and in isolation, so adding one barely changes response time and one question's wording never contaminates another's answer. And because you decompose before you ask, you re-weight by changing a coefficient in code rather than rewriting a prompt. Instead of "rate this startup pitch," you ask separately about market size, technical feasibility, and differentiation, then apply your own formula.

What a decision looks like

A Jev call separates state (the context) from questions (what you want decided). A simplified response:

{
	"answers": {
		"department": {
			"type": "choice",
			"choice": "billing",
			"confidence": 0.89,
			"probabilities": {
				"billing": 0.91,
				"technical": 0.02,
				"sales": 0.07
			}
		},
		"is_urgent": {
			"type": "noul",
			"noul": 0.93
		}
	}
}

Compare that to an LLM replying "billing". You get a probability for every option, so you can see how far ahead the top choice was. You get a calibrated confidence value, which is the hook for fallback logic — remembering that calibration is a property of the group, not a guarantee for any single answer, so design thresholds accordingly. And you get structure, with no prompt engineering to force valid JSON and no parsing step to fail.

Why this matters for agents

Agent frameworks spend most of their cycles on control flow rather than generation. Which agent handles this step? Which tool runs next? Should the loop continue, retry, ask the user, or stop? Is this output good enough to return?

Every one of those is a System One decision: small, frequent, and latency-sensitive. Hand them to a general LLM and you are paying generation prices for judgment calls. Hand them to a System One model and the loop stays fast and cheap, with the LLM reserved for the steps that actually generate value.

The confidence number is the product

The most useful output is not the top label. It is the confidence, because confidence turns a classifier into a policy:

confidence >= 0.85  ->  act automatically
0.60 - 0.85         ->  ask a clarifying question or verify
< 0.60              ->  escalate to an LLM or a human

With that policy, the fast cheap model handles the bulk of the traffic and the expensive judgment is spent only where it is needed. That is the economic case for System One models in production.

Try it

The quickest way to understand System One behavior is to watch the probabilities move. Take one decision from your product, reword the input, add a confusing option, and see how the distribution and confidence respond.

You can do that in the official TypeSafe playground or the Jev Agent playground.