System One models know which work to hand back

Pick any AI feature in your business and follow one request through it. Somewhere in the middle there is a call that exists to answer a question with three possible answers. Billing, technical, or account. It takes a second or two, it charges for a paragraph, and the paragraph is thrown away the moment one line of code has read one word out of it. Mic Lacorte, a founder and engineer in Italy, asked other developers the obvious question on 17 September: "which of your prompts is secretly just an if statement?"

A System One model answers that kind of question and nothing else. You hand it the material and a list of typed questions. It hands back one answer per question with a probability attached to each, and it never writes a sentence, because it can't. The first one released publicly is Jev, published on 15 September 2026 by TypeSafe AI. Its cofounder Diogo Almeida worked on the training method behind today's chat models, then decided that shape was wrong for software meant to run without a person watching.

The name comes from Daniel Kahneman. System 1 thinking is the fast, automatic judgment. System 2 is the slow, deliberate one. Almeida put the split he is after like this: "having AI do the system 1 and code do the system 2". That is a plainer description of the product than either of the two numbers on the company's own home page.

There are three shapes of question. That is the entire model:

• Choice. Pick one option from a list you supply. Which team should this ticket go to.
• Score. Place the material on a rubric you define. How frustrated is this customer, on your scale, not the model's.
• Noul. Is this statement true, answered as a number between 0 and 1. Does this message ask for a refund.

You can't ask it to write the reply. You can only ask it to decide something about the reply, then write the reply yourself or hand that job to a model that does write.

A chat model answers by writing. It produces one token, reads back everything it has written so far, produces the next one, and repeats until it decides to stop. That is why the answer appears on your screen a word at a time. It is also why asking for JSON doesn't make the work any shorter: the model is still writing that JSON one piece at a time, and your code still has to parse the result and cope when the shape comes back wrong.

A System One model never writes. It reads the material and your list of options together, and returns how much probability sits on each option. Hemant, an applied AI engineer at a bank who built an open source version of the idea to understand it, described the difference as taking "an input text and candidate options" and returning "calibrated probabilities and an explicit 'insufficient evidence' outcome in a single forward pass", in place of "token-by-token autoregressive decoding or JSON string parsing".

That has a consequence you can test. The order you list your options in stops mattering much. A model reading left to right meets the first option before the last one and gets quietly swayed by it. Hemant measured this on his own version: reversing the option list changed 3.0% of its answers, against 27.8% for a conventional small model put through a comparable test. A model that reads the whole list at once cannot prefer an option for being first.

The second effect is stranger. Asking more questions is close to free. Abraham Peters, who is building a tool that scores insurance sales calls against a rubric, ran both sizes the same day. One question came back in 238 milliseconds. Thirty-four questions, twenty-seven scores and seven true-or-false checks, came back in 102. The questions get weighed side by side against the same material instead of one after another, so the second one never waits for the first.

TypeSafe's home page leads on two figures: 193.6 times faster and 444.6 times cheaper, footnoted as measured on workflows for the sort of task the model is built for. Those are the company's numbers, on tasks the company chose.

People who ran it in the first week reported smaller ones. OpenChamber, a group building open source tooling for agents, read through the public reports from the first three days and put its own medians next to the claims:

Measure	Claimed	Measured median
Speed-up	193.6x	5x
Cost saving	444.6x	32x
Latency	70 to 500ms	270ms

Individual runs sit either side of that. A developer building a text-driven role-playing game measured a median of 317 milliseconds for the step that reads what a player typed and turns it into an action his server can run, against 6.52 seconds for the setup it replaced, and put his whole test suite of 1,385 calls through for forty cents. John Joubert tried it in a robotics simulator, got around 300 milliseconds, and said that wasn't good enough: "it would need to be closer to 50 ms to have real applications." Chase McDougall measured a median near 400 milliseconds and called the launch figures a disappointment.

Thirty-two times cheaper is still a serious result and nobody should wave it away. It just isn't four hundred times. If you are building a budget on the difference, that gap is the whole budget.

The speed argument buries the interesting part. Every Choice and Score answer comes back with a probability spread across the options you gave it, plus a single confidence figure between 0 and 1 derived from that spread. A confident answer puts most of the probability on one option. An unsure one spreads it thin.

