Loading...

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.

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.

JevChat models
Median classification latency126.81 ms688.40 ms
Input price$0.042 per million tokens$0.20 to $10 per million
Output priceunmeteredaround 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 whenStay with what you have when
The same decision runs thousands of times a dayThe decision is rare, or made once
It sits in the request path and the delay is feltAn overnight batch job is fine
You have, or can label, a few thousand past outcomesYou have no labels and no way to get them
The decision splits into narrow questionsThe 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.

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 jobThe question you askWhat comes back
Support triageDoes this ticket need a specialist nowA Noul, one probability
Queue routingWhich team should handle thisA Choice from your list of queues
ModerationDoes this break each rule in your policyOne Noul per rule, asked together
Model routingHow hard is this requestA Score on your own difficulty scale
Agent loopsShould this loop stop nowA Noul, checked at every step
Retrieval filteringIs this chunk actually relevantOne 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