System One models: System 1 and System 2 thinking applied to AI

“System One model” is TypeSafe AI’s name for a new class of models, and Jev is the first. The idea is fast, typed decisions where an LLM would write text. Here is what the term covers, what the Kahneman analogy gets right, and where it misleads.

What is a System One model?

A System One model reads a state and returns typed decisions with probabilities. That is TypeSafe’s definition. It understands natural language like an LLM does, but it writes nothing.

In: a state, as text or JSON, plus typed questions.
Out: a choice, a score or a probability for each question.
With every choice and score: a confidence between 0 and 1.

The term does not come from research. It is TypeSafe’s label, introduced with Jev in September 2026. Jev is the first model in the class, and the only one TypeSafe offers today.

System 1 and System 2: where does the name come from?

The name comes from Daniel Kahneman. In Thinking, Fast and Slow, he describes two modes of thought.

System 1 is fast, automatic and effortless. It reads the emotion on a face at a glance.
System 2 is slow, deliberate and costly. It works through a multiplication or checks an argument.

TypeSafe maps the idea onto models. A System One model makes quick, focused judgments. An LLM that reasons step by step plays System 2. The docs describe a good question as a call a well-informed expert could make in a second.

Where the analogy breaks down

The analogy helps you place each tool. It does not explain how Jev works.

In Kahneman’s book, System 1 is where biases come from. It jumps to conclusions. TypeSafe acknowledges this and argues its models can be more reliable. That is a promise, not yet public evidence.
The two systems are a metaphor. Kahneman himself calls them fictitious characters, not two parts of the brain.
Jev has no intuition. It is a network trained to output probabilities. “Fast” describes its compute cost, not a way of thinking.
An LLM does not deliberate like a person. Most of its slowness comes from generating one token at a time.

Token by token or one pass: what is the difference?

An LLM generates its answer one token at a time, each conditioned on the ones before. That is autoregressive generation. Writing a JSON decision takes dozens of sequential steps. A reasoning model adds hundreds, sometimes thousands.

Jev works differently, according to TypeSafe’s launch post. It reads the state once. It evaluates every question in parallel. It returns all the answers from a single request. Some commentators, MindStudio for one, call it non-autoregressive.

TypeSafe mentions a new architecture and a parallel sampler.
It has published no technical paper, no weights and no detailed architecture, as Wikipedia notes.
Questions are independent. One answer never becomes hidden context for another.

Why this changes latency and cost

With no generation, the cost sits almost entirely in reading the input. Hence Jev’s pricing: you pay for input tokens and output is free.

Latency: TypeSafe claims 70 to 500 ms end to end, measured from the US West Coast.
Many questions: adding more barely changes response time, according to the docs.
Price: $0.042 per million input tokens. TypeSafe puts LLM input at $0.20 to $10 per million tokens, with output about five times dearer.
Multipliers: the 193.6 times faster and 444.6 times cheaper figures come from TypeSafe’s own workflows. The vendor itself places them at the high end.

In our test, a French ticket with 3 questions took 494 ms end to end, relay included, for 499 input tokens. The service runs on the US West Coast, so the network matters.

A fair caveat. A well-tuned LLM can also classify with a single output token. The gap widens mostly with JSON, several questions and reasoning.

What does “calibrated probabilities” mean?

A model is calibrated when its probabilities match observed frequencies. Across all the cases where it says 0.8, it should be right about 8 times out of 10.

That is the goal of TypeSafe’s training method, RLCD. Probabilities are optimised against outcomes, not against human rater preference. TypeSafe argues that preference training can reward overconfident answers instead.

Calibration is measured over a group. It guarantees nothing about a single answer.
Calibrated does not mean accurate. A model can be well calibrated and often unsure.
It does not travel. Calibration measured in English proves nothing in French or German.
Questions are not consistent with each other. In one of TypeSafe’s examples, “is this a refund request?” scores 0.72 and its negation scores 0.47. They add up to 1.19.

To check it yourself, bucket a few hundred cases by stated probability. In each bucket, compare the average probability with the share of correct answers. If the two track each other, you can set a threshold.

Unstructured state in, typed decision out

TypeSafe frames Jev as a function call: “unstructured state in, typed probabilistic decisions out”, as its launch post puts it.

The state is what you would hand an expert to read: a message, an order, a policy.
The questions fix the answer space up front: options, levels or true and false.
The output always fits that schema. No JSON to repair, no invented option.

{
  "model": "jev-1.13.0",
  "state": {
    "message": "I was charged twice for order A-104.",
    "order": {
      "id": "A-104",
      "captured_charges": 2
    },
    "policy": "Duplicate charges are refunded."
  },
  "questions": {
    "refund_requested": {
      "type": "noul",
      "instructions": "The customer asks for a refund"
    },
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payments and refunds",
        "technical": "Bugs",
        "sales": "Pricing"
      }
    }
  }
}

The schema protects the form, not the substance. Jev can pick the wrong option with confidence. Confidence measured on your own cases is what tells you when to trust it.

When does a System One model fit?

When the answer fits a closed list and the decision comes up thousands of times.

Routing tickets, emails or intents.
Rating on a rubric: urgency, risk, quality.
Checking a statement before taking an action.
Filtering RAG passages and guarding an LLM’s inputs and outputs.
Real-time decisions where every second counts.

When do you still need an LLM?

Whenever you need to produce text or reason over several steps. That is System 2 territory.

Writing a reply, a summary or code.
Extracting a free-form value, such as a name you cannot list in advance.
Chaining deductions or answering multi-hop questions.
Handling cases nobody anticipated in the option list.

Arithmetic, dates and counting belong to neither. They belong in code, which is what TypeSafe recommends for Jev.

How do an LLM and Jev work together in an agent?

The LLM reasons and writes. Jev decides at the branches. Your code stays in charge between the two.

Jev classifies the incoming request: fixed rule, specialist LLM or human. TypeSafe calls this intent routing.
Above the confidence threshold, code follows Jev. Below it, the LLM takes over.
The LLM handles the open part: research, reasoning, drafting.
Jev checks the output before it goes out, as in TypeSafe’s guardrails cookbook.
Every decision is logged with the model version and its confidence.

This split is cheap to try. Our n8n guide applies it to support tickets, and the demo shows Jev’s answers live. For the model itself, read what is Jev.

Jev and TypeSafe are trademarks of TypeSafe AI, Inc. This article is independent and not affiliated with TypeSafe AI.