Jev, the model that can't hallucinate (but isn't always right)

September 27, 2026

TypeSafe calls Jev a "System One model": you send it a state and a set of typed questions, and it sends back typed answers with calibrated probabilities attached. No text generation, no token-by-token sampling, no free-form output to validate afterward. That's a strong claim in an ecosystem built around parsing strings out of LLMs, so I built here-we-go-jev, a one-page playground and test bench, to see how much of it holds up against a real run instead of the announcement post.

The API in one screen

There's one endpoint, three primitives. choice picks among up to 255 labeled options and returns a probability per option. score places the state on an ordered rubric, 2 to 10 levels, and the answer can fall between levels. noul is a yes/no with a 0 to 1 value and no confidence field. A request can mix all three, and Jev evaluates every question against the state in parallel, one API call instead of one call per classifier. The vendor's own worked example, a support ticket about a failing Stripe integration, answers department, frustration, and is_urgent in a single 392-token call.

The playground wires up every backend behind that same contract: the real model via OpenRouter or TypeSafe's own endpoint, an LLM asked the same questions for a side-by-side baseline, and a Mock that needs no key and can simulate 401, 422, 429, and 529. Point any of TypeSafe's official SDKs at the Mock's base URL and it behaves like the real thing, which made the whole exercise reproducible without spending a cent up front.

"Can't hallucinate" is a narrower claim than it sounds

The training method is called RLCD, reinforcement learning for calibrated decisions, and TypeSafe contrasts it with RLHF (optimizes for human preference) and RLVR (optimizes for verifiable rewards). Because the answer space is fixed in advance, a choice response is drawn from options that exist. It genuinely cannot invent an option that wasn't offered, which is the type of hallucination that breaks a JSON parser.

What it doesn't promise is that the answer is correct. TypeSafe's own docs list nine known failure modes for the current version, jev-1.13: it reads instructions literally rather than the intent behind them, it's unreliable at arithmetic and counting, it compares dates poorly, accuracy drops with double negatives or multi-hop reasoning, a state full of irrelevant detail causes context rot, adversarial content in the state can steer the answer (it's not prompt-injection-proof), contradictory instructions confuse it, and structural invariants can slip: in one of their own examples, P(refund) plus P(not refund) summed to 1.19. Calibration is a property of many predictions taken together; it says nothing about whether any single answer is right.

Testing the one claim that mattered most

A Spanish-language explainer video I'd watched cited a claim that swapping the order of two options in a choice flipped the top answer, sourced to a post on X I couldn't track down. Rather than repeat the claim, scripts/e2-order-sensitivity.ts tests it directly: one choice with three options, all 6 orderings, over 3 states, each combination repeated 3 times. 54 answers total, against the real model via OpenRouter, for about $0.00027.

The top answer never changed with option order across any of the 18 permutations per repeat. But the probabilities did move, and only on the one genuinely ambiguous state in the set: P(book_report) ranged from 0.71 to 0.91 depending on where it sat in the list, and confidence swung from 0.57 to 0.86. Whichever option was listed first picked up extra mass, an effect about 5x the size of the run-to-run noise on the same ordering (at most 0.04, and 0.00 on the unambiguous states). I couldn't reproduce a flipped top answer, so the original claim stays neither confirmed nor refuted, but the probabilities and confidence are exactly the values a team would threshold on for confidence routing. A 0.8 cutoff would act on some orderings of the identical question and escalate others.

What actually changes

Jev doesn't remove the need for evaluation, it moves the question. Instead of "is this valid JSON?", the thing worth checking becomes "is this probability well calibrated for my data?", and that's a harder, more honest question to sit with. The lab notebook in the repo keeps every source labeled, vendor claim, doc spec, video commentary, or measured result, precisely so those categories don't blur into each other the way they do in most AI announcement threads.

Repo: here-we-go-jev on GitHub