Jev and System One models: a plain guide

Jev landed on 15 September 2026 with a claim that sounded like marketing and turned out to be a definition. TypeSafe AI called it the first public System One model, "a new class of frontier models built to make fast, structured decisions that software can use directly" [1]. The waitlist came off five days later, on 20 September, and anyone can now create a key at console.typesafe.ai [11]. We had been grading part of our eval suite with a language model, and within the week we had moved that grading to Jev. This guide is what we learned while doing it, with every figure attributed to whoever measured it.

Here is the short version. A language model writes text, and if you want a decision you have to ask it to write the decision and then parse what it wrote. A System One model skips the writing. You send it a piece of text, which TypeSafe calls the state, and a set of named questions. It returns an answer for each question with a probability attached, and the answer always fits the shape you asked for [2]. That single change is what makes it faster, cheaper, and more predictable than a language model for the class of decisions where the possible answers are known in advance. It is also what makes it useless for anything that needs a sentence written.

What a System One model is

The name comes from Daniel Kahneman's description of two kinds of thinking: fast, automatic judgment, and slow, deliberate reasoning. TypeSafe borrowed the label for a model that does the first kind only. It classifies, routes, scores, extracts a label, or picks a branch [2]. Chat, code and explanations are language model work.

That sounds like a limitation, and it is one. It is also the point. Most of the decisions inside a software product are of the fast kind: is this message spam, which team should get this ticket, does this response follow the instruction, is this tool call inside the plan. Teams have been paying for a slow, expensive model to answer fast, cheap questions because until this month there was no public model built for the fast kind. We wrote a full definition, including what fits and what does not, in what is a System One model.

What Jev returns

Jev has three question types, which the docs call primitives.

A Choice question picks one option from a list of up to 255. It returns the chosen option, a probability for every option, and a confidence number [13]. A Score question places the state on an ordered scale of 2 to 10 levels that you describe in words. The score is each level number multiplied by its probability, added up, so it can land between levels. The docs' own example returns a score of 1.43 with a confidence of 0.35 and probabilities of 0.0, 0.57 and 0.43 across levels 0, 1 and 2. A Noul question is a yes/no statement and returns one probability from 0 to 1, with no separate confidence number [2].

Each maps to a decision your code already makes. Choice is a switch statement. Score is a threshold on an ordered scale. Noul is an if. The mapping, the limits, and how to name the questions are in what Jev returns: Choice, Score and Noul.

Calibrated probabilities and what confidence means

A calibrated probability is one you can trust as a frequency. If the model says 0.8, then across many such answers it should be right 8 times in 10. TypeSafe trains for this with a method it calls Reinforcement Learning for Calibrated Decisions, or RLCD, and has not disclosed the architecture behind it [1] [7].

Confidence is a separate number, for Choice and Score only, computed from how spread out the probabilities are. For three options the docs give the formula (3 x largest probability - 1) / 2. The docs then suggest bands: 0.9 and above, act automatically; below 0.5, route to a person, ask for clarification, or fall back to another system; the middle, proceed with caution. They add a line we think every team should copy: "Different actions within the same system should be gated at different levels depending on the consequences" [4]. Refunding $5 and deleting an account deserve different thresholds. The full explanation is in calibrated probabilities and confidence, explained.

How to write the state and the questions

The state can be a string, a JSON object, or an array of text values, and it is text only, with no images or audio. It is capped at 32k tokens, inside a 64k limit for the whole request [3]. The questions are written in plain language, and the model answers exactly the question you wrote. TypeSafe's design guidance says to break a broad judgment into atomic questions and combine them in code with weighted arithmetic, and it names "Is this spam?" as the anti-pattern: too broad for one question, and better served by several narrow ones about what the message actually contains [14].

The reason this matters is on TypeSafe's own list of known weaknesses: Jev "answers the question you wrote, not the one you meant. Scoping words, negations, and implied conditions are read at face value" [6]. So a question with a negation in it, or a question that assumes context that is only in your head, will be answered literally. How to write the state and the questions is the practical page.

