Jev cannot hallucinate. Its own docs explain the catch.
TypeSafe AI came out of stealth on 15 September with $40 million led by DCVC, a reported valuation near $200 million, and a model called Jev that the company says has a 0% hallucination rate. It went to the top of Hacker News and collected over 400 comments in a day.
The 0% number is real. It also means something narrower than most people reading the headline assumed, and TypeSafe says so in their own documentation.
What Jev does
Jev stops generating text. You send it a block of unstructured input and a set of named questions, and it answers all of them in one pass. There are three answer shapes:
- choice, which picks one of your named options and returns a probability for each
- score, which places the input on a scale you define by describing each level
- noul, which returns a single probability that a statement is true

A support ticket goes in. Out comes department: billing at 0.84, frustration: 1.035 on a three-level scale, is_urgent: 0.999. No prose, no JSON parsing, no retry loop. Input costs $0.042 per million tokens and output is free. The choice type caps at 255 options.

That is a classifier with a hosted API and a schema you define per request. TypeSafe calls it a "System One Model," after Kahneman's fast intuitive thinking.
What the guarantee covers
Jev picks from a list you supplied, so it cannot return a value outside that list. It cannot invent a department that does not exist, emit malformed JSON, or call a tool you never defined. That is the whole of the 0% claim.
TypeSafe's documentation states the limit plainly: "Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct."
A model that always returns one of APPROVE, DENY or ESCALATE can return APPROVE when the answer was DENY, confidently, every time. Nothing in the type system catches that. You have traded an invalid answer for a wrong one, and a wrong one costs the same.
Diogo Almeida, TypeSafe's CEO, conceded the related point about speed in the Hacker News thread, saying the comparison against LLM latency is "problematic since output tokens are not comparable." He was answering his own marketing copy.
Constrained decoding already did this
Guaranteed schema-valid output from an LLM has shipped since 2024. OpenAI's Structured Outputs compiles your JSON Schema into a grammar and masks every token that would break it, which took them from roughly 93% schema match to 100%. Outlines compiles regex and JSON Schema into finite state machines. XGrammar hides the mask computation behind the GPU matmuls and adds close to nothing in the common case. llama.cpp has shipped GBNF grammars for longer than that.
So "the model can never produce an invalid value" is table stakes, available in open source, at near-zero latency cost, on top of whatever model you already run. Paying for it as a headline feature is paying for something you have.
The benchmark measures agreement, not correctness
TypeSafe's published comparison scores Jev against the average of two frontier models' own outputs, GPT-6 Astra and Fable 5.1. That measures how often Jev agrees with them. It does not measure how often any of the three is right.
Four workflows are published. TypeSafe's capabilities team chose them. The runs came from laptops on the US West Coast. The wikiracing comparisons reportedly used non-reasoning modes, which weakens the baseline. Nobody outside the company has reproduced the headline figures of 193.6x faster and 444.6x cheaper.
The most useful independent test so far is Mike Taylor's at Every.to, who ran 1,709 judgments through it. Median response of 0.35 seconds against Claude Fable's 8.83, roughly 25 times faster and 580 times cheaper. Jev also missed a writing defect that Fable caught. His verdict was that wider validation would be needed before production use. A CTO quoted by TechCrunch found it 10 to 20 times cheaper than Gemini and slightly less accurate, with better confidence scores.
Cheaper, faster, slightly worse at the answer, better at knowing when it is unsure. That is a real trade and a defensible one.
The part that would matter
Calibration is the interesting claim and the one with no evidence behind it.
A calibrated probability means that when the model says 80%, it is right 80% of the time. If that holds, you can build routing on it: execute automatically above 95%, send 60 to 95 to a human, escalate the rest. For an agent running inside a client's business, that turns a black box into something with a failure mode you can price. The thing that loses an account is a confident wrong action taken silently, not a slow one.

TypeSafe trained for this with a method they call Reinforcement Learning for Calibrated Decisions. They have published one sentence about it. There is no paper, no expected calibration error, no Brier score, no reliability diagram. For a company whose pitch is honesty about uncertainty, the absence of calibration numbers is the gap to ask about.
Their confidence field is also derived rather than predicted. The docs describe it as "a statistic computed from the probability distribution the answer already gives you," and the formula is deferred to a cookbook that does not exist yet.
If you want to try it
Run your own labelled set and compute expected calibration error and Brier score yourself. Check both per class rather than in aggregate, because aggregate calibration hides overconfidence on the rare classes where the expensive mistakes live.
Compare against the cheap baseline, meaning a small fine-tuned classifier or a small model with grammar-constrained decoding. Comparing against a frontier reasoning model on a routing decision flatters everything.
An afternoon on one real classification task from live work will tell you more than the launch post did.