Thinking Fast and Slow for AI: System 1 vs System 2 and TypeSafe's Jev, Explained

Ask a reasoning model whether a support ticket is about billing or shipping, and it may spend hidden thinking tokens weighing the question before it returns one word. You pay for that deliberation and you wait for it. The answer is a label that an experienced support agent would have picked in under a second without thinking about it. Psychologists have a name for that kind of instant judgment. On September 15, 2026, TypeSafe AI opened early access to a model built around it and called Jev a "System One model." To judge whether the label means anything, you first need the original idea.

System 1 and System 2, Explained Without Jargon

Daniel Kahneman's Thinking, Fast and Slow popularized a split that psychologists had studied for decades. Humans think in two modes, which Kahneman plainly named System 1 and System 2.

System 1 is fast, automatic, and mostly invisible. You don't decide to read a stop sign. You just read it. System 1 answers 2 + 2 before you ask it to. It keeps a car centered on an empty highway while you talk to a passenger, and it hears anger in someone's voice from one syllable.

System 2 is slow, effortful, and deliberate. Try 17 x 24 in your head and notice the shift. You stop, hold intermediate numbers, and maybe stop walking. Parallel parking on a busy street takes the same mode. You can't chat freely while you do it, because System 2 has limited capacity and uses it up quickly.

Most of life runs on System 1, and that works out well. It costs almost nothing, and on familiar ground it is usually right.

Where each system goes wrong

System 1 fails in predictable ways. That predictability is what made Tversky and Kahneman's 1974 paper Judgment under Uncertainty: Heuristics and Biases so influential. Two of its failure modes map directly onto AI:

• Anchoring. Participants watched a wheel of fortune land on 10 or 65, then estimated the percentage of African countries in the United Nations. The median estimates were 25 for the group that saw 10 and 45 for the group that saw 65. A number everyone knew was random pulled the answer.
• Substitution. Faced with a hard question ("How likely is this startup to succeed?"), System 1 quietly answers an easier one ("Do I like the founder?"). It then reports that answer with full confidence.

The confidence is what makes these errors dangerous. System 1 does not flag its guesses as guesses. The bat-and-ball puzzle that Kahneman made famous shows this well. A bat and a ball cost $1.10 together, and the bat costs $1.00 more than the ball. "Ten cents" arrives instantly and feels right, but the ball costs five cents.

System 2 has its own flaws. Kahneman describes it as lazy: it usually accepts System 1's suggestions unless something forces it to engage. It is also expensive. Deliberate thought is slow and tiring, and nobody can run it on every decision in a day.

How the handoff works

System 1 runs by default and produces impressions. When it hits something surprising, or something it has no quick answer for, it calls in System 2. System 2 then either endorses the impression or overrides it.

That handoff is the part worth copying into software. Good human judgment depends on this arrangement: a cheap fast system handles routine work, and an expensive slow system steps in when the fast one is out of its depth.

Mapping the Two Systems onto AI Models

The analogy is loose. Neural networks are not brains. Still, the framing has shaped real research. A 2021 AAAI paper by Booch, Rossi, and colleagues, Thinking Fast and Slow in AI, proposed an architecture with fast solvers, slow solvers, and a metacognitive component that decides which one to trust for a given problem. Builders can use that structure even if they never read another cognitive science paper.

Here is roughly where today's models sit:

• Chat LLMs generate text one token at a time, and each token is another pass through the model. Even a one-word answer comes from a machine designed to write.
• Reasoning models move further toward System 2. They produce extended chains of thinking tokens before they answer. OpenAI's write-up on learning to reason with LLMs showed that performance on hard problems improves as the model spends more compute thinking at inference time. That is deliberate effort, paid for with latency and tokens.

For proofs, debugging, and multi-step planning, that trade makes sense. For "is this ticket billing or shipping," it is like using parallel-parking concentration on an empty highway.

Classic machine learning classifiers, such as gradient-boosted trees or a fine-tuned BERT model, have always had a System 1 shape: fixed outputs, one pass, and very fast. Each one needs its own labeled training data, though, and each does exactly one job. Jev aims at the gap between those narrow classifiers and general-purpose LLMs. It is a general model that reads arbitrary text and emits only a decision.

What TypeSafe's Jev Is

Everything in this section comes from TypeSafe's own materials, mainly its launch post introducing System One models and Jev. Read every number here as a vendor claim.

Jev is named after William Stanley Jevons, the 19th-century economist behind the Jevons paradox: when a resource gets cheaper to use, total consumption of it tends to rise. The implied bet is that once decisions become cheap enough, software will make many more of them.

Jev accepts unstructured text or JSON and returns a typed decision in a single non-autoregressive pass. It never writes sentences. Its output comes in three primitives:

Every answer comes with a calibrated confidence value. TypeSafe's performance and pricing claims are:

• 70-500 ms end-to-end latency
• 40x-200x faster than frontier LLMs on "System-One-shaped" queries
• Up to 193.6x faster and 444.6x cheaper, according to homepage figures reported by Tom's Hardware
• Input at $0.042 per million tokens, with free output
• Text-only input
• Access through a waitlist

