Jev: A System One Model

Jev has no paper, model card, or published architecture. This post draws on TypeSafe's launch post and documentation, press coverage from September 15 to 19, 2026, the three most-watched explainer videos, and a write-up by Rajesh Beri (September 20, 2026) that collects several community evaluations. All diagrams are original. The interactive runs on simulated data tuned to one of those evaluations; it is not Jev output. Sources retrieved September 27, 2026.

Key Takeaways

Software wants decisions, not essays

An agent receives a request. Before it does anything useful, it must decide which tool to call. A support system receives a ticket and must pick a queue. A chatbot drafts a reply and must decide whether it is safe to send. None of these steps needs a paragraph. Each needs a typed answer, fast, and an honest sense of how likely that answer is to be right.

Today most of these small decisions go to a large language model. You ask in prose, wait a few seconds while it writes, parse the text, and pay for every output token. If you want a confidence, you ask for that too, and the model writes a number that sounds right. Nothing guarantees that its “90%” answers are right 90% of the time. The GPT-4 technical report measured this drift: post-training made the model more useful and its probabilities less honest.

In mid-September 2026, a startup called TypeSafe came out of stealth with a model that does only the small decisions. It is called Jev.

What Jev is

TypeSafe borrows its framing from Daniel Kahneman’s two systems: fast, intuitive judgement (System 1) and slow, deliberate reasoning (System 2). The last two years of frontier AI pushed hard on System 2. Reasoning models think for thousands of tokens before they answer. TypeSafe calls Jev a System One model: it does not reason, write, or chat. It makes the snap decision.

The founder, Diogo Almeida, worked at OpenAI on RLHF, InstructGPT, ChatGPT, and GPT-4, according to press coverage of the launch. The company raised a $40M seed round led by DCVC. The pitch is short: unstructured state in, typed probabilistic decisions out.

A call to Jev carries two things: the state (text or data describing the situation) and a set of questions defined in advance. Each question has one of three types.

Because every answer is a typed value checked against the schema, it cannot be malformed. That is what TypeSafe’s “0% hallucination” claim means: an answer can be wrong, but it cannot be off-schema.

The three most-watched explainer videos, from Caleb Writes Code, Krish Naik, and Theo (t3.gg), all stress what Jev is not: a replacement for LLMs. Theo offers a good rule of thumb. If a person would make the decision instantly, it is a Jev decision. If they would need to think, it belongs to a reasoning model.

Fast and nearly free

Speed and cost are the headline numbers in almost every piece of coverage.

• Latency. TypeSafe quotes 70 to 500 ms end to end, and 40x to 200x faster than LLMs at the same level of frontier intelligence. Its launch post credits a new architecture and a parallel sampler that answers everything in a single query.
• Price. $0.042 per million input tokens. Output is free, because a handful of typed values is, in TypeSafe’s words, “too cheap to meter”. LLM APIs usually charge several times more for output than for input.

Free output changes how you ask. A 1,000-token ticket costs about $0.000042 whether you ask one question or twenty, and TypeSafe says the questions in a call are answered in parallel. Its docs call the resulting pattern speculative fan-out: send many questions in one call, including ones you might not need, and let your code decide which answers matter.

TypeSafe’s headline benchmark numbers (“193.6x faster, 444.6x cheaper”) come from its own workflow evaluations. The company notes that its own team wrote them and that the results likely sit at the high end. The outside tests below look at what the 444x actually measures.

Where Jev sits next to an LLM

The videos spend most of their time on one question: where do you put Jev in a system you already have? Routing dominates. Krish Naik also shows a second placement, as a guardrail.

As a router. An agent has several tools: a SQL database, web search, a Python sandbox. Deciding which one to call is usually an LLM call of its own. In Krish Naik’s demo, Jev gives each tool a probability instead (SQL 0.96, Python 0.02, the rest smaller), and the agent calls the top one directly. The same pattern routes a request between agents, or a ticket between queues.

As a guardrail. After an LLM drafts a reply, a yes/no question (“safe to send?”, “does this answer the question?”) decides whether to send it or regenerate. A guardrail runs on every response, so a check that costs milliseconds and almost nothing is attractive.

Both placements share a detail that the demos mostly skip. The router has to decide when Jev’s answer is good enough to act on. The usual rule is a threshold:

Set $\tau = 0.95$ and you expect at most 5% errors among the requests Jev handles alone. That promise holds only if Jev’s probabilities are calibrated, meaning its 0.95 answers are right at least 95% of the time. This is why TypeSafe sells calibration, not just speed: without it, the threshold is a guess.

RLCD: training for honest probabilities

TypeSafe names its training objective RLCD, Reinforcement Learning for Calibrated Decisions. Its launch post places it next to two familiar objectives. RLHF optimizes for what human raters prefer. RLVR, the recipe behind reasoning models, optimizes for answers a program can verify. RLCD optimizes for probabilities that are epistemically honest: when Jev says 0.9, it should be right nine times in ten, and similar inputs should get similar answers.

