Jev and the comeback of classifiers
Jev is the first model in a new class TypeSafe AI calls System One. It comes from Diogo Almeida, an ex-OpenAI researcher who worked on the methods behind ChatGPT, and it launched in early access in September 2026. It doesn't generate text. You give it some data and questions, and it returns typed answers with probabilities in a fraction of a second. The idea itself isn't new. For years, we've been using text-generating models to answer questions that don't actually need text. The key part is how it works and how reliable those probability scores actually are.
Jev returns typed decisions instead of text, in a fraction of a second, with output tokens unmetered. This post covers what it is, and why the industry dropped classifiers and is now buying one back. Then the calibration work you have to do before any decision model is safe to put a threshold on.
Jev is a classifier, not an LLM
I've worked quite a bit with BERT, RoBERTa, DistilBERT, DeBERTa, and similar models for classification, so I found this recent comeback of classifiers around Jev pretty interesting. A few weeks back, I added a similar idea to this app's assistant. A classifier reads the whole question and picks one intent from a fixed catalogue, instead of relying on hand-written rules to match keywords.
One thing to clarify. Jev is not an LLM, and the underlying idea of using models as classifiers is not new. Jev is essentially focused on classification and decision-making rather than generating text. Given an input, it returns a class, a score or a probability instead of a sentence, which can make it useful for tasks where you don't actually need an LLM.
For example, spam detection, ticket routing, intent classification, moderation, and many other structured decision tasks can often be handled by a classifier without generating a response.
Classifiers are back now because they're faster and cheaper than calling an LLM. It doesn't mean classifiers disappeared or that this is a completely new ML concept. It is more like an old and useful approach getting renewed attention in an LLM-first world.
What Jev returns instead of text
The companion build is on GitHub, Jev Decision Lab. It runs offline with no API key, and switches to the live model when you add one.
Jev takes two things. Some state, which is whatever text or structured data you already have, and a set of questions. It answers all of them in one call and returns typed values with probabilities attached.
Jev has three kinds of question, and the kind you pick decides what comes back.
- Noul: A Noul is basically a yes or no answer, represented as a probability between 0 and 1. The name may be unfamiliar, but the idea is simple.
- Choice: One option from a set you define, up to 255 of them, with a probability for each option.
- Score: A position on an ordered scale of 2 to 10 levels, such as how frustrated a customer sounds. It comes back as a decimal, the probability-weighted mean of the levels, so 1.3 sits between level 1 and level 2.
That is everything it can return. Jev can't write a sentence, explain its reasoning, or call a tool. It also can't return a field you didn't ask for, invent an option that wasn't on your list, or hand you JSON that fails to parse.
Three questions take almost the same time as one. The state is read once, then all the questions run in parallel. You only pay for the extra question text, so TypeSafe recommends putting all independent questions in the same call.
TypeSafe doesn't call this a classifier. Their term is a System One model, or a frontier-intelligence function call. The distinction they draw is that it decides with frontier-level judgement, rather than matching patterns inside one narrow domain. The classifier framing in this post is mine.
Why the industry stopped using classifiers
Before 2020, building a classifier was ordinary production work. You collected a labelled dataset, finetuned an encoder such as BERT, and got back a class with a probability. An encoder reads the whole input at once and scores it. A decoder, which is what a chat model is, writes one token at a time.
GPT-3 changed the arithmetic. You could call one API and get a usable answer, with no labels and no training run. The same API also worked on tasks a finetuned encoder was never built for. Teams dropped the encoder, and that was the right call. Ten classifiers mean ten datasets, ten training runs and ten things to keep working.
Dropping the encoder also changed the shape of the answer. A decoder can only reply in tokens. So a yes or no decision comes back as the word yes, wrapped in JSON and generated one token at a time. You pay decoder prices for that, then parse it, and handle the times the JSON comes back broken.
A classifier was always the right tool for a decision. The problem was the cost of building one, a labelled dataset and a training run for every task. Jev is meant to give you the same kind of answer without any of that.
How a single-pass model works
TypeSafe says Jev generates all of its output in a single query rather than one token after another, and does not disclose the architecture beyond that. Generating every position at once has a name in the literature, non-autoregressive generation, and it isn't new. Researchers tried it on machine translation in 2018 and it worked badly.
A sentence has many valid translations. Emitting each word independently blends two good sentences into one incoherent one, because the words never see each other.
A decision has no such problem. There is one slot and a fixed list of allowed values, so nothing has to stay consistent across positions. The idea that broke on sentences fits decisions exactly. TypeSafe trains the model with reinforcement learning for calibrated decisions, which optimises the probability rather than the wording.
| Jev | Chat models | |
|---|---|---|
| Median classification latency | 126.81 ms | 688.40 ms |
| Input price | $0.042 per million tokens | $0.20 to $10 per million |
| Output price | unmetered | around 5x the input price |
The latency pair comes from an independent benchmark of 240 routing calls against Claude Haiku 4.5, not from TypeSafe. Read the exact figures as one setup on one day, and the order of magnitude as the real result.
What a probability is worth
So Jev is fast and cheap. Before you can use it for anything real, you need to know whether the probability it returns with each answer is trustworthy.
You use a decision model the same way every time. You pick a confidence cutoff. The model handles anything above that cutoff on its own, and everything below it goes to a person. So the cutoff is only as good as the number you are comparing against. When the model says 0.95, it should be right about 95% of the time, and that is what calibration means.
Several people have now measured this on Jev. One found an expected calibration error of 0.107 on 900 synthetic support tickets, against a 0.024 noise floor for the same measurement. Yes or no answers came out underconfident and choice answers overconfident, so a single correction can't fix both. On questions the text could not answer, the model was right 44.7% of the time while giving its answers an average probability of 0.74.
How you ask the question matters even more. On a 2,000-email phishing set, one broad question scored 62.6%. The same task split into five narrow questions, with a logistic regression fitted on 1,000 labelled emails, scored 95.0%. Same model, same emails. Splitting a decision like that is called decomposition.
That 95% belongs to Jev plus your labelled data plus a regression you now maintain. Budget for the labels, because they are the part that costs.
The companion project runs the same comparison on data you supply. Its own sample tickets are generated, so decomposition wins there by construction and the numbers prove nothing about Jev. They still show which number to watch. Accuracy barely moves between the two ways of asking. Coverage does, and coverage is the share of traffic the model handles on its own at a fixed accuracy bar.
There is a standard fix for bad calibration, a one-parameter adjustment called temperature scaling. On the broad-question version it made things worse. Temperature only makes a probability sharper or flatter, so it can't correct a model that leaned the wrong way. Fixing it needs a second adjustment that moves the whole scale up or down, called Platt scaling, and that is two more lines of code.
When to reach for one, and what else to look at
Decide on volume and repetition first, then on whether the decision splits cleanly.
| Reach for a decision model when | Stay with what you have when |
|---|---|
| The same decision runs thousands of times a day | The decision is rare, or made once |
| It sits in the request path and the delay is felt | An overnight batch job is fine |
| You have, or can label, a few thousand past outcomes | You have no labels and no way to get them |
| The decision splits into narrow questions | The answer needs an explanation a person will read |
Jev is not the only way to get a calibrated decision, and the alternatives are worth pricing before you commit to a hosted one.
- A finetuned encoder of your own: ModernBERT or a small open model, trained on your labels. One independent run finetuned a 4B model on 1,000 of those phishing emails and reached 97.4% with a calibration error of 0.010, ahead of Jev on both. You own the weights and the privacy, and you carry the training and the serving.
- A small chat model with a forced schema: Constrained decoding makes the model emit only tokens that fit your schema, so the output always parses, and you keep the ability to ask for an explanation. You give up the calibrated probability, since a chat model's stated confidence is generated text like the rest of its output.
- Embeddings and nearest neighbours: Embed your labelled examples once, then classify by what a new input sits closest to. No training run, and it improves as you add examples. It struggles when the decision turns on a rule rather than on similarity.
- A rule: If one keyword or one field decides it, write the rule and spend the model budget on the decisions that are genuinely hard. This is the option teams skip, and it is free to test.
Whichever you pick, the measuring work is the same. The evaluating AI systems post covers building the fixed test set this needs, and the LLM judge lifecycle post covers what happens when the thing doing the scoring drifts.
Where Jev fits
These are jobs where the answer was never text, and where something has been generating text anyway. The third column is the primitive that fits, which is usually the part people get wrong first.
| The job | The question you ask | What comes back |
|---|---|---|
| Support triage | Does this ticket need a specialist now | A Noul, one probability |
| Queue routing | Which team should handle this | A Choice from your list of queues |
| Moderation | Does this break each rule in your policy | One Noul per rule, asked together |
| Model routing | How hard is this request | A Score on your own difficulty scale |
| Agent loops | Should this loop stop now | A Noul, checked at every step |
| Retrieval filtering | Is this chunk actually relevant | One Noul per chunk |
Model routing is the one with a published measurement behind it. The independent benchmark quoted earlier in this post was exactly that job, deciding which model should answer each incoming request.
Moderation and retrieval filtering are the two that get tricky when you actually use them. Both look like one question but are really several decisions, so it makes sense to split them and tune the weights yourself.
Sources
- TypeSafe AI, 2026: Introducing System One Models and Jev. The launch post, and the source for the pricing and the training method.
- TypeSafe AI docs: Python SDK. The question types, the response shape and the cardinality limit.
- LiteLLM, 2026: JEV Classifier: 5.43x as Fast as Haiku, 96% Lower Cost. The independent latency and cost figures, 240 calls, with the authors' own caveats.
- Beri, 2026: TypeSafe Jev Scores 62.6% Asked Once and 95% Split Five Ways. The decomposition result, the calibration measurements and the finetuned 4B comparison.
- Gu et al., 2018: Non-Autoregressive Neural Machine Translation, arXiv:1711.02281. Why parallel generation broke on sentences.
- Devlin et al., 2018: BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding, arXiv:1810.04805.
- Guo et al., 2017: On Calibration of Modern Neural Networks, arXiv:1706.04599. Where temperature scaling comes from, and why it is the first thing to try.