What is a System One model?
A System One model is an AI model that answers typed questions about data you supply with a pick, a score or a probability, never generated text.
A System One model does one job. You hand it some state, whatever text you already have, plus a list of typed questions, and it hands back one typed answer per question. No prose, no tool call, no next step. The answer is a value your code can switch on.
Most of what people spend a chat model on is not writing, it is judging: is this spam, which queue does it belong in, how urgent is it. Each has a small fixed set of possible answers.
One caution up front, because the marketing around structured output blurs it: the type guarantees the interface, not the truth. A model that cannot return an option outside your list will still sometimes return the wrong option from inside it.
Where the name comes from
Daniel Kahneman described two modes of thinking: System 1, fast and intuitive, and System 2, slow and deliberate. A chat model imitates System 2 by thinking out loud, and those tokens are where most of its time and bill go. A System One model is named for the other half, the immediate read with nothing shown. That is a convention about the output, not a claim about cognition.
System One model, chat model, ordinary code
| System One model | Chat model | Ordinary code | |
|---|---|---|---|
| What it returns | A pick, a score or a probability | Generated text, optionally a tool call | Exactly what you wrote |
| Can call tools | No | Yes | It is the caller |
| Latency | Vendor-published at about 100 ms | Seconds, more when it reasons aloud | Microseconds |
| Cost shape | Per token read, once per batched call | Per token in and per token out | Free once written |
| Good at | Judging messy input against declared options | Writing, reasoning, multi-step work | Arithmetic, lookups, exact matching |
The last row decides most architectures: the middle column can do the outer columns' work, badly and expensively.
The three question types
TypeSafe's documentation defines three, and their shapes are the whole API.
| Type | The question | What you declare | What comes back |
|---|---|---|---|
| Choice | Which of these options? | Up to 255 options, each described | The pick, a probability per option, a confidence |
| Score | Where on this ordered ladder? | Between 2 and 10 levels, in order | A mean between the rungs, the distribution, a confidence |
| Noul | Is this true? | The statement | One probability from 0 to 1, no confidence field |
Three details matter more than they look:
- Option names and descriptions both go to the model; question ids do not. The docs say to "write descriptions that separate the options from each other", and "Question IDs are for your code." Your meaning lives in the criteria.
- A score comes back between the rungs, as a probability-weighted mean (1.30 in the docs' example), not as one of the levels you declared.
- A noul near 0.5 means yes and no are equally likely, not medium intensity. That reading is ours, not a line in the docs. For intensity, the docs route you to a score along defined levels.
Jev, the first one in public early access
Jev, from TypeSafe, reached public early access on 2026-09-15 and is the first System One model we know of to get there. Everything below is vendor-published rather than measured here, and the two halves of their site do not say the same things, so it matters which half a fact comes from. Their launch post calls the access waitlisted; their quickstart just tells you to get an API key from the dashboard and mentions no gate at all.
From the docs: questions ride one request and are evaluated independently, so "adding more questions does not create context-rot"; a budget of about 32,000 tokens, or "roughly 150,000 characters of English text". Their parallel-questions cookbook puts 13 questions to a 54,000 character Wikipedia article, five repeats each way on jev-1.12, and reports the batched call at 12.2x cheaper and 10.0x faster than 13 separate calls. Another vendor page reports that same experiment as 11.5x and 9.6x. Batching did not change the answers, which is the weaker and more useful claim than identical answers: a couple of the 13 do move between repeats, by the same amount whichever way they are called, which the page reads as noise belonging to the question rather than to the batching. One article, one model, one run set. The shape underneath needs no multiple: N separate calls pay to read the document N times, the batched call pays once.
From the launch post: $0.042 per million input tokens, output tokens reported on the response but not billed, most queries completing in about 100 ms, and a note that the rate may be subsidised. The docs carry no price list at all; the nearest thing is the cost table in that cookbook, which pins its rate to a dated version, jev-1.12 "as of 2026-09". Read it as a per-version early-access rate rather than a standing price. A general-purpose model such as GPT-5.6 Luna is $0.20 per million input tokens and $1.20 out, so the published Jev rate is a little under five times cheaper on input. Our rates are on /pricing.
No rate limit, quota, concurrency ceiling or uptime commitment is published anywhere. Their API reference covers the 429 and 529 responses only in terms of what to do about them, "retry the request with exponential backoff instead of retrying immediately", which tells you throttling exists without telling you where it sits. The DPA, retention and training-use policies were unpublished as of 2026-09-16. Settle both before you send anyone's data.
Why one is not an AI worker on its own
| What an unattended worker needs | What a System One model gives you |
|---|---|
| Reach an app and act in it | No tool calls at all |
| Take a turn, read the result, take another | One request, one set of answers |
| Write the reply, the summary, the message | No generated text |
| Start itself on a schedule or a trigger | Nothing starts it |
An AI worker is an agent set up to do one job unattended: it starts on a schedule or an event, reaches real accounts with its own scoped key, and leaves a receipt. A System One model supplies none of that by construction. TypeSafe's concepts page says "System One models do not write replies, produce code, or generate explanations of their reasoning", and their how-to page adds that "every loop introduces another opportunity to go off the rails."
Judgment and work are two halves of one job, the subject of Jev and decision models. An agent worker runs on a general model because it has to write the reply and make the tool call. A decision worker is the other shape: no agent loop, so the judging is the run, and the acting happens in code through the same firewall door an agent run uses. WorkerKit runs both, which is why a System One model is a worker class here rather than an entry in the model picker. Support Inbox Triager sorts a support inbox and drafts the answer: sorting suits a decision model, drafting does not.
Where the judgment still needs restraints
A typed answer with a number on it feels safer than a paragraph, and that is the hazard. A calibrated confidence is derived from the shape of the returned distribution, concentrated for a confident answer and spread for an uncertain one. It is a statistic about that distribution, not the model reporting how sure it feels, and it says nothing about correctness.
TypeSafe describe three bands in prose: act automatically on high confidence, proceed with caution in the middle, and on low confidence route to a human. The numbers people quote, 0.9 and 0.5, come from one worked example whose above-0.9 branch still confirms with the user, because that action is high stakes. The governing sentence there is about stakes rather than a number: "Different actions within the same system should be gated at different levels depending on the consequences of getting it wrong." Their own example gates a balance check lower than a transfer approval. A confidence threshold is your number, derived for your domain, and one number for a whole system is already the wrong shape.
A threshold is not a permission. It decides whether to act, and says nothing about what the acting may touch. That is an app firewall, with contact rules and redaction beside it, and on WorkerKit all three ship on every plan including Free.
When you do not want one
- Anything that has to produce prose. That needs a model that writes.
- Open-ended or multi-step work. There is no loop, by design.
- Arithmetic, lookups, exact matching, thresholds on numbers you hold. Ordinary code is cheaper, exact and free.
- Retrieval. It judges candidates you already found. Finding them is search.
- Any option set you cannot know in advance. A choice cannot express an answer outside its list, so always carry a no-match option.
- Legally consequential decisions about people, unsupervised: hiring, firing, credit, benefits, discipline. Sorting for a human reviewer is fine. Deciding is not, however well calibrated the number looks.
- Anything where being wrong sometimes is unacceptable and nobody is downstream. A floor makes uncertainty visible, not the model right.
FAQ
What is Jev?
Jev is a System One model from TypeSafe, in public early access since 2026-09-15. You send it text plus a list of typed questions and it returns one typed answer per question: a pick from options you declared, a score on a ladder you declared, or a probability that a statement is true. It writes no prose and calls no tools.
Is a System One model just a small language model?
No. A small language model still generates text token by token, and you still parse what comes out. A System One model returns a value from a set you declared, with a distribution over it, and no free-text field to parse. The difference is the output contract, not the size.
What has to sit around a System One model for it to do a job?
The parts it leaves out, which together are an AI worker: something to start it on a schedule or a trigger, reach the connected apps, act, and write whatever a person reads. It can decide which queue an email belongs in; something else still has to move it and answer it.
How do you run a System One model on WorkerKit?
As a decision worker, not as a model choice. The deploy-time picker chooses which general model does the writing work, and a decision worker has no agent loop to write in, so it is a separate worker class instead of an entry in that list. It judges each item with typed questions, routes on the answer in code, and acts on the worker's own key under the same per-app Off, Read or Write grants, contact rules and redaction an agent run gets.
What does the confidence number on an answer mean?
It is derived from the shape of the probability distribution the model returned: concentrated on one outcome means a confident answer, spread across several means an uncertain one. In Jev's case, choice and score answers carry one between 0 and 1 and noul answers carry none. It measures agreement, not correctness.
What does a System One model cost to run?
TypeSafe's launch post prices Jev at $0.042 per million input tokens, with output tokens reported but not billed, and says the rate may be subsidised. That is vendor-published, tied to a dated model version, and not measured here. A general-purpose model such as GPT-5.6 Luna is $0.20 per million input tokens and $1.20 out, billed at provider list price with no markup. On WorkerKit a decision worker meters the item judged, not the token. See /pricing.