One practical detail: Jev’s confidence field is not the probability of the top answer. TypeSafe’s docs describe it as a statistic computed from the distribution. In an example discussed by TuringPost, the top option held 0.84 while the reported confidence was 0.596, because a second option held 0.159. If you build a threshold, build it on the probabilities.

What the first outside tests found

The explainer videos repeat TypeSafe’s numbers; none of them tests the calibration claim. Within a week of launch, several people did, and published their results on GitHub. Rajesh Beri collected them in one write-up. They are small, fast, and mostly on synthetic data, so treat them as early evidence rather than a verdict.

One question versus five

The open-source jev-phishing-bench (September 17) ran phishing detection on 2,000 synthetic emails (1,000 for fitting, 1,000 for evaluation) and compared Jev with Claude Haiku 4.5.

Asked one broad question (“is this phishing?”), Jev scored 62.6% against Haiku’s 81.3%. It caught 43.2% of the actual phishing emails and falsely flagged 18.0% of legitimate ones.

Split into five narrow questions (for example, does a link point to a URL shortener or free hosting, and does the sender use a free email address) and combined by a logistic regression, Jev reached 95.0% against Haiku’s 93.2% on the same setup, a gap that is not statistically significant. The catch is the regression: it was fitted on 1,000 labelled emails. In Beri’s words, the 95% is “Jev plus your labelled data plus a regression you maintain.” Fan-out is cheap with Jev. Turning five answers into one good decision is still your job.

Calibration off the benchmark

Calibration is usually summarized as expected calibration error (ECE): the average gap between claimed confidence and actual accuracy, where 0 is perfect. On public benchmarks, Jev’s ECE came in at 0.024 to 0.032, which is good. A study on September 19, run through Vercel’s AI gateway, used 900 synthetic support tickets unlike those benchmarks. There, ECE rose to 0.107, about 4.4 times the noise floor. Choice and Score answers were overconfident. Yes/no answers were underconfident.

The worst case is the most instructive. On questions that depended on an internal policy missing from the ticket text, Jev was right 44.7% of the time while assigning its answers an average probability of 0.74. No training objective can calibrate a model on information it was never shown.

A pre-registered study published as priorbench/jev (September 20) found a related pattern over 5,721 calls. Jev scored 95.9% zero-shot on its 400-item benchmark, but accuracy above the threshold stayed flat from 0.50 to 0.95, then jumped to 100% at 0.99. The 0.99 band covered 60.2% of traffic. In practice, confidence below 0.99 did not separate good answers from bad.

Try it: the router with the measured miscalibration

What does overconfidence do to the router from the diagram above? The simulation below routes 4,000 requests. Jev sees every request first; anything below the threshold escalates to the LLM. The overconfident setting uses the refit temperature the September 19 study measured for Choice answers (3.29).

With overconfident probabilities, the router looks excellent on cost and latency, because it hands most requests to Jev. The errors are hidden in the gap between claimed and delivered accuracy. The checkbox applies the classic fix, temperature scaling: divide the logits by one constant fitted on labelled data (the study fitted 3.29 for Choice answers). It repairs what Jev claims without changing what it picks, and it needs labelled data from your own traffic. That is the very step a calibrated-out-of-the-box model promises to remove.

Cost, and what “444x cheaper” measures

The cost advantage is real, but smaller than the headline suggests. TypeSafe itself discloses that its 444.6x figure measures agreement with the average of two frontier models (GPT-6 Astra and Fable 5.1), which is a different thing from correctness. A separate test by Good Start Labs, over 6,003 rubric checks and published by Langfuse, measured agreement with Claude instead. DeepSeek V4.1 Flash agreed 93.5% of the time and Jev 91.5%, at $260 per million verdicts against Jev’s $160. On that test DeepSeek V4.1 Flash cost 1.6 times as much as Jev, far from hundreds. TypeSafe also says it cannot prove its price is unsubsidized.

Where Jev fits

Put the pitch, the coverage, and the tests side by side and a narrower, still useful picture emerges.

Where it fits. High-volume, typed decisions on text: tool and agent routing, ticket triage, guardrail checks. It fits best where categories change often and a slower fallback exists for low-confidence cases. The classic alternative is a fine-tuned classifier plus temperature scaling. That recipe is cheap and well calibrated in-distribution, but it needs labelled data and retraining whenever the label set changes. Jev offers the same shape without the training step.

Where it does not fit. Anything that needs generated text or reasoning; that stays with the LLM. Image inputs, which Jev does not accept yet. Decisions that depend on context missing from the state. And any router that trusts a threshold below about 0.99 without first checking calibration on its own data.

What would change the picture. A technical report with calibration metrics across domains; tests on real rather than synthetic traffic; and evidence that the price holds without a subsidy. Until then, treat Jev like any new classifier: shadow it against labelled data, fit a temperature if needed, and let measured accuracy set the threshold.