Within 24 hours of arriving on Vercel’s AI Gateway, TypeSafe’s Jev was in use by nearly 13% of the paid teams there, more than twice as many as any earlier model launch had reached. Vercel called it the fastest-adopted model in AI Gateway’s history, while noting that the next test is whether the adoption lasts.
What TypeSafe set out to build
The company’s manifesto, headlined “Build Prod, Not God”, rejects the race towards AGI on the grounds that today’s models are already capable enough to create enormous economic value, and that what holds them back is how hard their intelligence is to build into software. The goal is a model whose judgment any program can call, as dependably as a database query. Jev, the first public model built on that bet, works like a function call. It takes the material a decision depends on, which the API calls the 'state', together with a set of questions about it, and returns typed answers instead of text, which software can act on directly, each with the probabilities behind it.
System One and System Two
Jev is a System One model, a label borrowed from Daniel Kahneman’s distinction between fast, intuitive thinking and slower, deliberate reasoning. A conventional LLM composes its answer one token at a time, so even a one-word verdict has to be written out. As documented, Jev reads the state and the questions once and answers every question in parallel, each answer with its probabilities.
In exchange for the single read, Jev writes no replies and explains none of its answers. It may also struggle with questions that need several hops, such as a property of a property, and its failure-mode page advises against such System Two tasks. When an answer is uncertain, a person or a reasoning model should take over.
Small decisions inside AI products
AI products make many small judgment calls that need a decision, not an essay: which model should handle a prompt, which files or passages belong in its context, whether a failed step matters, and whether an agent should continue, retry or stop. These are the jobs Jev is designed for. Each has a set of possible answers known before the call, and code acts on whichever one comes back. Published response times run from 70 to 500 milliseconds, though the claimed 40- to 200-fold speed-ups compare Jev with LLMs left in their default modes.
Triage a bug report
An engineering intake system can triage a bug report before a developer reads it. For “The search page crashes when the query is empty,” it can ask what happened, whether the report says how to reproduce the problem, and how serious the issue is. The resulting answers can route the report and set review priority. A developer still inspects the code before fixing the crash.
Here the state is the report. A state can be a single text like this bug report, or a JSON object that gathers related records, such as a support conversation, the order it concerns and the refund policy, each under a name a question can point to. Every question in the request reads that same state and brings its own instructions and possible answers. Each question uses one of Jev’s three primitives:
- Choice - selects an option and returns the probability distribution across the supplied options.
- Noul - asks a yes-or-no question and returns the probability of yes.
- Score - returns a probability-weighted value across levels the developer defines.
Each answer in the figure below is read differently. A Choice picks the option with the highest probability, here crash at 0.94, and the gap to the other options shows how sure Jev is. A Noul’s single number is the answer and its certainty at once, so 0.97 is a strong yes, a value near 0 a strong no, and a value near 0.5 would mean Jev cannot tell. A Score is a position on the levels, so 1.2 sits between Workaround and Blocking, nearer Workaround, and because different splits can give the same score, the probabilities behind it matter too.
The intake system could ask all three questions in one request. They run in parallel, and none sees the others’ answers. A question that matters only for crashes can still go in the same request, and code ignores its answer for other reports; TypeSafe calls this speculative fan-out. A second request is needed only when building it takes an earlier answer, for example to fetch the code a crash points to.
The other option gives reports outside crash and wrong_result somewhere to go, because a Choice cannot abstain. Code can send those reports, or uncertain answers, to a person.
Fitting Jev to a company
Jev is not fine-tuned for customers, since the same weights serve every account and customer data is not used for training. A team adapts it through the request instead, putting its records in the state and its rules and edge cases in the question criteria, and splitting broad judgments into narrow questions whose answers code combines, sometimes through a separate model trained on Jev’s outputs. Where a team has no labels to train that model, the documentation suggests generating them with an ensemble of expensive reasoning models.
The figure below follows one request to an action.
- Jev - reads the state and the questions and returns a probability for each question. Outlined in red, it is the same for every team; everything around it is the team’s own.
- Combine - code merges those probabilities into one result, by a rule or weighted sum the team writes or through that separate model.
- Thresholds - the result must clear a threshold before code acts; below it, the case goes to a person or a reasoning model. Each action gets its own threshold, higher where a mistake costs more.
- Act - code carries out the action the threshold allows.
- Labelled past examples - past cases whose right outcome is known. They fit the separate model and set each threshold, by showing how often answers at each probability turn out right.
Innovations and earlier decision models
TypeSafe claims three innovations: a new model architecture, a parallel sampler and a training method called Reinforcement Learning for Calibrated Decisions (RLCD). No paper, weights or architecture details have been published, so the first two remain claims; the single read and parallel answers described above are the behaviour they are said to produce.
Models that return a probability where a chatbot would return text predate Jev. In March 2025 Nandakishor M published SalesRLAgent, a reinforcement-learning model that estimated, turn by turn, how likely a sales conversation was to convert. In his own account, that model was built for one question and could not take new questions at runtime, which Jev does with every request. Nandakishor argues that TypeSafe packaged the same core idea for general use, and he responded by building an open alternative.
That alternative, Laya, is published by Convai Innovations under the Apache 2.0 licence. Laya is a 421-million-parameter model built on ModernBERT-large, a bidirectional encoder, and it answers one typed question in about 40 milliseconds on a T4 GPU. Its model card sets Laya’s scores beside Jev figures that others published. On the Banking77 intent task it lists Jev at 0.870 on 72 labels against Laya’s 0.425 on 77, and puts Laya’s score down to its default token budget. With different samples, prompts and label counts, the scores are not a like-for-like comparison.
RLCD and calibrated probabilities
Diogo Almeida, the company’s founder, helped build the instruction-following methods at OpenAI that led to ChatGPT, and the case for RLCD starts with their limits. Reinforcement learning from human feedback (RLHF) rewards the text human raters prefer, which suits a chatbot but, by the company’s account, can also reward confident-sounding hallucinations. Reinforcement learning with verifiable rewards (RLVR), a method used to train reasoning models, suits tasks a program can check.
RLCD aims instead at calibrated probabilities, meaning that across many answers, those given a probability of 0.8 should turn out right about 80% of the time. Calibration describes groups of answers, not a promise about any single one. That limits what it offers selective automation, which acts on the confident answers and sends the rest to a person. The figure below shows why, with two illustrative models that are each right on nineteen of twenty answers.
- Model 1 gives every answer 0.95, and nineteen of the twenty are right, so it is calibrated. But its mistake carries the same number as its right answers, so no threshold can pick it out, and catching it means checking all twenty.
- Model 2 gives fifteen answers 1.0, all right, and five answers 0.8, of which four are right, so it is calibrated too. A threshold between 0.8 and 1.0 runs the fifteen automatically and sends the five to a person, who finds the mistake among them.
Selective automation needs the second kind, where the probabilities also separate likely errors from the rest, and calibration alone does not promise that. A model separates its errors by giving lower probabilities to the kinds of case it tends to get wrong.
A team from the University of Southern California and AWS AI Labs, publishing in the Findings of ACL 2026, trained models on decision tasks and found that RLVR raised their accuracy but made them extremely overconfident, while ordinary supervised fine-tuning kept them better calibrated.
An established way to reward honest probabilities is a strictly proper scoring rule, which pays the most on average only when a model’s stated probabilities match the true odds. Because it rewards certainty on right answers and penalises it more heavily on wrong ones, it also rewards a model for separating its errors. Laya's model card describes training with such rules, which shows the approach can be done in the open. How Jev was trained stays private, so its probabilities have to be judged by how they behave on real tasks.
Accepting confident verdicts
In a preprint posted in September 2026, researchers at Carnegie Mellon University tested Jev as a judge of other models’ answers against sixteen other judges, the strongest of them GPT-6 Astra. Across 990 judgments on three public benchmarks, Jev was more accurate when it gave a higher probability. On the items it gave a probability below 0.6, Jev was right on 47.7% and GPT-6 Astra on 78.5%; on those it gave 1.0, both were right on 99.1%. GPT-6 Astra’s advantage sat where Jev was unsure.
That separation is what would let code accept Jev’s confident verdicts and pay a stronger judge only for the rest. The Carnegie Mellon team tested that rule on 510 pairs of answers that were not used to choose it, with a threshold of 0.9 on Jev’s highest answer probability, averaged over both orders of each pair and fixed beforehand. Jev settled 53.7% of the pairs on its own and passed the others to GPT-6 Astra. The combination was worked out from the two judges’ recorded verdicts rather than run live, and it scored 92.5% against 93.1% for GPT-6 Astra alone, at about 57% of its fee. Allowing for chance, the paper puts the combination between 1.8 points worse and 0.6 points better than GPT-6 Astra alone, and the delay of calling two models in turn was not measured. On harder judging tasks, Jev could be confidently wrong, so that threshold needs validation on each workload.
The separate confidence field Jev returns is not an independent check that an answer is right, because it is derived from the same probabilities. The open-source adapter published alongside Jev, which gives LLMs the same interface, computes it by rescaling the top probability for Choice and measuring how concentrated the distribution is for Score. That formula reproduces the confidence values in TypeSafe’s published API examples. The Choice version depends on the number of options, so a threshold tuned on one set of options does not carry over to another, and Noul answers have no confidence field at all.
Agreement and cost against LLM judges
In a grading test by Good Start Labs, DeepSeek V4.1 Flash agreed with Fable 5.1's verdicts 93.5% of the time against Jev's 91.5%, at $260 per million graded answers against Jev's $160. Jev's verdicts came from July, when the lab had early access, and the lab does not say which version produced them; the language models graded the same answers on 15 September. The lab also timed Jev at about half a second per call in a separate run, but reported no speeds for the language models, so the comparison covers agreement and cost only.
Implications
Start with a decision whose correct answer you can label, such as the issue type on past bug reports. Measure the errors and the review workload before automating new decisions. Jev’s narrow output is attractive when software already has a defined action to take, but any saving must survive the cost of handling uncertain cases. The Carnegie Mellon results suggest that letting Jev settle its confident verdicts and passing the rest to a stronger judge can keep accuracy close to that judge’s at a little over half its fee, provided Jev’s confident answers have been checked on that kind of judgment. If another model has to reconsider every report, compare that arrangement with sending every report to that model alone.
Takeaways
- Try Jev when the possible answers are known before the call. Use generation when the required answer is open-ended.
- Automate only where local results justify the threshold. Revalidate when the questions, options, traffic or model version change.
- Keep Jev in the application if the complete workflow improves on your cheapest adequate alternative. Remove the extra stage if review consumes its saving.