System 1 models answer questions with probabilities

01What a System 1 model is

Same message, two kinds of model

Where it fits

These work together rather than compete: code checks the hard facts, the System 1 model judges the text, and people handle what stays uncertain. If you already have thousands of labelled examples for one narrow task, a purpose-trained classifier is another option.

What about structured outputs?

{
  "team": "billing",
  "confidence": 0.9
}

The two combine well. Use structured outputs to extract facts such as names, amounts and dates, check those facts in code, then put them in the state and let the System 1 model make the judgement.

Why numbers help

The next two sections cover where these models pay off and how they work alongside chat and reasoning models. After that the guide turns technical.

02Where it pays off

A System 1 model earns its place where software makes the same kind of judgement about text thousands of times a day. Five kinds of work cover most uses so far.

Good fit, poor fit

Five questions to ask before a pilot

• Which decision is this, how many do we make each month, and what does a wrong one cost?
• Do we have past cases with known answers to measure against?
• Where do uncertain cases go, and who reviews them?
• Who could gain by manipulating the input?
• Which vendor numbers have we re-measured on our own data?

03Fast and slow together

System 1 models work beside chat and reasoning models. In the usual design the fast model handles the routine cases and passes the rest up, to a reasoning model or to a person.

What escalation does to cost and speed

The defaults are illustrative: about 700 input tokens at $0.04 per million for System 1, and a one-cent, eight-second reasoning call for System 2. Every request pays for the System 1 call; escalated requests pay for both. Replace the figures with your own. The agentic design pattern library on this site covers System 1 / System 2 escalation alongside the other patterns.

04How a request flows

Every request has two parts: the state, which is the text being judged, and the questions, each with a type, instructions and criteria. The response has one answer per question, plus token usage.

The values are invented. The shape follows the /v1/systemone format used by TypeSafe and Microsoft Foundry. Other providers use different field names, so check the documentation for the model you use.

Under the hood

Call it from Python

Standard library only. The later code examples reuse this ask() helper.

import json, os, urllib.request

# Microsoft Foundry: https://<resource>.services.ai.azure.com/providers/microsoft/v1/systemone
URL = os.environ["S1_ENDPOINT"]
TOKEN = os.environ["S1_TOKEN"]
MODEL = os.environ["S1_MODEL"]      # model name, or your deployment name on Foundry

def ask(state, questions):
    body = json.dumps({"model": MODEL, "state": state, "questions": questions}).encode()
    req = urllib.request.Request(URL, body, {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {TOKEN}",
    })
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)["answers"]

a = ask(
    "My account payment has failed twice today. I need help before the end of the day.",
    {
        "urgent": {"type": "noul", "instructions": "Does the customer need help today?"},
        "team": {
            "type": "choice",
            "instructions": "Which team should handle the request?",
            "criteria": {"billing": "Payment and invoice issues",
                         "technical": "Software and integration issues"},
        },
    },
)
print(a["urgent"]["noul"], a["team"]["choice"], a["team"]["probabilities"])

05The three question types

Most decisions fit one of three shapes. APIs that follow TypeSafe's format call them noul (a yes/no probability), choice and score. Other providers say binary or boolean for the first. The type you choose determines what the answer looks like and what you can do with it.

06Writing good questions

The model only knows what the question tells it. Clear instructions and well-separated options matter more than anything else you control.

• Ask one thing per question. Split “urgent and angry” into two.
• Say what evidence counts, for example “only the facts stated”.
• Define every option and level in a single sentence.
• Add a fallback option such as “none of these” when it's realistic.
• Keep wording stable once you start testing, so results stay comparable.
• Put rules and facts the model needs into the state, not into your head.
• Write literally. The model answers the wording, not the intent, so spell out boundary cases.
• Give each question only the state it needs. Irrelevant detail lowers accuracy.
• Shuffle the option order when you test. Some models lean toward the first option.

07Design patterns

Six patterns cover most production use. Each keeps the model's job narrow and leaves control flow, weights and thresholds in your code. The snippets use the ask() helper from section 04.

08Scenario gallery

The same three question types cover very different work. These are invented examples with illustrative results.

09From probability to action

A probability becomes an action once you choose thresholds. A common pattern uses two: act automatically when the model is confident in either direction, and send the uncertain middle to a person. Drag the sliders to see the trade-off on 16 labelled example cases.

10Repeatability

Send the exact same request many times and the answers may vary slightly. Before you automate anything, measure how much. The example below shows 20 identical runs of one noul question, with a 0.70 cut-off.

