TypeSafe AI Explained: What Jev Actually Checks

A lot of production LLM traffic is not writing at all. It is a decision dressed up as one: which category does this fall into, how urgent is this, does this answer contradict that one. Asking a full chat model to generate a word and then parsing that word back out is a strange way to answer a yes-or-no question, and it is slow and expensive for what it actually accomplishes. TypeSafe AI built a different kind of model for exactly this category of problem, called it a System One model, and named its first one Jev. This is what Jev is, what it is asked to decide inside llm11's routing pipeline, and where TypeSafe AI's own claims about it should and shouldn't be taken at face value.

What "System One model" means as a category

The name is a direct reference to Daniel Kahneman's distinction, from his book Thinking, Fast and Slow, between System 1, fast, automatic, intuitive judgment, and System 2, slow, deliberate, effortful reasoning. The framing has been widely used since to describe two different modes of decision-making, and The Decision Lab's summary of the distinction is a good plain-language reference if you want the underlying psychology rather than the AI analogy built on top of it.

Applied to AI systems, a System One model is one that returns fixed, typed answers to a fixed set of questions in a single pass, with a calibrated confidence score, rather than generating open-ended text token by token. Feed it a state and a set of questions like "which of these four categories applies" or "how confident are you that this needs escalation," and it returns structured answers with numbers attached, not prose you then have to parse back into a decision. That is a meaningfully different job than what a general chat model does, even though both are, underneath, neural networks trained on data. One generates; the other decides.

What Jev is asked to decide inside llm11

Inside llm11's request pipeline, Jev is the default triage backend, the thing that answers three questions on every request before a model generates anything:

Which candidate model in the pool should answer this request. Given a pool of models at different price and capability points, Jev picks the one it judges can handle the specific request in front of it, which is the actual routing decision that determines cost.

How critical this particular request is. Not every request carries the same downside if it goes wrong, and criticality feeds directly into how much verification a request earns after the model responds.

How much verification a request has earned. Schema and groundedness checks run on everything regardless, but heavier checks, cross-model comparison, resampling, cost real money and time to run, so Jev's confidence and criticality scores are what decide whether a given request gets the light check or the full ladder.

All three of these are typed decisions with a fixed answer space, which is exactly the shape of problem a System One model is built for and exactly the shape a general LLM handles clumsily, by generating text and hoping it parses cleanly into one of your allowed options.

Why a typed decision model is arguably the better fit here

A general chat model asked "which of these four categories applies" has to generate a token sequence that, if everything goes well, matches one of your four options exactly. If it doesn't, you need a retry loop, a schema-constrained decoding layer, or a parser that guesses at what the model meant: real infrastructure built to work around a mismatch between the tool and the job.

A model that is typed by construction cannot return an out-of-range answer, because the answer space is declared up front rather than inferred from generated text. That removes the parsing step and the retry loop entirely, and because there is no token-by-token generation, latency stays close to flat across however many questions you ask in one call, rather than growing with output length the way chat completions do. Whether that advantage holds up for your own traffic is worth testing rather than assuming, but the argument for a purpose-built decision model beating a general LLM at this narrow job is reasonable on its face: it is a smaller, more specific tool built for a smaller, more specific job.

The part that actually makes triage decisions automatable is calibration: a confidence score that behaves like a real probability rather than a number a model reports about its own certainty because it was asked to. A verification pipeline that gates expensive checks on a confidence number is only as good as that number's honesty. Gate spend on a score that doesn't track reality and you have built, in TypeSafe AI's own framing on its published Jev materials, something closer to a random spend generator than a cost control. What a confidence score actually measures, and what "calibrated" means as a testable claim covers this distinction on its own terms.

Can a System One model hallucinate?

This is worth answering directly, with the right scope rather than either dismissed or oversold. According to TypeSafe AI's own published materials on Jev, the model cannot hallucinate in the sense that matters for its own output: because Jev's answers are typed and drawn from a fixed set of options declared in the request, there is no free-text generation step in which it could produce a plausible-sounding but false claim. TypeSafe AI describes this as guaranteed schema matching, a structural property of the output format, not a claim about the model's judgment being infallible.

That is a claim about Jev's own typed decisions specifically. It says nothing about whether the model Jev routes a request to will answer that request correctly. The answer a chosen model writes back is ordinary free-text generation, and it can be wrong in all the ordinary ways an LLM answer can be wrong. That is precisely why llm11 runs a verification ladder on the generated answer regardless of which backend made the routing decision. The longer explanation of what "no hallucination" can and cannot mean for a router covers why this distinction matters more than it might first appear.