Many questions in one call

Every question in a request is evaluated in parallel. The docs put it as "Adding questions barely changes the response time" [15]. TypeSafe's batching cookbook measured it on jev-1.12: 13 questions against the 53,777-character Wikipedia article on the GDPR, five repeats each way. One batched request cost $0.000497 and took 0.27 seconds. Thirteen single requests cost $0.006090 and took 2.71 seconds. TypeSafe reports that as 12.2 times cheaper and 10.0 times faster, and notes that answers did not depend on what else was in the request, with a standard deviation of 0.0 across repeats for 11 of the 13 questions [5].

That is the vendor measuring its own product on a workload it chose, so read it as an upper bound on what batching can do rather than a promise. The pattern it supports, which TypeSafe calls speculative fan-out, is to ask every question you might need in one request and let code decide which answers matter. Many questions in one call covers when that is worth doing and when it wastes tokens.

What it costs and where the limits are

TypeSafe prices Jev at $0.042 per million input tokens, which is $42 per billion, and output tokens are free. The current model is jev-1.13.0, released 15 September 2026; the aliases jev-latest and jev-preview both point to it. A request may carry 64k tokens, of which the state plus the longest question may use 32k. Rate limits are 250,000 tokens per second and 1,200 requests per minute. English is the primary training language [3].

One caveat comes from TypeSafe itself. As MarkTechPost reported on 19 September, TypeSafe says it cannot prove the price is unsubsidised [7]. A launch price for a model whose architecture is undisclosed may change. Plan for the number to go up and treat any saving you compute as the saving at today's price. The arithmetic, the error codes, and the SDKs are in Jev pricing, rate limits and context window.

Where Jev is weak

TypeSafe publishes a page for jev-1.13 called model jaggedness, and it is the most useful page in the docs. In plain words, the model: reads questions literally; does not count reliably, with error growing as the count grows; cannot reliably judge whether two numbers are near each other; is weak at numerical calibration on Score levels; reads dates as text rather than as ordered quantities; answers double negatives and indirect questions less reliably; loses accuracy as the state grows with content unrelated to the decision; can be moved by adversarial content placed in the state; and is not trained to generate text [6].

Each of those has a mitigation, and most of them are the same mitigation: do the counting, the comparing and the date arithmetic in code, put the result in the state as a plain fact, and ask Jev only the judgment that code cannot make. Where Jev is weak: the jaggedness list goes through all nine.

Jev vs a language model

The decision rule we use is short. If the set of possible answers is known before the request is made, and the decision repeats at volume, it is a Jev question. If the answer needs a written reason, a new option that was not on the list, or any generated text, it is a language model task. Many features need both: Jev decides, the language model writes. TypeSafe's own coding-agents page says the same thing from the other side, that 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 statement verification [16].

On speed and cost, TypeSafe reports 70 to 500 milliseconds end to end against 3 to 329 seconds for the frontier language models in its comparison, and states "40x-200x faster" [1]. Its headline benchmark has Jev finishing one workflow decision in 0.114 seconds for $0.000081, against GPT-5.6 Terra at 8.566 seconds for $0.013880, which TypeSafe reports as "193.6x faster and 444.6x cheaper" [7]. TypeSafe's own capabilities team wrote those workflows. On accuracy, DataCamp 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, with 0 percent structured-output errors for Jev against 45.5 percent for Claude Haiku 4.5 [8]. Those are TypeSafe's workflows too. Read together, the honest summary is: on TypeSafe's own tasks, Jev is close in accuracy to the mid-range language models, less accurate than the best ones, and far faster and cheaper than all of them. Jev vs a language model goes through the rule and the figures.

Jev vs a classifier you train yourself

Before Jev, the standard answer to a repeated classification problem was to train a small model on your own labelled data. That is still the right answer in several cases: when you have a large volume of labelled examples, when the data cannot leave your network, when the system has to work offline, when the text is mostly outside English, or when the decision is numeric. Jev is a hosted API with English as its primary language, and every one of those conditions works against it [3].