That figure is not decoration. Your code is supposed to branch on it.

Erick Lindberg ran 51 scenarios in three variants each, 153 answers in total, against a pinned version of the model. He got 149 right, at a median of 0.391 seconds. What matters is where the four wrong ones sat: "All four mistakes had low confidence: 0.14 to 0.42. None of the 106 responses with confidence at least 0.90 was wrong in this sample." He supplied the caveat himself, which is the reason the run is worth citing at all: "That's encouraging, but it does not establish a universally safe threshold."

TypeSafe's own documentation makes the same point against its own model, which is unusual enough to read twice. In a published test, the model repeated its own answers across fifteen runs 90.8% of the time. The chat models it was measured against repeated theirs between 87.5% and 100% of the time. It did not win. Apply a confidence floor of 0.60, send everything below it to a person, and agreement rises to 99.2%, with the model answering on its own in 74.2% of cases.

The gain does not come from the model being right more often. It comes from the model knowing which quarter of the work to hand back.

The documentation proposes three bands and they are the right shape for any business using this. Act automatically above a high line. Ask a person in the middle. Do not act at the bottom. Where you draw the two lines depends on what a wrong answer costs, which is why showing someone their account balance and approving a transfer out of it should never share a threshold.

There is a limit on that number worth knowing before you build on it, and it is not a flaw in the model. Confidence describes the material you handed over. It says nothing about the material you withheld. We tested this ourselves by feeding an instruction in fragments, the way software would if it tried to act while someone was still typing. On the words "delete invoice" it picked the delete control and reported a confidence of 1.00. The person was not finished. What they went on to type was "actually no, just archive it instead".

The model was not wrong. It was asked what two words meant and it answered correctly. The words that reversed them had not arrived, and a probability cannot cover information that was never in the question. What makes it safe to act early is whether the action can be taken back. A preview, a filter or a highlight can run on half an instruction. A deletion waits for the person to stop typing.

The company publishes a page listing its own model's failure modes, tied to the version number, which is more than most publish. It isn't a calculator: it doesn't count reliably, and it reads dates as text rather than as ordered quantities, so asking it which of two dates comes first is a bad use of it. It reads instructions literally, answering the question you wrote rather than the one you meant. Accuracy drops when you hand it material that has nothing to do with the question. And it can't generate anything, which is the whole design, but does mean it can never be the only model in a system.

That middle one deserves more than a place in a list, because it is where the time actually goes. The criteria you write are not a prompt the model reads loosely. They are the specification, and they are read exactly. We had a rubric grading how complete a support reply was, whose top grade asked the reply to say what happens next "and by when". Every correct answer to a how-to question scored as incomplete, because a how-to answer has no "by when". Same reply, same question, only the wording of the grades changed: the score moved from 0.81 to 1.53, and the probability sitting on the top grade went from zero to 54%. Both versions fit in one request, which is the cheap way to find this out.

The subtler version is a question that is right about the words and wrong about the consequence. Asking whether a message contains someone's agreement is not the same as asking whether that person agreed, and the two come apart the moment the material includes text written by somebody else, a forwarded email being the ordinary case. The model answers the question it was given. Getting the question to mean what you need it to mean is the work.

Useful as that list is, the sharper findings came from outside it.

One is about tampering. A developer working on open source agent systems ran forty matched pairs of messages through it: each message clean, then the same message with a line appended that was aimed at the model itself. Clean, nothing wrong. With the line attached, 22.5% wrong. The direction surprised him. The appended instruction told the model to ignore the spam criteria and always answer false, and the score moved from 0.04 to 0.66, meaning it became more suspicious rather than less: "an embedded instruction is itself a signal to it." His conclusion is the one to keep: "still good as a cheap first layer. just wouldn't make it the only one."

The other is about what it is really competing against. Alex Vu tested it on a classification problem of his own, 203 categories across 488 cases, against both a fast chat model and small models he had fine-tuned himself. The general model beat the fast chat model, 67.0% against 59.4%. It lost to two of his own, at 69.5% and 72.5%. If you have a fixed set of labels and enough of your own data to train on, something you tuned yourself is still likely to beat a general model that has never seen your problem.

