System 1 vs System 2 AI, and the gap between them

Psychologists describe two modes of thought. System 1 is fast and intuitive. System 2 is slow and deliberate. Most of what we decide in a day is System 1, and we switch to System 2 only when something feels off.

That split is a useful way to look at the models we put inside software. Ask "system 1 vs system 2 AI" and you get two families, each good at half the job. This post walks through what goes wrong at each extreme, and what a model that sits between them does instead.

System 2: models that think through everything

Reasoning models think through every question, even the easy ones, and answer in paragraphs you still have to parse.

Look at the decisions a real system makes in a day and most of them are easy. The language of a ticket. Whether a page has loaded. Which of five clearly different queues a message belongs to. A direct read gets these right, and thinking about them only adds seconds.

So a System 2 model costs you twice. You wait for deliberation the question never needed, and then you write code to dig the answer out of prose. On one call that's tolerable. On every event in a pipeline, it decides whether the model can sit inside a request at all.

System 1: models that answer at a glance

Fast decision models go the other way. They answer in a single glance. Easy calls are instant. Hard ones come back confidently wrong.

Take a delivery question:

"Ordered Friday. Delivery takes 9 days, weekends included." Which day does it arrive?

At a glance, Saturday and Sunday look about equally likely. Getting it right takes counting, and a model that can only glance has no way to slow down. It picks one, fast, and your code has nothing to tell it that this answer was a coin flip.

That's the System 1 failure: not that it's wrong sometimes (every model is), but that the hard questions get the same treatment as the easy ones.

The gap between them

Put the two side by side and the gap is clear:

• System 2 is careful on every question, including the many that don't need it.
• System 1 is fast on every question, including the few that do need care.

What you want is fast on the easy majority and careful on the close calls, decided per question, with the same kind of answer either way. That's what we mean by System 1.5.

What a System 1.5 model does

Wity answers most questions in one fast pass, in about a tenth of a second. When an answer is uncertain or unstable, it thinks first and then answers. Either way you get the same thing back: a typed decision with a probability for every option.

In auto mode the flow has three steps:

1. Direct read. Wity answers at once and checks whether that answer is robust: a clear winner that doesn't change when the options are presented differently.
2. Close call? Most questions pass, and the answer comes straight back. If not, it thinks.
3. Think, then stop. It reasons step by step and stops as soon as the answer has settled, instead of running a fixed long chain of thought.

There are three reasons it will think:

• close_call: the top options are close. A ticket at 0.51 billing and 0.46 account access deserves a closer look.
• order_sensitive: the answer changes with the order of the options. A sound answer shouldn't depend on that.
• forecast: the question asks how likely something is, not which answer is right.

Back to the delivery question. Saturday and Sunday are close, so Wity counts: Friday plus seven is Friday again, then Saturday, then Sunday. It answers Sunday, and is now sure of it.

Most thoughts finish in a few hundred tokens, and thought answers typically take one to four seconds. The easy questions in the same request still come back at direct-read speed.

You can see when it thought

Every answer says whether it thought, and why:

"reasoning": {
  "mode": "auto",
  "thought": true,
  "reason": "close_call",
  "thought_tokens": 184
}

Log that next to each decision. A question that often thinks for close_call is telling you two of its options overlap. Sharper descriptions, or splitting it in two, make it both faster and more accurate.

Choosing the mode

One field sets it for the whole request:

{ "state": "…", "questions": { … }, "reasoning": "auto" }

• auto for almost everything: fast where it can be, careful where it has to be.
• off for the lowest, most predictable latency, like a step in an interactive UI. Close calls still show up as close probabilities, so your thresholds keep working.
• always for batch jobs where every decision is expensive to get wrong and nobody is waiting, like overnight review of flagged transactions.

The output type is the same in every mode, so switching never changes your code. Thinking isn't billed either, so a thought answer costs the same as a direct one. The only reason to turn it off is time, not money.

Where this leaves you

No model is perfect, and a 1.5 model doesn't change that. What changes is where the effort goes: none on the questions that don't need it, and some on the ones that do. The probability on every answer still lets your code decide when to act and when to hand a decision to a person.

The reasoning docs cover the modes, the response fields and how to plan around latency.