How to tell a System One task from a System Two task

Most feature plans that reach us have one box on them labelled "the model". Inside that box are ten or eleven different jobs: sort the incoming request, check the attachment, pull out the date, decide whether to escalate, write the reply, and so on. One model, one price, one response time for all of them. Since TypeSafe released Jev on 15 September 2026, that box has to be drawn as two, because the jobs inside it now have two prices and two speeds, and one of the two models cannot write a sentence.

TypeSafe calls Jev a "System One model". The name comes from Daniel Kahneman's book Thinking, Fast and Slow, in which System 1 is the fast, automatic judgment a person makes without effort and System 2 is the slow, deliberate reasoning, and a System One model does only the first kind. You send it a piece of text plus a set of named questions, and it returns a typed answer and a probability for each. There are three question types: a Choice picks one of up to 255 options you listed, a Score places the text on a scale of 2 to 10 levels you described in words, and a Noul answers a yes-or-no statement with one probability from 0 to 1. TypeSafe states 70 to 500 milliseconds per request and $0.042 per million input tokens, output free. Everything a product team needs to know about which jobs belong in which box follows from that description. We use a three-part rule, with four exclusions, and below we walk three common features through it.

1. Three tests, and a task has to pass all three

The possible answers can be written down before the call. A Choice needs its options listed. A Score needs each level described in a sentence. A Noul needs the statement. If you can write those before the request goes out, the task is a candidate. If the answer has to be composed, because it is a reply, a summary, a plan, or a list whose items you cannot predict, it is System Two: a language model or a person.

The task repeats at volume. The price difference only matters when it is multiplied. TypeSafe's own batching test asked 13 questions about the 53,777-character Wikipedia article on GDPR: one batched request cost $0.000497 and took 0.27 seconds, while 13 separate requests cost $0.006090 and took 2.71 seconds, on jev-1.12 with five repeats each way. In LangChain's test the same month, a language model judge took 2.16 to 2.83 seconds per decision. If a decision happens fewer times a day than a person could review by hand, that saving buys you nothing, and the language model you already have is fine.

Nobody needs a written reason. Jev returns probabilities and no explanation. If a customer, a regulator, or a colleague will ask "why was this decided", the reason has to be composed, which is System Two. You can log the probabilities, and you should, but a probability of 0.83 is a record, and a person asking why wants a sentence.

A task that passes all three is a System One task. A task that fails any one is System Two, or is split, which is what the examples below show.

2. Four tasks that look like System One and belong in code

TypeSafe published a weaknesses page for jev-1.13 with the launch, and four items on it are tasks a product team would otherwise sort into the fast box.

Counting. The page says the model "does not count reliably", that it recognises the shape of an answer rather than tallying, and that the error grows with the size of the thing counted. Its advice: if a parser can find the unit, count in code; if each item needs a judgment, ask one Noul per item and add the answers up yourself.

Numeric comparison. Given two numbers, the model "cannot reliably judge whether two values are near each other", and its Score levels are "weak in numerical calibration", so a score of 2.4 does not mean a value 40 percent of the way from level 2 to level 3. Use a Score to check whether a threshold is crossed, and keep every subtraction in code.

Dates. The model "reads dates as text, not as ordered quantities", so which of two dates comes first, how far apart they are, and whether one falls inside a window are unreliable. The page's own fix is to extract each part as a Choice (twelve months, thirty-one days, a bounded range of years, plus an explicit "not stated" option) and let code assemble and compare the date.

Double negatives and indirection. Scoping words, negations and implied conditions are read exactly as written, and a question that needs the model to follow two references is answered less reliably than one that points straight at the text. Write the exact condition, and when interpretation is unavoidable, split it into two literal questions and combine them in code.

All four follow one rule TypeSafe states in its design guidance: keep control flow, deterministic rules and side effects in code. The model answers judgment questions, and arithmetic is a code question.

3. Three features walked through the rule

Support triage. An incoming ticket needs a queue, an urgency, and a few facts. The queue is a Choice among the names of your queues, which you can list. Urgency is a Score with four levels, each described in a sentence ("customer cannot log in", "customer asks a question"). "The customer is asking for a refund" and "the message mentions a legal threat" are Nouls. Tickets arrive by the thousand, and nobody asks the router for its reasons. All three tests pass, so triage is System One. TypeSafe's design guidance names "Is this spam?" as the anti-pattern here: one broad question in place of several narrow ones combined in code. The reply to the customer fails the first test, because it has to be composed, and the explanation of why a ticket was escalated fails the third, so both stay with a language model or a person.