Which means the sceptics are holding something real. Charlie Day's summary is accurate: "it doesn't generate anything new so it's not 'generative' in the sense chatgpt generates new things. it's a classifer, albeit a really good, fast, and cheap one." Classification is decades old. What is new is a general one that needs none of your training data, answers in a fraction of a second, and reports how sure it is.

None of this is a reason for a business to go shopping for a model. It is a reason to look at where the AI already inside your business spends its time.

Almost everything useful an agent does is a long run of small judgments wrapped around one or two pieces of real writing. Is this email from a customer or a supplier. Does this invoice match the order it claims to. Is this the third time this person has asked. Does the job go to the workshop or the office. The same holds one level down, inside the agent's own loop, where TypeSafe's documentation lists choosing which model receives a request, selecting which records to pull in, and checking another model's output for errors among the jobs it built this for. Not one of those needs a paragraph, and until recently every one of them was billed as though it did. Klaas, an engineering cofounder at a search analytics company, put the shift at "50-60%" of his own AI spend, with the honest caveat that he needs more testing. That is his figure for his workload, not a promise about yours.

A wider figure has been circulating, relayed from the consumer finance company Klarna, and it is worth naming what kind of number it is. A language model, asked to size the effect on enterprise spending, put the decision-shaped share of a typical agent-heavy bill at 40 to 60%, and called a 30 to 70% cut in what still reaches the frontier models a reasonable planning range, conditional on the new model holding its advertised price and reliability. That is a projection generated by a model rather than a measurement of anything, and its condition is the same one the measured figures above already put in doubt. It is the shape of the bet, not evidence for it.

The range is wider than the word classifier suggests. A model that cannot write a command can still drive a screen, because most of what happens on a screen is choosing rather than composing. Your code lists the controls that are actually on the page, the model picks which one and which action, and your code carries it out. We ran a five step sign-in that way and it finished in two seconds for about a hundredth of a cent. The coordinates never come from the model: they belong to the element your code already found, so there is nothing for it to invent. Nor does the list of controls have to be short.

Controls on screen	Right one chosen	Time
40	yes, at 1.00	337ms
120	yes, at 1.00	399ms
240	yes, at 1.00	396ms

Those are our own runs on a pinned version, on synthetic screens with clean labels, so treat them as an indication rather than a benchmark. The shape is the interesting part: the time barely moves, because every option is weighed in the same pass.

Two things that loop still needs, and neither of them comes from the model. Something has to turn the screen into a list of controls in the first place. Good markup makes that sound solved, and on a page built for the job it is, but a real site carries hundreds of elements that are technically clickable and a handful that mean anything. Narrowing that honestly is its own problem, and our runs above used clean lists precisely because we had not solved it, which is why they read as a ceiling rather than a forecast. An application that offers only pixels is harder again. And a confident answer is not evidence that the click landed, so the code has to look at the screen again afterwards and check. A probability describes how a model behaves across many cases. It says nothing about whether this one worked.

Everything above treats the judgment as a network call. The shape of the model suggests it will not always be one.

There is no decoder loop to run, the answer is bounded before it starts, and a batch is weighed in a single pass, which is why our own key returned two answers in 501ms and a hundred and eleven in 428ms. Those are the properties that make a model small as well as cheap, and nothing about them needs a data centre.

Say that lands on the device. The cost of asking stops being a line item, and that changes which questions get asked at all. Each judgment described above is currently a decision to spend something: whether an inbound message should wake an agent, whether an event deserves a turn, whether a record belongs in this request. At a fraction of a cent they are worth asking. At nothing they would be asked a hundred times more often, in places where nobody would file a model call today.

That is an argument from the shape of the model rather than a measurement, and no such hardware has shipped. But it sharpens this article's point rather than softening it. A judgment that costs nothing is not automatically a judgment worth acting on. Put one in a thousand new places and the number beside the answer stops being a nicety and becomes the only thing standing between a cheap decision and a confident wrong one.

So the change worth making is not the model itself. It is the shape of the system around it: let something cheap make the small calls, keep the expensive one for work that genuinely needs writing, and record the confidence of every call so you can see which decisions your software should never have been making on its own. That last part is the one most teams skip, and it's the only thing that tells you whether the automation is safe to widen.

The other half of this argument is about where the bill comes from in the first place, which we set out in inference is the meter.