On 15 September 2026 TypeSafe AI opened early access to Jev, the first of what it calls "System One" models. The founder is Diogo Almeida, a former OpenAI researcher; according to The Register he co-invented RLHF and worked on ChatGPT. The company left stealth after two years with $40 million in funding.
The question Almeida poses is worth pausing on: models have been superhuman at chat for years, so where is the automation? Most enterprise software does not need a good answer. It needs a decision the next line of code can act on.
How Jev differs from an LLM
Jev does not generate strings. It takes state as input and returns a typed value defined in advance, with a probability for each option. The architecture uses a parallel sampler that produces the whole output in a single query rather than token by token. The training method, which the company calls Reinforcement Learning for Calibrated Decisions, optimises for honest probabilities rather than human preference.
TypeSafe sums the product up in one line: think of Jev as a frontier-intelligence function call — unstructured state in, typed probabilistic decisions out.
The difference is clearest side by side. Ask an LLM whether a customer is likely to churn and you get a paragraph starting "based on the available information, I believe…", which you then have to parse. The decision model returns something you can use as is:
{
"churn_level": "HIGH",
"probability": 0.87
}Because the schema is declared up front, the application branches, routes, scores or extracts directly from the result, with no text-parsing layer in between.
Another example described by The Register: routing a customer request to the right department, with a confidence percentage per option. The company also had Jev play Doom from game state data to show it can drive a real-time system.
Sources: TypeSafe AI — Introducing System One Models & Jev · The Register · AI News
The numbers the vendor publishes
- Response times of 70–500 milliseconds, which the company frames as 40–200 times faster than frontier LLMs. In the demo The Register cites: 0.114 seconds against 8.566 seconds.
- $0.042 per million input tokens, with output tokens free.
- On multi-step workflows, the company reports 193.6 times faster and 444.6 times cheaper.
To their credit, TypeSafe hedges these numbers themselves. They write that the gains are at the higher end of what to expect in the real world, that the eval was built by people on their own model capabilities team so some bias could exist, and that the reference answers average OpenAI and Anthropic models, which biases the comparison towards those two.
In other words: no independent evaluation yet. But even heavily discounted, the latency gap matters for work that runs thousands of times a day, where several seconds per model call simply rules the approach out.
Being straight about "no hallucinations"
The headline claim is that Jev cannot hallucinate. Read it precisely: the output always conforms to the declared type. The Register notes plainly that this is not a like-for-like comparison, because the output is structured data rather than natural language.
Schema conformance is also not new. OpenAI's Structured Outputs documentation states that the model "will always generate responses that adhere to your supplied JSON Schema", enforced during decoding. That problem is solved in several places already.
So what is genuinely new about Jev sits elsewhere: latency, cost, and calibrated probabilities. And one thing TypeSafe says on its own site: the model can still get things wrong. Type-safe does not mean correct.
Sources: OpenAI — Structured outputs · TypeSafe AI
Why calibration is the valuable part
Inside a business process, the hard question is not what the model predicts but when the system may act alone and when it must ask a person. A model that always sounds certain leaves you two extremes: trust everything, or review everything.
If the model returns a probability you can trust, a third option appears: set a threshold. Above it the system proceeds; below it the case becomes a task for a human reviewer. That threshold is a business parameter, tuned to the risk of each decision type.
In practice the threshold is rarely a single number. A common split:
- Above 0.95: the system handles it and simply logs the decision.
- Between 0.70 and 0.95: run an extra automated check — against source data or a business rule — before deciding.
- Below 0.70: route to a human reviewer, with the model's suggestion and reasoning attached.
"Trustworthy" here has a technical meaning: of the cases where the model says it is 80% sure, about 80% should be right. That has to be measured on your own data; it cannot be taken from a launch page.
How to fit it into an enterprise application
For an application built on a platform such as Mendix, the integration is straightforward:
- A microflow calls the decision service over REST and receives a typed value with its probability.
- Compare the probability against the threshold for that decision type. Above it, continue. Below it, create an approval task in the workflow, carrying the model's suggestion so the reviewer does not start from nothing.
- Log the input, the decision, the probability, the model version, the threshold in force, and the reviewer if there was one. This is what answers the auditor's questions later.
- Periodically compare automated decisions against real outcomes and adjust thresholds, rather than setting them once and forgetting.
This is also why we keep saying that business logic belongs outside the model vendor's tooling. A decision model is a replaceable service; the process, the thresholds and the log should belong to your application.
A layered pattern: decision model in front, LLM behind
This is not a Jev feature but an integration pattern we find effective. Jev takes state and returns a decision; splitting the tiers and forwarding between them is your application's job.
Take a customer service channel. Every incoming message passes through the decision layer first, which returns an intent with a probability:
{
"intent": "GREETING",
"probability": 0.96
}- Greetings, order status questions, delivery address changes: the application answers from a template or a direct database query, with no large language model call at all.
- Complex complaints or contract terms: hand off to an LLM, with context the first layer has already normalised — request type, customer id, order id.
- Anything the layer cannot classify confidently: default to the tier behind it rather than answering.
That last rule matters more than it looks. The main risk of a layered design is a hard question landing in the fast lane and the customer receiving a meaningless template. Set the threshold so that when the model hesitates, the system takes the more expensive but safer path.
The gain comes from most requests never reaching the large model: lower cost and lower latency for that group. The exact ratio depends entirely on your own mix of requests, so measure it on real data rather than trusting a generic figure.
Where the names come from
The model class is named after Daniel Kahneman's familiar split: System 1 is fast, intuitive thinking, System 2 is slow, deliberate reasoning. Jev targets the first: many small, fast, repeated decisions rather than long chains of reasoning.
Jev itself is named after William Stanley Jevons. The company points at his paradox: more efficient steam engines did not reduce coal consumption, they increased demand for it. They expect machine intelligence to follow the same path — when each decision gets hundreds of times cheaper, software will use far more of them rather than spend less.
Limits worth knowing before you try it
- Jev is in early access behind a waitlist.
- The model generates no text, so it does not replace an LLM for drafting, summarising or answering a customer in words.
- According to AI News, a decision is limited to 255 discrete options, so classification problems with thousands of labels do not fit yet.
- Every performance figure available today comes from the vendor. Before putting it in a live process, measure both accuracy and probability calibration on your own dataset.
For enterprises in Vietnam
There is no rush to change infrastructure. But the direction is worth watching: after years in which every model talked to people, a class of models is appearing that is built for software to read. Work that repeats thousands of times a day — classifying requests, routing files, labelling transactions, extracting fields from documents — is where this class fits best.
The most interesting thing in the announcement is not how many times faster Jev is, since that is the vendor's own benchmark. It is the division of labour: an LLM for complex reasoning; a System One style model for thousands of small decisions with a clear schema; and deterministic workflow and code keeping control of the whole.
That means treating AI as a decision layer inside the process rather than turning the process into a free-roaming agent. In an approval system the model can return the request type, the risk level, a suggested route and any anomaly, each with a probability — while who approves, and in what order, stays with the process.
And whichever model you choose, the value still sits in what surrounds it: confidence thresholds, stopping points for people, and a traceable log. No vendor builds that part for you. If you are building flows like these, see our intelligent automation and AI page.
