Jev returns decisions instead of sentences
A model that does not write anything
TypeSafe AI opened early access to Jev on 15 September, and the first thing to understand is what comes back. Not a sentence. Not JSON for you to parse and validate. A typed decision, in the shape you declared before the call, with a probability attached to every option.
You hand it a block of state, which can be a plain sentence like "my card was charged twice" or a structured dump of an application's current condition. You ask typed questions against that state. It answers all of them in one pass.
The API is small enough to describe completely
There are three question primitives. Choice picks from a set of alternatives you declare and returns a probability per option. Score rates against ordered levels and returns a continuous value. Noul evaluates a binary proposition and returns the probability that it is true.
The constraint is doing real work. It is also the whole limitation. If your question does not fit one of those three shapes, Jev has nothing to say. There is no fallback to prose, no asking it to explain its reasoning, no writing the migration script instead. A support request might declare a Choice over billing, technical, sales and spam, plus a Score for frustration, and get both back at once.
Why the interface matters more than the numbers
The numbers are the headline and they are striking. Response times between 70 and 500 milliseconds, against the three to three hundred and thirty seconds frontier models take. Input at $0.042 per million tokens, with output unmetered because there is barely any output to meter. On TypeSafe's own workflow evaluations Jev lands at 67.8% agreement with the reference answers at about $0.0004 per case, roughly level with GPT-5.6 Terra at around 76 times the cost and 25 times the latency.
The speed is a consequence of the design rather than the point of it. Jev produces no tokens in sequence, so it is not autoregressive: it does not generate one token and condition the next on it. All the answers are computed in a single forward pass, which is where both the latency and the parallel question answering come from.
The practical effect is that a decision can now live inside a loop. TypeSafe's own demonstration has Jev playing Doom by reading a text description of the game state about ten times a second. The game is a stunt and a scripted bot would beat it, but it shows a general model running somewhere a three second call is impossible.
Where the caveats start
The claim travelling fastest is that Jev cannot hallucinate. Read it precisely. Jev cannot return a value outside the schema, and it cannot make a type error, because the valid outputs were fixed before the call. That part is structural and a single counterexample would falsify it.
That is not the same as being correct. Jev can still pick the wrong option from your list. Calling the sky red is a mistake rather than a hallucination, and the distinction matters more to marketing than to production, where a wrong decision is just wrong. Several people said so within hours of the launch.
The benchmarks carry a second caveat. Every figure above is vendor-reported. The reference answers in the workflow evaluation come from averaging two other models rather than from operational ground truth, TypeSafe designed the workflows itself, and the company states that the largest speed and cost advantages are probably at the high end of what you would see in practice. Nobody has reproduced the numbers independently yet.
The objection worth knowing about
The sharpest technical criticism is that this may not require a new architecture at all. A standard model can already answer with a single constrained token: prefill the response up to where the choice goes, restrict the sampler to your declared options, and generate once. Several questions batch into the same forward pass. Most of Jev's speed arrives that way, which makes the moat thinner than the announcement suggests.
Where that argument is weaker is training. A model optimised only for structured decisions should be better at them than a general model with a prompt wrapped around it, and TypeSafe constrains the competing models through an adapter precisely to keep the comparison honest.
What I would use it for
Not chat, not code generation, not anything where a person reads the output. The fit is where the possible answers are known up front and the same decision is made over and over at volume. Classify this row. Score this review. Decide whether this trace is anomalous. Route this ticket.
The part that matters if you write application code is where the judgment sits. Instead of asking a model to handle a customer, you declare what has to be understood and your own code decides what happens next. Thresholds, routing and consequences stay in the program where you can read and test them. That is a better division of labour than parsing prose and hoping it stays parseable.
Early access is open with a waitlist. Worth trying on one narrow decision you currently make with a fragile if statement.
Need a hand with a WordPress site that keeps breaking? See what I do and how I work.