A document check. An uploaded invoice has to be accepted or rejected. "The invoice names the supplier on the purchase order" is a Noul. "The currency is one of USD, CAD, EUR" is a Choice with a fourth option for "other". Both pass. "The total equals the sum of the line items" is arithmetic and goes to code. "The invoice date is within 30 days of delivery" is a date comparison, so it is split: three Choices for month, day and year, each with "not stated", then code builds the date and does the comparison. The message telling the supplier why the invoice was rejected is System Two. One feature, three boxes: the decision model, code, and the language model.

A drafting assistant. A tool that writes a first draft of a sales email is System Two in its main job, because the draft is composed. What surrounds the draft is System One. "The draft follows the instruction it was given", "the draft states a price that does not appear in the input", and "the draft stays within the requested tone level" are Nouls and Scores that can run on every draft before a person sees it. Openlayer's jevals library ships checks named InstructionFollowing, Hallucination and Faithfulness in exactly this shape, one Jev request per record. The word count is code.

4. What the split buys you, and what it does not

The reason to split is speed, price, and the shape of the answer. On the vendor's own numbers, accuracy is close to even. DataCamp's explainer reports a TypeSafe workflow evaluation in which Jev agreed with the reference answer 67.8 percent of the time, against 67.9 percent for GPT-5.6 Terra, 74.1 percent for GPT-5.6 Sol and 73.1 percent for Claude Opus 5. Those are workflows TypeSafe wrote, so treat them as the vendor's figures. The same evaluation reports 0 percent structured output errors for Jev against 45.5 percent for Claude Haiku 4.5, which is the number a product team should look at: the answer always comes back in the shape you asked for, so the code that reads it never has to guess.

TypeSafe's own coding agents page says the same about scope: Jev "is not a drop-in replacement" for the language model running an agent, and is used inside the application for routing, rubric scoring and checking statements. That is the split above, stated by the vendor.

We apply the rule to our own work. Our eval suite grades every change before it is released, and the checks that used to need a language model as judge (does the change meet the written acceptance criterion, does it stay in scope, did the agent follow the plan) are now Nouls and Scores with the rubric written into the question, graded by Jev. The checks with a deterministic answer stay in code, and a grade in the uncertain band goes to a person. Measured against our previous grader, the suite runs ten times faster. That is the one figure we will put on it. The longer version of the rule, with the question templates, is in System One models for product teams and decision models for product teams, and the older question of which tasks should stay with a person is in how to decide if a feature needs a human in the loop and how to choose what not to automate.

Thanks to TypeSafe for publishing a weaknesses page on launch day, which is the document this rule is built on, and to the DataCamp, LangChain and Openlayer teams for numbers with their methods attached.

If you can write the answers before you ask the question, you do not need a model that writes.

Sources

• TypeSafe AI, "Introducing System One models and Jev" (15 September 2026). Vendor announcement and the 70 to 500 millisecond figure.
• TypeSafe docs, System One concepts. The Kahneman naming note and the three question types.
• TypeSafe docs, Models. Price of $0.042 per million input tokens, output free.
• TypeSafe docs, Parallel questions cookbook. The 13-question batching test on the 53,777-character GDPR article, jev-1.12.
• TypeSafe docs, Model jaggedness for jev-1.13. Counting, numeric comparison, dates, literal reading and indirection, with the vendor's own workarounds.
• TypeSafe docs, How to build with System One. Keep control flow and side effects in code; the "Is this spam?" anti-pattern.
• TypeSafe docs, Coding agents. "Not a drop-in replacement" for the model running an agent.
• LangChain, "Can Jev be a better agent evaluator?" (20 September 2026). Per-decision times of 2.16 to 2.83 seconds for language model judges.
• Openlayer, jevals on GitHub. The InstructionFollowing, Hallucination and Faithfulness checks.
• DataCamp, "Jev: TypeSafe's System One model explained". Reports TypeSafe's workflow evaluation: 67.8 percent agreement for Jev against 67.9, 74.1 and 73.1 percent for the named language models, and 0 percent against 45.5 percent structured output errors.