Most products in this field are sold on what they can also do. The list grows every release and the edges blur until nobody can say what the product is for.
Jev went the other way, and I think it is the most disciplined piece of AI engineering I have looked at this year. It does one thing. It will not be talked into doing anything else. The company publishes a page listing what it is bad at. Somewhere in the documentation there is a line telling you not to read too much into its headline feature, which is not a sentence vendors usually write about their own product.
I want to explain what it is, and then why the restraint is the interesting part rather than the speed.
Table of contents
Open Table of contents
What it is
Jev comes from TypeSafe AI, founded in San Francisco in 2024 by Diogo Almeida, Erik Gafni and Sasha Sheng. Almeida spent around four years at OpenAI on reinforcement learning from human feedback, InstructGPT, ChatGPT and GPT-4 before leaving. The model was built in stealth for about two years and released in limited early access on 15 September 2026 alongside a forty million dollar seed round.
It is named after William Stanley Jevons, whose paradox observes that making a resource cheaper to use tends to increase consumption rather than reduce it. The stated reasoning is that cheaper machine intelligence will be deployed far more widely rather than saving anybody money. I like a company that names its product after what will happen to its customers.
The company calls it a System One model, after Kahneman’s fast intuitive thinking, with generative models as the System 2 counterpart.
You send a state, which is a string, a JSON object or an array of strings, plus one or more typed questions. You get back one probability distribution per question. That is the only thing the model produces. The choice, the score and the confidence figure that come out of the API are computed from those distributions by plain formulas sitting outside the model.
Three question types, all multiple choice underneath.
Choice selects one option from a set you define and returns probabilities across all of them.
Score rates against ordered descriptive levels. Define zero as calm, one as frustrated, two as very frustrated, and you get back something like 1.4, the probability weighted average across your levels.
Noul asks a yes or no question and returns the probability that the answer is yes, as a number between zero and one. Not a boolean. The number is the entire point.
The refusals are the design
Four refusals, each of which I think is correct.
It will not write. No prose, no explanation, no reasoning you can read. The published list of weaknesses includes generation as an entry, with the recommended workaround being to use a generative model. A company that lists its own absence of a feature as a known limitation, and tells you to go and use a competitor’s product for it, has a clear idea of what it is.
It will not let one question depend on another. Every question in a request sees the same state and is evaluated independently. If you need the answer to one before asking the next, you make two requests in sequence, and the type system will not let you pretend otherwise. That is a constraint enforced in the design rather than a caveat in the documentation, and the difference between those two is most of software engineering.
It will not take a vague question. The guidance is explicit that “does this message convey urgency” is a good question and “analyse this message and determine the best course of action” is not. Where the judgement rests on several factors, you are told to ask about each separately and combine them with weights in your own code. Instead of rating a startup pitch, ask about market size, technical feasibility and differentiation, then weight those yourself. When priorities change you edit a number rather than rewriting a prompt.
It will not pretend to be a calculator. Arithmetic, counting and date comparison are all documented as weak, with the advice being to keep that work in code where it belongs.
Each of those is a decision to be less useful in the demo in exchange for being more predictable in production. That trade is unfashionable and it is the right one.
Calibration, and the vendor talking down its own product
The claim circulating about Jev is that if it reports ninety five percent confidence it is correct ninety five percent of the time.
TypeSafe’s own documentation says otherwise, in terms, and this is the moment I went from interested to impressed. Calibration, it says, is measured across groups of predictions, and it does not guarantee that any individual answer is correct.
Think about what that sentence costs them. Calibration is the headline property, the one the training method is named after, the reason to choose this over a classifier you trained yourself. And the documentation goes out of its way to stop you believing the flattering version of it. A perfectly calibrated model that assigns 0.95 to a thousand cases will be wrong in roughly fifty of them, and nothing in the output tells you which fifty.
There is a second distinction underneath, which the write ups also miss. Confidence and probability are different numbers. Confidence is not the chance of being right. For a choice question it is a normalised measure of how concentrated the distribution is on its leading option; for a score question it is a dispersion measure built on average absolute deviation around the mode. A confidence of 0.95 on a two option question corresponds to about 0.975 on the winning option. Two quantities, two formulas, both documented.
This matters practically, because the reason to use the model is to act on the number. Build a threshold that sends anything below a cutoff to a human and you need to know precisely what the cutoff means. The company could have left that ambiguity in place and sold more. It wrote the correction into the docs instead.
The jaggedness page
TypeSafe maintains a page for each model version headed jaggedness, listing known failure modes with recommended workarounds and a review date on the top. The current one lists nine.
I cannot think of another model vendor that does this. Limitations usually surface as a paragraph of hedging in a launch post, or they do not surface at all and you find them yourself in production at your own expense.
Several entries are what you would expect. Poor at arithmetic and counting. Reads dates as text rather than as ordered quantities, so comparisons and windows are unreliable. Degrades when the state is padded with irrelevant material. Vulnerable to adversarial content in the input, which will not surprise anybody who has thought about where operational text comes from.
Two I would not have found quickly on my own, and they are the ones worth designing around.
It reads literally. It answers the question you wrote rather than the one you meant. Scoping words, negations and implied conditions are all taken at face value. The accompanying advice contains the best line in the documentation: when you look at a wrong answer and find yourself explaining what you really meant, that explanation is the missing half of your instruction.
Option order affects the answer. The documented workaround is to reorder the options and check the answer holds. That is a positional bias in a system whose output you intend to threshold on, and finding it unaided would have taken a long time and a confusing incident.
Publishing that costs the company something on first read and saves every one of its users a week. It is the behaviour of people who expect to be around in five years.
The one place I would hold back
For balance, because unqualified enthusiasm is not worth much.
The performance claims are vendor claims. End to end response times of 70 to 500 milliseconds, 40 to 200 times faster and 40 to 400 times cheaper than frontier models on comparable tests. I would treat those as directional rather than measured, for the reason TypeSafe gives itself: the workflows were built by its own model capabilities team and its own technical notes say they may therefore be biased relative to real tasks.
Even here what I notice is that the caveat came from them. I would still measure it on my own workload before quoting the numbers to anybody.
Separately, the architecture is unpublished. No weights, no paper, nothing beyond the statement that it is transformer based. I have read confident descriptions of classification heads replacing a generation head and embeddings being routed into parallel scoring layers, and none of that appears to come from the company. That is a complaint about the write ups rather than about TypeSafe, which has simply declined to say.
Why this is the shape I want
There is a pattern in a great many production systems where a generative model is being used as a classifier. A prompt asks for a category, a schema is specified, something comes back, and code parses it and handles the times it arrives outside the enumeration or wrapped in an apology.
That arrangement pays three times. For tokens produced and discarded, for latency while they are produced one at a time, and in the loss of any usable measure of how sure the model was. The probabilities either are not exposed or are awkward to get at, and a model’s statement of its own confidence in prose is worth almost nothing.
A discriminative model removes all three at once, because the distribution is the output rather than something you are trying to reconstruct from one.
But the part I admire is not the efficiency. It is that somebody looked at a field rushing to make every model do everything and built one that does a single thing, refuses the adjacent things on principle, publishes where it falls short, and warns you against over reading its own best feature.
If you try it, build the reliability diagram first. Run a few hundred cases where you know the answer, compare predicted probabilities against observed frequencies, and find out what the numbers mean on your data. It takes an afternoon. Given how carefully this company has handled the difference between calibrated and correct, doing less would be a poor way to repay the effort.