Last week TypeSafe AI released Jev, which it calls the first “System One model”: a model that does not chat, does not write, and does not reason step by step. It answers structured questions about an input, in a single forward pass, with a probability attached to every answer. Most of the coverage has focused on speed. I think the more interesting claim is the one about calibration, because calibration is the thing that has quietly limited every production classifier I have shipped, including the one in my COMPSAC paper.
This post is my attempt to work out what Jev actually changes, where it fits in a real ML stack, and how I intend to test the claim rather than take it on faith.
Jev is built around three ideas, per TypeSafe’s launch post:
- Non-autoregressive output. A normal LLM produces its answer one token at a time, and each token depends on the last. Jev emits the entire structured answer at once. That is where the speed comes from: TypeSafe quotes 70–500 ms end to end and “40x–200x faster” than frontier LLMs on equivalent tasks.1
- Typed questions, not prompts. You send a state (text, structured data, or a message history) and a set of questions. Each question is one of three types: choice (pick from a set, get a probability per option), score (rate against ordered levels, get a continuous score and distribution), or noul (a yes/no, returned as the probability the statement is true).2 Every question in a request is evaluated in parallel, so adding questions barely changes latency.
- Training for calibration. The model is trained with what TypeSafe calls reinforcement learning for calibrated decisions (RLCD). The stated goal is “epistemically honest probabilities” rather than the human-preference or verifiable-reward objectives that chat models are tuned on.1
The constraints are just as important as the features. Jev cannot generate free text. A choice question supports at most 255 options. There is no image input yet. Pricing is $0.042 per million input tokens with output tokens free, and access is currently by waitlist.1
So it is not a smaller GPT. It is closer to a very fast, very general tabular classifier that reads unstructured input and returns a typed decision with a confidence you are meant to be able to trust.
Here is the part of my own paper I keep coming back to. We predicted whether a pull request would be merged, using only signals available at submission time. Random Forest hit an F1 of 0.958. The majority-class baseline, which says “merged” to everything, hit 0.957. The number that actually separated a useful model from a useless one was ROC-AUC: 0.676 for the forest versus 0.500 for the baseline. And even at that, we wrote plainly that the models “should not be treated as perfectly calibrated probability models” and were fit for triage, not for automated accept/reject decisions.3
That is not a quirk of one dataset. It is the normal shape of a production classifier:
- Accuracy saturates early. On imbalanced problems, most of the available accuracy is free. The hard part is the ranking and the confidence.
- Downstream logic needs probabilities, not labels. “Route this order to manual review if the model is less than 80% sure” only works if 80% means 80%. If the model says 0.95 on things that are right 70% of the time, every threshold you set is a lie.
- Miscalibration is invisible in the usual metrics. F1, accuracy, even AUC are all threshold or rank metrics. A model can have a fine AUC and terrible calibration, and you will not know until the business rule built on top of it starts misfiring.
The standard fixes are post-hoc: Platt scaling, isotonic regression, temperature scaling. They work, but they are another fitted component that drifts when the data does. What Jev is claiming, if I read it correctly, is that the probabilities come out of the model already honest, because honesty was the training objective. If that holds on tasks outside TypeSafe’s own benchmarks, it removes a whole layer of glue from production ML systems.
That “if” is the entire question, and it is testable.
I work on ML inside a wholesale distribution business. Almost none of it is chat. Most of it is small, repeated decisions that sit between two systems:
| Decision | Today | Why it is annoying | Does Jev’s shape fit? |
|---|---|---|---|
| Is this inbound order an exception that needs a human? | Rules plus a small classifier | Rules rot; retraining the classifier is a project | Yes: a noul with a threshold |
| Which regulatory product category does this new SKU belong to? | Keyword rules, manual cleanup | Vendor descriptions are messy free text | Yes, if categories fit in 255 choices |
| How urgent is this customer support message? | Nothing, or an LLM call that takes seconds | Latency and cost make it hard to run on every message | Yes: a score over ordered levels |
| Which delivery route should absorb this late order? | Constraint solver | Not a classification problem at all | No |
| Write the customer-facing note explaining a substitution | LLM | Needs generated text | No |
The pattern is clear. Anywhere I have an LLM doing a job that is really classification wearing a chat costume, a System One model is a plausible replacement with two orders of magnitude less latency and cost. Anywhere I have hand-written rules that keep breaking because the input is free text, it is a plausible replacement for the rules. Anywhere the job is generation or optimization, it is the wrong tool and TypeSafe says so themselves.
The ERP integration story is also attractive. A model that returns {"is_exception": 0.93} in 100 ms can sit inside a request path. An LLM that returns a paragraph in four seconds has to sit beside it in a queue. That difference decides whether ML is a feature or a batch job.
A few things in the launch material deserve a skeptical reading.
“Zero hallucination.” What TypeSafe can guarantee is that the output type is always valid: you asked for one of five categories, you get one of five categories, with probabilities that sum to one. That is real and useful, and LLM structured-output modes only approximate it. But it says nothing about whether the chosen category is right. A confidently wrong answer in a valid schema is still a wrong answer. The honest framing is “zero schema errors,” and calibration is what has to cover the rest.
Calibration on whose distribution? A model can be well calibrated on its training and benchmark distribution and drift badly on yours. Calibration is a property of a model and a dataset. The only number I will trust is one measured on my data.
The comparison baseline. “200x faster than an LLM on classification” is true and also a bit unfair, because the right baseline for many of these tasks is not an LLM. It is a gradient-boosted tree on engineered features, which is also sub-millisecond and free. The interesting comparison is three-way: classical tabular model, LLM-as-classifier, and Jev, on the same task, on accuracy, ranking, calibration, latency and cost.
I have exactly the right testbed already built: the PR acceptance pipeline from my paper. It is leakage-aware, it has fixed 5-fold splits, and it has a published tree-model baseline with a known calibration weakness. Here is the design.
Task. Same as RQ1 in the paper: given a PR at submission time, predict merged vs. closed without merge. The Jev state will be the PR title, body, and the same submission-time metadata and diff statistics the trees see, serialized as text. Nothing that appears after submission (comments, CI, later commits) goes into the state. The leakage rules do not relax because the model is new.
Questions. One noul: “This pull request will be merged.” Optionally one choice over the task-intent tags (fix, feature, refactor, docs) to see whether Jev’s own reading of intent agrees with our keyword rules.
Baselines. The paper’s Random Forest (400 trees), the same forest with isotonic calibration fitted in-fold, and a frontier LLM asked the same question with structured output.
Metrics. Ranking and calibration, not just F1:
- ROC-AUC, so the result is comparable to the paper.
- Brier score, the mean squared error of the probability against the outcome:
- Expected calibration error, binning predictions by confidence and measuring how far each bin’s accuracy is from its stated confidence:
- A reliability diagram per model, because a single ECE number hides where a model is over- or under-confident.
- Median and p95 latency, and cost per 1,000 PRs.
What would change my mind. If Jev matches the forest’s AUC and beats the calibrated forest on Brier and ECE, without any post-hoc fitting, then the calibration claim is real on a distribution TypeSafe never saw, and I would start moving classification-shaped LLM calls at work onto it. If it beats the uncalibrated forest but not the calibrated one, then it is a convenience, not a capability. If its AUC is materially lower, the speed does not matter.
I will publish the numbers either way, and I will link them from here.
If you are deciding whether to care about Jev right now, my advice is:
- Inventory your LLM calls. Tag each one as generate or decide. The decide ones are candidates. In my experience that is most of them.
- Measure calibration on what you already have. Compute Brier and ECE for your current classifiers. If they are bad, you have a problem Jev might solve. If they are fine, you mostly have a latency and cost question.
- Do not skip the classical baseline. A gradient-boosted tree on decent features is the bar. Any new model has to beat it on your data, with your leakage rules, or it is not an upgrade.
- Treat “calibrated” as a hypothesis. Test it on your distribution before a business rule depends on it.
The idea behind System One models is sound: most of the decisions software needs from ML are small, structured, and latency-sensitive, and a chat model is a strange tool for them. Whether Jev delivers on the calibration promise is an empirical question. I have the dataset to answer it, and I intend to.
If you have Jev access and a labeled classification dataset with a known calibration problem, I would like to compare notes. My contact details are on the homepage.