JEV: a model that only decides

A surprising amount of what companies use large language models for has nothing to do with writing. Is this support ticket about billing or about a bug? Does this transaction look like fraud? Should this alert wake someone up at three in the morning? We ask a model that can write poetry to answer with a single word, then we write code to parse that word, retry when it comes back as a paragraph, and hope the format holds on the next model version.

JEV, released by TypeSafe AI on 15 September 2026, is built around that observation. It is the first public model in what the company calls System One models, and it does exactly one thing. You give it some state and a set of questions with answers you have already defined, and it gives you back a choice or a score for each question, along with a probability.

Who made it

TypeSafe AI was founded in 2024 and spent about two years in stealth before the launch. The chief executive, Diogo Almeida, previously worked at OpenAI on reinforcement learning from human feedback. Erik Gafni is CTO and Sasha Sheng, who worked in research engineering at Meta's FAIR lab, is COO. The name System One reads like a nod to Daniel Kahneman's fast, intuitive mode of thinking, and that is a fair description of what the model is trying to be.

How it works

The input to JEV is unstructured program state, which can be a ticket, a log excerpt, a chunk of JSON or whatever else describes the situation, together with a list of typed questions about it. A question might ask the model to pick one of a fixed set of categories, to produce a score, or to answer yes or no. The model evaluates all of the questions in one parallel pass and returns every answer at once, each with a calibrated confidence.

Because the answers are chosen from a set you declared before the call, the output always matches your schema. There is no string to parse and no way for the model to invent a category that does not exist. TypeSafe describes the approach as Reinforcement Learning for Calibrated Decisions, and the emphasis on calibration is the part I find most interesting. A probability you can trust lets you set thresholds in code, send the uncertain cases to a person or to a bigger model, and measure the trade-off explicitly.

Skipping text generation is also where the speed comes from. Responses come back in somewhere between 70 and 500 milliseconds, which puts it tens to a couple of hundred times ahead of the big LLMs on this kind of bounded question. Pricing follows the same logic. At launch it costs $0.042 per million input tokens, and output is free, since there is almost no output to speak of.

Where it fits

The obvious uses are the ones that already run through LLMs today with a lot of glue code around them. Routing and triage, scoring leads or risk, moderation and guardrail checks in front of a more expensive model. Anything where the question is bounded and the answer feeds straight into an if statement.

In the kind of systems I usually work on, I can see it sitting in the alerting path of an IoT platform. When a device reports something odd, the last hour of its telemetry and a bit of context about the site could go in as state, with a single question about whether this looks like a sensor fault, a real event worth acting on, or noise. At a few hundred milliseconds and a fraction of a cent per call, that is cheap enough to run on every alert, and the probability gives you a natural place to draw the line for waking someone up.

I have not put JEV in front of real traffic yet, so take all of this as first impressions from reading about it and poking at the idea. A few things do make me cautious.

What to be careful about

The first thing I would want is my own numbers. The accuracy figures floating around so far come from TypeSafe's own test setups, and as far as I can tell they measure how often JEV agrees with other big LLMs. That is a reasonable start, but I would not trust it for a real decision until I had run it against a few hundred cases that a person labelled by hand.

The idea that JEV cannot hallucinate also needs a careful reading. It cannot return a value outside your schema, which is a real and useful guarantee. It can still pick the wrong option with high confidence, and when it does, you get a number and no explanation of how it got there. For debugging, and for any regulated setting where you need to justify a decision, that missing rationale is a genuine gap.

From what I have seen so far it also takes instructions very literally, cannot count reliably, struggles with arithmetic and date comparisons, loses accuracy on questions that need several steps of indirect reasoning, and degrades when the state is padded with lots of irrelevant material. Most of that is unsurprising for a model designed to answer in one fast pass, and it suggests keeping the state tight and the questions direct.

Access is the last practical point. The direct API is in early access behind a waitlist, although the model is already available through Vercel AI Gateway, OpenRouter and Cloudflare AI Gateway. The request formats differ slightly between these providers, so it is worth pinning one and testing against it before copying examples around.

Why it matters anyway

Even with those caveats, JEV is a useful correction to how we have been using language models. Plenty of production systems need a fast, cheap and well calibrated decision thousands of times a day, and until now the only way to get one from a large model was to ask for text and hope. A model whose output is typed by construction and whose confidence means something is a good fit for the boring, high-volume decisions that make up most of a real system.

I expect the interesting architectures of the next year or two to mix both kinds. A System One model handles the thousands of small, bounded calls, a general LLM takes the few cases that genuinely need reasoning or an explanation, and the probability from the first decides which is which. I plan to try exactly that on an alerting pipeline and will write up what I find.