System One models
Fast typed judgments for software, not a chat LLM.
System One models make fast, structured decisions that software can use directly. A model in this class evaluates a state and returns typed answers and probabilities. Jev is TypeSafe's flagship model and the first public System One model. Like an LLM, it understands natural-language input. Unlike an LLM, it does not write replies, produce code, or generate explanations of its reasoning. You define the possible answers through Choice, Score, and Noul.
How it differs from an LLM
An LLM is trained to continue text. A System One model is trained for calibrated decisions: probabilities are optimized against outcomes so they reflect uncertainty across groups of predictions. Calibration does not guarantee that one answer is correct. It does mean you can set gates in code — act, review, or escalate — instead of parsing a paragraph.
You never ask Jev to draft an email or a function. You ask which queue should own a ticket, how frustrated a customer sounds, or whether a message requests a refund. The table on TypeSafe's concept page uses those three examples: Choice returns choice: "billing", Score can return 1.4 on a 0-2 frustration scale, and Noul can return 0.95 for a yes/no refund check.
The System One name comes from Daniel Kahneman's Thinking, Fast and Slow. System 1 is fast and intuitive. System 2 is slower and more deliberate. TypeSafe puts the fast judgment in the model and the slow control flow in your application. If a task needs long chains of indirection or free-form writing, that work belongs to a generative model or to code, not to Jev 1.13.
RLCD instead of RLHF
TypeSafe trains Jev with Reinforcement Learning for Calibrated Decisions (RLCD). RLHF is the stack used to make chat models agreeable. RLVR is the usual path for long-form reasoning models. RLCD is the path TypeSafe documents for System One: reward calibrated decisions rather than fluent tokens. The launch post also mentions a new architecture and a parallel sampler that evaluates many questions against one state.
Because the weights are shared, you do not fine-tune or LoRA-adapt Jev with customer data. Put proprietary records in state. Encode domain rules in instructions and criteria. Split a broad judgment into atomic questions and combine the numbers in code. Composite scoring and a downstream classical model on Jev's probabilities are the documented ways to specialize without training a private copy.
Jev currently accepts text only. Strings, JSON objects, and arrays of text are legal. Pixels and waveforms are not. English is the primary training language; CJK and other scripts are accepted with lower accuracy, so test before you route a non-English workload. Confidence on Choice and Score is the practical way to keep those weaker languages behind a human gate.
Fast judgments inside a larger workflow
For a refund request, the documented loop is: build a state with the message, transactions, and policy; ask independent questions together (was a refund requested, does the evidence show a duplicate charge, does the policy allow it); then combine answers with deterministic checks and route for action or review. Once primitives are in place, you compose them. Typed outputs mean your code can inspect answers without a parser for leftover prose.
Speculative fan-out is the pattern that makes this cheap. You send questions you might not need, including ones that assume a device type or an intent, and you drop the irrelevant results after the call. Sequential round trips would wait for each hop. Jev evaluates the map in parallel, so extra questions barely move latency. That is why the smart-home demo can ask category, domain, device, and action together.
Call a System One model with typesafe-sdk, @typesafe-ai/sdk, or POST https://api.typesafe.ai/v1/systemone. The model field selects the build; docs examples use jev-latest, which currently points at jev-1.13.0. Start with state shapes and primitives, then add confidence gates before any automatic side effect.
What stays outside System One
Generation, long-horizon planning, and tool-using agents are System Two work in Kahneman's language. Jev 1.13 will not write the refund email, the SQL, or the next Wikipedia paragraph. It will tell you whether the ticket is a refund, which queue should own it, and how sure that call is. Pair it with a generative model when you actually need tokens out.
Numeric identity is also out. Counting, date order, and hex distance belong in code. The jaggedness page is the catalog of those edges, last reviewed 17 September 2026. A System One workflow that ignores that catalog will look calibrated and still route on a literal misread.
Pixels stay out until TypeSafe ships image input. Doom, Wikiracing, and the smart-home assistant all send text. If your product is a camera, transcribe or describe first. If your product is audio, the same rule applies. The 64k and 32k budgets are for tokens, not for frames.
System One is a product class with one public member today. If TypeSafe ships a second model on the same endpoint, the model field is how you select it. Until then, jev-1.13.0 is the versioned ID behind jev-latest and jev-preview. Treat every other chat or reasoning model as a different class, even when it sits in the same overall workflow.
RLCD is the training method TypeSafe names for this class. It is not a switch you pass in the request. You still write instructions and criteria, and you still combine answers in code. The difference is what the weights were optimized to do: calibrated decisions, not chat tokens. That is why the output is Choice, Score, or Noul instead of a paragraph.
Keep chat models for writing. Keep Jev for the fork in the road. The two can share a workflow; they should not share a prompt. That split is the whole point of a System One model sitting next to an LLM.
Kahneman is the namesake, not a runtime mode. You still pick Choice, Score, or Noul yourself.
Sources