What is a system one model?

A system one model answers a question about something you give it by picking one of the answers you listed, and telling you how likely each one is. It doesn't write a reply. It reads the material once and returns a judgement your code can act on, in a fixed shape, in a single pass.

The name comes from dual-process theory in psychology, made widely known by Daniel Kahneman's Thinking, Fast and Slow. It describes two modes of thought: system one, which is fast, automatic and intuitive, and system two, which is slow, effortful and deliberate. Chat models work like system two. They compose, reason and explain, a word at a time, and they're remarkable at it. A system one model is the other half: an immediate judgement, with nothing composed and nothing deliberated.

What it gives you

For each question you ask, a system one model returns the same four things:

• The answer, which is always one of the options you listed.
• A probability for every option, adding up to 1.
• A certainty score, from 0 when the probability is split evenly between your options to 1 when one option has all of it.
• An average, for rating questions: where the answer falls on your scale once every level is weighted by its probability.

Because the answer is drawn from your own options, there's nothing to parse, nothing to validate and no retry when a reply comes back in a shape your code didn't expect.

How the answer is computed

The material being judged, which we call the state, is put in front of the model together with one question, and the options are labelled A, B, C and so on. Instead of letting the model write, a system one model reads its probability for each of those labels and rescales them to add up to 1.

Nothing is sampled and no words are produced. That's why the same input gives the same answer, why the answer can never be a sentence you weren't expecting, and why a judgement costs a fraction of what a written reply costs: there's no output to pay for, and the state is read once however many questions you attach to it.

Three kinds of question

Most real work is a handful of these about the same piece of material. A support message might get one multiple-choice question for the queue it belongs in, a rating for how upset the writer sounds, and a yes-or-no for whether it mentions a refund.

{
  "state": "Buy 10,000 followers for $5!!! Link in my profile.",
  "questions": {
    "is_spam": {
      "type": "yes_no",
      "text": "Is this comment spam?"
    }
  }
}

{
  "model": "seacat-1",
  "answers": {
    "is_spam": {
      "type": "yes_no",
      "answer": "yes",
      "probabilities": {
        "yes": 0.9947,
        "no": 0.0053
      },
      "certainty": 0.9519
    }
  },
  "usage": {
    "input_tokens": 82,
    "cost_usd": 0.000017
  }
}

What they're good at

• Routing. Send each ticket, email or lead to the right queue, and pass anything the model isn't sure about to a person.
• Tagging and classification. Label intent, topic, language or tone. One call can label a document on every axis you track.
• Moderation. Ask one yes-or-no question per policy, and set a different threshold for each: strict for anything unsafe, looser for off-topic posts.
• Checking extracted data. Send a document together with the fields pulled out of it, and ask whether the source supports each one before it reaches your database.
• Grading against a rubric. Score model outputs, support replies or applications on ordered levels, and get the spread across those levels rather than a number pulled out of prose.
• Choosing a next step. Pick an agent's or a workflow's branch. The answer is always one of the branches you defined.

What they're not for

A system one model has no second thought, so some work belongs elsewhere:

• Writing anything. Replies, summaries, code and explanations are a chat model's job.
• Arithmetic and counting. There's no working out, so totals, averages, counts and date gaps should be computed in your code and put in the material you send.
• Open-ended extraction. Answers come from options you list. Pulling arbitrary names or amounts out of a document needs a model that writes.
• Questions you can't phrase. If you can't state the options, the model can't choose between them. Vague questions get confident-looking noise, which is why a "none of these" option and a separate "does this say enough to tell?" question are worth adding.

Deciding when to act on an answer

The probabilities are what make the answers usable without a person reading each one. Pick a threshold per question: act automatically when the leading option clears it, and send everything else to a person or a fallback rule. A routing mistake that's cheap to undo can run at a low threshold; anything that emails a customer or closes a ticket deserves a high one.

Pick those numbers from your own data rather than by feel. Label 100 to 200 real examples, run them, and for a range of thresholds measure how often the answers above the threshold are right and how many examples they cover. Take the lowest threshold that meets your accuracy target, and check it again whenever you reword a question, because wording moves probabilities.

A certainty score says how concentrated the probabilities are. It isn't a separate estimate of whether the answer is right, and because it depends on how many options there are, compare it only between questions with the same number of options.

Using one

SeaCat is a system one model you can call over HTTP. You send one piece of text or JSON and up to 64 questions about it, and get every answer back with its probabilities in one response. It's $0.20 per million input tokens, with nothing to pay for output, and the material is billed once however many questions you attach.