What TypeSafe AI publishes, and how llm11 treats those numbers

TypeSafe AI's own blog post introducing System One models and Jev states specific figures: a 70 to 500 millisecond end-to-end response time, $0.042 per million input tokens with output unmetered, and calibrated confidence scores where higher stated confidence tracks higher actual accuracy. Tom's Hardware, reporting on that same announcement, cited the vendor's claim of roughly 193 times faster and 445 times cheaper than a frontier LLM for the same class of decision.

Figures compiled from TypeSafe AI's blog post introducing System One models and Jev and Tom's Hardware's report on the announcement. None of these numbers are independently verified by llm11.

Every one of those is a vendor's own published claim, treated here as exactly that. llm11's own page on Jev and TypeSafe AI keeps the same framing, stating plainly that Jev's picks land roughly at parity with frontier models rather than clearly ahead of them, and that the interesting property is the calibration of its confidence scores, not a raw accuracy edge. That is a more modest claim than "faster and cheaper and better," and the one llm11 is willing to stand behind.

TypeSafe AI's founder, Diogo Almeida, has described the motivation behind System One models in terms of a gap he saw in production LLM use:

"I thought maybe chat models would lead to AGI, but despite the hype it became obvious to me that there was something really big missing."

Source: Diogo Almeida, founder of TypeSafe AI, on TypeSafe AI's blog announcing System One models and Jev

The gap he points to is automation: chat models generate text a person reads, but a lot of production software needs a decision a program can act on directly, not a paragraph someone has to interpret. That is the gap a typed, calibrated decision model closes.

Why llm11 doesn't depend on Jev being available

TypeSafe AI is a single vendor, recently launched, and Jev is one implementation of an interface llm11 defines rather than a hard dependency the product is built around. If Jev is unavailable, slow, or priced out of reach, llm11's triage layer falls through automatically to its own heuristic decision engine, and it does not fail the request or pretend Jev made the call. The heuristic is intentionally more conservative: it caps its own confidence lower, which routes upward more often and costs more than Jev would for the same traffic, but it never throws and never depends on a network call to a third party. Every receipt states outright which backend, Jev or heuristic, actually decided a given request. The system one router page compares this approach against three other ways a router can decide, the category explainer already on this site covers the System One concept in more depth, and the longer piece on where "System 1" comes from covers Kahneman's original distinction that the name borrows from.

The cost angle of getting this decision right

None of this matters if the routing decision itself is bad, since a fast, well-calibrated triage layer only pays for itself if the requests it sends downstream actually land on the right model. The broader cost optimization playbook on this site covers why model selection is usually the single biggest lever on an LLM bill, and a decision layer built for fast, typed, high-volume calls is what makes running that decision on every request affordable in the first place, rather than a cost center you'd have to ration.

Frequently asked questions

What is a System One model?

A model that answers fixed, typed questions in a single pass with a calibrated confidence score, instead of generating open-ended text the way a chat model does. The name references Daniel Kahneman's System 1 and System 2 framing of fast, intuitive judgment versus slow, deliberate reasoning.

Is Jev a replacement for a chat model like GPT or Claude?

No. Jev answers structured decision questions, not open-ended writing tasks. In llm11's pipeline, Jev decides which chat model should answer a given request and how much verification that answer needs; a full chat model still does the actual generation.

Does TypeSafe AI's claim that Jev "can't hallucinate" mean llm11's answers are guaranteed correct?

No. That claim is specifically about Jev's own typed decisions being drawn from a fixed, schema-guaranteed set of options, not about the free-text answer a chosen model writes afterward. That answer can still be wrong the way any LLM output can be wrong, which is why a verification pass runs on it regardless of which backend made the routing call.

What happens if TypeSafe AI's Jev goes down or becomes unavailable?

llm11's triage layer falls through automatically to its own built-in heuristic decision engine, which needs no network call to TypeSafe AI and never fails outright. It is more conservative than Jev, so it routes upward more often and costs somewhat more, and every receipt states plainly which backend, Jev or the heuristic, actually made the routing decision for that request.

Are TypeSafe AI's speed and cost figures for Jev independently verified?

No, and llm11 does not present them as such. The 70 to 500 millisecond latency, the per-token pricing, and the reported multiples against frontier LLM costs all come from TypeSafe AI's own published materials or third-party reporting on those materials, and this post treats them explicitly as vendor claims rather than figures llm11 has benchmarked itself.