The one comparison figure available is from the jevals README, which cites JevBench (a benchmark whose owner we have not verified) at 83 to 87 percent on Banking77 and CLINC150 [10]. Both are intent-classification benchmarks, which is the task a trained classifier does, and the figure is TypeSafe's own. Jev vs a fine-tuned classifier or a small model sets out when to train instead.

What third parties found

Three teams built on Jev in its first week and published what they measured. LangChain ran five weather-agent cases, 100 repetitions per judge per case, against a human-labelled reference. On the binary pass question, Jev agreed with the reference 100 percent of the time, GPT-5.6 Terra 99.8 percent, GPT-5.6 Luna 96.4 percent and Claude Sonnet 4.6 80.0 percent. Jev's mean per-case variance on the quality score was 0.0000149; Luna's was 433 times higher, Terra's 913 times higher, and Claude's 92 times higher. The full run cost $0.34 with Jev and $28.17 with Claude Sonnet 4.6. The authors call the results "promising, but early" and "observational, not evidence", say the experiment "cannot tell us why Jev's scores varied less", and warn that "low cost can amplify mistakes" [9]. Five cases is a small set, and they say so.

Openlayer released jevals, an MIT-licensed library in alpha, which runs agent evals and guardrails as one Jev request per trace. On Openlayer's own benchmark, Ragas on GPT-4.1-mini used 6 language model calls plus embeddings per sample at $2.60 per 1,000 samples and 22 to 35 seconds for 20 samples; jevals on Jev used 1 request per sample at $0.03 per 1,000 and 0.8 seconds for 20 samples, with Jev latency at a median of 244 milliseconds and a 95th percentile of 371 milliseconds [10]. Browser-use built a browser agent on Jev that reads a structured element table instead of screenshots and decides the action and target in one request; on six alternating runs of one Google Flights task, the median fell from 9.45 seconds to 7.09 seconds and browser protocol calls from 1,092 to 101. Browser-use says that is three repeats of one task and no general benchmark. We covered both in AI News: jevals and Jev Ultrafast.

Where Reveneau fits

We generate all of our code, and a large eval suite written from the specification has to prove every change before it is released. Some of those checks have a deterministic answer: a test passes, a schema validates, a migration holds. Those never touch a model and never will. The rest used to need a language model as judge: does this change match the acceptance criterion as written, does this diff stay in scope, did the agent's trace follow the plan, does this generated text follow the instruction. Each of those is now a Noul or a Score question to Jev, with the rubric written into the criteria. A grade below the threshold fails the change. A grade in the uncertain band goes to a person, and that person's label is kept so we can re-check the grader later.

On our own suite, measured against our previous grader, the run is ten times faster. We will not attach a dollar figure or a defect rate to that, because we have not run the experiment that would let us say it, and a consultancy whose whole pitch is verification should not publish numbers it cannot show the working for. What we will say is what changed in practice: the grading step used to be the slowest part of the suite, and it is now one of the fastest, which means the suite runs more often and a failing change is caught sooner. How Reveneau uses Jev describes the setup in detail, evals with Jev is the how-to for your own suite, and eval-driven development is the practice it sits inside. If you are deciding whether a decision model belongs in your product, Jev in production covers the engineering and decision models for product teams covers the product side. If you want to talk it through, contact us.

The one-paragraph summary

Jev is a hosted model that answers fixed questions about text with calibrated probabilities, at $0.042 per million input tokens, in under half a second on TypeSafe's figures. It fits decisions whose answers are known in advance and repeat at volume, and it fails, in ways TypeSafe documents, at counting, comparing numbers, reading dates, handling negations, and anything that needs a sentence written. Use it for the fast decisions, keep a language model for the slow ones, keep deterministic checks deterministic, and set a different threshold for every action according to what a wrong answer costs.