• SpreadMinimum, maximum and standard deviation of each probability across runs. A small spread is normal.
• Decision flipsHow often the final action changes. A 0.03 wobble doesn't matter at 0.95, but it flips the outcome near a cut-off.
• Top-answer agreementFor choices and scores, the share of runs that pick the same top answer.
• Identical inputHash the request body and confirm every run sent the same bytes, so you know any variation came from the service, not your code.

11Known limits and failure modes

The category is weeks old, and the first independent tests are in. These are the failures reported so far, with what each one means for your design.

What the first independent audit supports

Sources: Check Point (manipulation test), Delaunay, arXiv 2611.12521 (audit), TypeSafe documentation (known rough edges), Sanjay Shankar (Khmer result, context limits), 47Billion (Laya figures). Retrieved November 2026.

12Cost and latency

A System 1 model reads your text and returns a few numbers. A chat model reads the same text and then writes its answer one token at a time. Most of the difference in cost and speed comes from that writing step.

Estimate your monthly cost

Defaults: $0.04 is typical of the hosted decision APIs in section 15. $0.10 and $0.50 are the published input and output prices for OpenAI's GPT-6 Luna as reported in October 2026. Both sides include the questions in the input tokens. Sampling a chat model several times and counting the answers is the usual way to get rough probabilities from it.

Reported latency

Sources: benchlm.ai (Celeris figures), eesel.ai (Cloudflare figures, Luna test and price), MarkTechPost (Microsoft figures), Dave Kerr (20-transaction test). Retrieved November 2026.

13Using it responsibly

A System 1 model is good at judgement calls on messy text. It shouldn't be the only thing standing between a request and an irreversible action.

14Putting it together

Each section above covers one piece. This is the order to use them in, from first draft to production.

1. Write the questionsOne thing per question, distinct options, anchored levels. Put the policy and any facts computed in code into the state (section 06).
2. Label real casesCollect 50 to 100 real inputs and record the answer a skilled person would give. Include hard and borderline cases, not just easy ones.
3. Measure accuracy and calibrationFor nouls, compare against the labels at several cut-offs and draw a reliability chart. For choices, build a confusion matrix to see which options get mixed up. For scores, report exact matches and the share that are off by one level. Track false positives separately.
4. Set thresholdsChoose cut-offs from the labelled results: how many automatic errors you can accept, and how much work the review queue can absorb (section 09).
5. Test repeatability and option orderSend the same request 20 or more times and count decision flips near your cut-offs. Shuffle the options and check the answers hold (section 10).
6. Attack itAdd misleading or injected content to realistic inputs and count how often the decision changes. Decide what screens the input before the model sees it (section 11).
7. Decide what escalatesChoose which uncertain cases go to a reasoning model and which go to a person, and what each path costs (sections 03 and 07).
8. Launch with people in the loopRoute and recommend rather than approve, log every request and answer, and repeat steps 3 to 6 whenever the model, the questions or the input format changes (section 13).

15System 1 models you can use

System 1 models became a product category in autumn 2026, and new ones appear every few weeks. These are widely discussed options as of November 2026. Prices are reported list prices per million input tokens; none of these providers lists a charge for output. Check each provider's page before you rely on a figure.

The Microsoft-Decision-1 price is not on its documentation page; the figure shown is from press coverage. The OpenAI price is from press coverage of the October release. Several community fine-tunes of 4B open models sit near the top of the JevBench leaderboard alongside Jev; they are not listed here because they change weekly.

Comparing and switching

Sources: provider pages linked above; prices as reported by benchlm.ai and eesel.ai, October and November 2026.

Further reading

• Introducing System One Models and Jev, TypeSafe AI. The launch post that named the category.
• Confidence and Patterns, TypeSafe documentation. How confidence is calculated, and the patterns in section 07.
• Use Microsoft-Decision-1, Microsoft Learn. Request examples, limitations and responsible-use guidance.
• Understanding Jev and System 1 models, Dave Kerr. A worked fraud-triage example with timings.
• System One Models: 6 Rules, Sanjay Shankar. Lessons from building a product on these models.
• The System 1 Models: Decisions with Confidence, Sandeep Alur. Hybrid System 1 and System 2 designs for enterprises.
• Can the Confidence and Decisions of System 1 Models Be Trusted?, Julien Delaunay. The first independent audit.
• Jev is not a language model, but it breaks like one, Check Point. The manipulation test.