Free output makes sense given the design. The output is a label and a number, so almost all of the compute goes into reading the input.

Reading the Claims Carefully

Four points deserve attention before anyone rebuilds a pipeline around this.

1. "Never makes type errors" is a format guarantee. It means Jev cannot return an option outside your set or a score outside your range, so you get zero out-of-schema outputs. It says nothing about wrong decisions. Routing a billing ticket to the shipping queue is a perfectly well-typed mistake.

2. The ~68% workflow eval score used other frontier models' answers as the reference. As KDnuggets points out, that score measures agreement with other models. Accuracy against independent ground truth has not been published. When the frontier models are wrong on a case, agreeing with them still earns credit.

3. Independent tests so far are small. Early coverage, such as The Register's hands-on report, still asks whether it is good, not just fast. Early access opened on September 15, 2026. Treat the speed and cost figures as hypotheses to test on your own traffic.

4. It cannot write, reason step by step, code, or use tools. That is by design. If a task needs any of those, Jev can only be one component of the solution.

For architecture, the claim that matters most is calibration, so test it first. Guo et al.'s 2017 paper On Calibration of Modern Neural Networks found that modern deep networks tend to be overconfident, meaning their stated probabilities run higher than their hit rates. Calibration means that of all answers given with 0.9 confidence, roughly 90% are correct. If that holds on your data, you can build escalation logic on it. If it doesn't, the confidence number is decoration, and you have rebuilt human System 1: fluent, fast, and sure of itself when it shouldn't be.

In a System One model, the confidence score may be worth more than the decision itself, because the confidence score is what tells you when to call System 2.

Fast Layer, Slow Layer: An Architecture That Uses Both

The practical pattern copies the human handoff. The System One model makes the default decision on every item. Low-confidence cases go to a reasoning model or a person.

A fast decision layer fits these jobs well:

• Routing and triage: sending requests to the right queue, team, or downstream agent
• Classification: intent, topic, language, document type
• Guardrails: screening inputs for jailbreak attempts or policy violations before an expensive model sees them
• Smart if-statements: replacing brittle keyword rules in workflows with a typed judgment
• Map-reduce over large datasets: scoring each of a million records, then sending only the interesting slice to a slower model

Here is how the two kinds of model compare:

Worked example: support ticket routing (composite)

This is a hypothetical composite. It is not a client deployment. Picture a SaaS company with eight support queues that receives 10,000 tickets a day.

1. Each ticket goes to a Choice call with nine options: the eight queues plus "unclear."
2. A parallel Noul call estimates the probability that the ticket is urgent, such as an outage, a security report, or a legal threat.
3. If the Choice confidence is at or above 0.85, the ticket is routed automatically. Below that, a reasoning model reads the ticket and the customer's history, picks a queue, and writes a one-line note explaining why.
4. Any ticket with a high urgency probability pages a human, whatever the routing result.
5. Every decision is logged with its confidence. Each week, a person reviews a random sample of auto-routed tickets to confirm that calibration is holding.

The cost math is simple at TypeSafe's list price. At about 400 input tokens per call, including the queue descriptions, one call per ticket comes to 4 million tokens a day, or roughly $0.17. Two calls per ticket come to about $0.34 a day. The escalation rate drives the real bill, and the 0.85 threshold controls that rate.

Set the threshold with data before launch. Run 300 to 500 historical tickets with known correct queues through the model, group them by confidence, and measure accuracy in each group. Choose the threshold where auto-routed accuracy matches what your human team achieves today. If the groups don't line up, for example if 0.9-confidence answers are right only 70% of the time, keep every ticket on the escalation path until that changes.

Now apply the Jevons paradox to your own roadmap. Once routing costs cents a day, someone will want to score every ticket for churn risk, sentiment, and upsell intent. Inference spend stays small, but the number of automated decisions nobody reviews grows quickly. Budget for review capacity alongside the API bill.

Picking Your First Fast-Layer Decision

A good first candidate has four properties:

• The output is already a fixed set of options, such as queues, categories, or yes/no.
• Volume is high enough that latency and per-call cost matter.
• Mistakes are recoverable. A misrouted ticket gets bounced back; a wrong wire transfer does not.
• You have labeled history, so you can check calibration before go-live.

Poor first candidates include decisions a regulator will ask you to explain, decisions where one error is expensive, and any task that needs the model to write something back to a customer.

Not every team should build this. If your helpdesk's built-in routing already meets your accuracy bar, keep it. If you have no labeled history, spend a month collecting labels before you evaluate any model. Because Jev is in early access with limited independent testing, run any pilot in shadow mode beside your current process before it replaces anything.

When OpenNash designs this kind of system, the work starts with the parts no model provides: the typed decision itself, the escalation threshold, the human handoff, and the audit log that lets you prove calibration later. Those pieces carry over whether the fast layer ends up being Jev, a fine-tuned classifier, or a small LLM with a strict output schema.

If one of your workflows uses a large model to write paragraphs just to pick a label, export 200 recent examples along with their correct answers. Bring that file to a call with OpenNash, and we will use it to test whether a fast decision layer with escalation holds up on your data.