On 15 September 2026, a San Francisco company called TypeSafe AI released Jev in limited early access. It is a transformer model that does not write. It takes application state and a structured question, and returns a typed value with a probability and a confidence score — output meant to be consumed by your code, never read by a person.
Within days the API was falling over under demand, roughly 500 open-source projects had picked it up, and a lot of engineers were asking the same question: is this a genuinely different tool, or an inference-cost optimisation with good marketing?
It is worth understanding either way, because the architectural bet behind it is one most teams building agents have quietly been working around for two years.
What it actually does
Jev answers three shapes of question, and nothing else:
- Choice — pick one of a defined set of options.
- Score — rate something against ordered levels.
- Noul — evaluate a yes/no statement.
You define the output space up front. The model returns a value from that space plus a calibrated probability. It does not produce prose, it cannot be prompted into producing prose, and there is no parsing step between the model and your program.
That last point is the whole design. If you have built an agent in the last two years you have almost certainly written this: a carefully worded prompt asking a frontier model to reply with only APPROVE or REJECT, a JSON schema to constrain it, a parser, a retry for when it explains its reasoning anyway, and a fallback for when it returns something outside the enum. Jev deletes that entire apparatus by making the output space the interface rather than a request.
Why it exists
Founder Diogo Almeida was an OpenAI researcher who worked on ChatGPT and contributed to reinforcement learning from human feedback. He left roughly two years ago on a specific thesis: that models were not useful for automation because they were optimising for human language — a capability that is expensive, slow, and irrelevant when the consumer is a for loop.
Jev is that argument made concrete. It is trained entirely on synthetic data using what TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD), and the thing being optimised is calibration — whether a stated 80% confidence is right about 80% of the time — rather than fluency.
The numbers, and who is making them
This is where care is required, because the headline figures and the independent figures are an order of magnitude apart.
TypeSafe's own claims: response times of 70–500 milliseconds, and 40–200× faster and 40–400× cheaper than frontier LLMs, peaking at 193.6× faster and 444.6× cheaper on internal workflows. To the company's credit it says plainly that these are self-run, acknowledges the bias, and notes the gains sit at the high end of what real workloads will see.
What third parties report: a Vercel engineer, Pranit Sharma, described swapping an OpenAI model for Jev and getting results five to eighteen times more quickly with better accuracy. Bryo AI's CTO, Nikhil Mudholkar, put it at ten to twenty times cheaper than Gemini for email classification.
Five to twenty times is a very different claim from two hundred, and it is the one to plan against. It is also still a large number. A classification step that costs a tenth of what it costs today changes which features are economically viable, even if it never approaches the marketing figure.
On pricing, the structure is more interesting than the rate: output tokens are free, and input is priced per billion tokens rather than per million. For a workload that is millions of tiny classifications, that pricing shape matters more than any per-token comparison.
The "cannot hallucinate" claim, examined
TechCrunch reports the model "cannot hallucinate since users define outputs in advance." That is true in a narrow and genuinely useful sense, and misleading if you stop reading there.
What is true: the model cannot return a value outside the space you defined. No invented enum member, no prose where you expected a boolean, no malformed JSON. That class of failure is gone, and it is a real class of failure.
What remains: it can still be wrong. A confidently incorrect REJECT is not a hallucination, it is a misclassification, and it will hurt your users exactly as much. The confidence score is what makes this tractable — you can route low-confidence cases to a human or to a bigger model — but only if the calibration genuinely holds on your distribution, which is the thing no vendor benchmark can tell you.
What this changes
For most teams, not this month. It is limited early access, the API has already buckled once, and there is no published paper.
What it does change is how you should be thinking about a class of work you are currently paying a frontier model to do. Look at your system for steps that are really just a decision: is this support ticket urgent, is this content safe, which of four tools should handle this request, does this document look like an invoice. Those are Choice and Noul questions. They are almost certainly running through a model built to write essays, at essay prices and essay latency.
Three practical consequences:
1. Model routing becomes cheap enough to be default. A fast, calibrated classifier deciding which model handles a request has been the obvious architecture for a while and has rarely been worth the added latency. At 70–500ms it starts to be.
2. Confidence becomes a first-class input to design. If you get a calibrated score with every decision, "escalate below 0.85" is a product rule rather than a heuristic. Design the escalation path before you tune the threshold.
3. Evaluation gets harder, not easier. You cannot read a typed probability and judge it the way you can skim generated text. You need a labelled set from your own traffic and a calibration check. Budget for that, because it is the step that decides whether any of this works for you.
What we do not know
Enough is unpublished that scepticism is the correct posture:
- No technical paper, no architecture, no weights. RLCD is a company name for a method, not a described one.
- External observers suggest it may be built on an open-weight LLM. If so, the performance story is partly a serving and output-constraint story rather than a new model class — still valuable, but a different claim.
- No independent benchmark. Every headline number is TypeSafe's own, and the company says so.
- Trained purely on synthetic data, which tends to be excellent on the distribution it was generated for and brittle just outside it. That is precisely the risk profile that matters for calibration.
The honest summary: an ex-OpenAI researcher has made a specific, plausible architectural bet — that automation wants calibrated decisions rather than language — and shipped something developers are visibly enthusiastic about. The bet is interesting. The evidence for the headline numbers is currently one company's own testing.
If you run high-volume classification today, it is worth an afternoon and a labelled sample of your own traffic. If you are waiting to see whether the calibration survives contact with real distributions, that is also a defensible position, and one we would take on anything load-bearing.