Jev and RLCD: A Decision Model That Returns Calibrated Probabilities Instead of Text

On 15 September 2026, a startup called TypeSafe AI came out of stealth with a model called Jev. Within a week it had a waitlist of over a hundred thousand people and more than thirty open-source clones. The odd thing is that Jev cannot write a sentence.

You don't chat with it. You send it some state, such as a support ticket, a web page's DOM, a game frame described as JSON, or a log line. With the state you send a list of typed questions, and for each question you define the possible answers yourself. For every question, Jev returns a probability distribution over the answers you defined. It never returns a string you have to parse, and it can't return anything outside your schema. Your code then branches on the numbers.

TypeSafe's co-founder Diogo Almeida (a co-author of InstructGPT, the paper that introduced RLHF to language models) calls it a "frontier-intelligence function call." The simpler description, which caught on, is a smart if-statement.

The speed and price got most of the attention: 70–500 ms per call, $0.042 per million input tokens, and output tokens that cost nothing. The part worth understanding is the training target behind it, RLCD: Reinforcement Learning for Calibrated Decisions. This post covers both in order: what Jev is and how it's used, then what RLCD is and how it compares to RLHF and RLVR.

What's confirmed and what isn't. TypeSafe has published no paper, no weights, no reward function and no training code. Everything here is labelled as coming from TypeSafe (docs, blog, founders, the Latent Space podcast of 21 September), from black-box measurement by third parties, or from inference (mine or the community's). Most performance numbers are self-reported and unverified.

TL;DR

• Jev is a decision model, not a language model. You send it a state and typed questions. It sends back distributions over answers you defined. Its three question types map onto code: Choice → switch on an enum, Score → sort or threshold, Noul → if.
• It is fast because nothing is generated. The state is read once and shared across all the questions, the questions run in parallel, and a readout head produces the probabilities directly. There is no decode loop, which is why output is free.
• The training target is calibration. RLHF optimises for what raters like, and RLVR optimises for answers a checker accepts. RLCD optimises for probabilities that match how often things actually happen. If you gather everything Jev scored at 0.8, about 80% of it should be true.
• Only one kind of objective fits that goal: a strictly proper scoring rule such as log loss or the Brier score. A consequence is that when the right answer is known, the gradient is the same as ordinary supervised cross-entropy. So the "reinforcement" in RLCD most likely lives in where the data and outcomes come from, not in the optimiser.
• TypeSafe says the real moat is data. All of its training data is synthetic, built to be broad rather than to mirror real traffic, and improved by a loop that finds weak spots and patches them in general.
• Where Jev leads its clones is confidence ordering. Open reproductions match its accuracy and even its average calibration error. What they can't match is how well it ranks its right answers above its wrong ones. That ranking decides how much work you can safely automate, and temperature scaling can't fix it.

1. What Jev is, in one picture

Here is the same job done two ways. A support ticket comes in, and you want three things from it: which team should handle it, how frustrated the customer is, and whether they're asking for a refund.

The difference is in the shape of the output. An LLM gives you text that describes a decision, and you have to turn it back into something code can act on. Jev gives you the decision itself, as a number for every option. The options are ones you wrote at request time, not labels fixed in training.

That last detail is what separates Jev from the text classifiers people have trained for decades. A classic classifier knows the labels it was trained on and nothing else. With Jev, the labels, their descriptions and the criteria all arrive with the request, and there's no training step on your side at all.

Why "System One"

TypeSafe calls Jev a System One model, after Kahneman's split between fast, intuitive judgement (System 1) and slow, deliberate reasoning (System 2). The claim is that a pretrained transformer is at its best on System 1 work: reading something and making a judgement in one step. On the podcast, Almeida put it as "these pre-trained super condensations of intelligence are fundamentally system one thinkers."

That's also the explicit trade: "instead of sacrificing size (because the model wouldn't be as smart), we instead sacrifice text generation for composability." Jev is not a small model. The official line is that it is "neither small nor an LLM." It gives up generation, and in return it gets speed, cost and a clean interface.

The name has two jokes in it. Jev is for William Stanley Jevons and the Jevons paradox: when something gets cheaper to use, total demand for it goes up. The bet is that intelligence works the same way.

2. The three question types, and what they map to in code

Jev has exactly three question types. TypeSafe deliberately made them new concepts rather than reusing existing programming types. "A score is not an int," as Almeida put it. Each one still maps cleanly onto a control-flow construct.

A few details make these more useful than they first look.

• Everything is a probability. Almeida: "Everything for us is a probability." Even a Choice's choice field is just the top of a distribution you also get in full.
• Up to 255 options per Choice. Options are processed together, not scored one at a time (more on this in section 3). Above 255, TypeSafe runs a two-stage "score independently, then choose."
• Inputs can be structured. State, instructions, option descriptions and criteria can all be JSON. That includes rubrics, taxonomies, not_for lists and examples, so a program can slot things into the right place rather than building one long prompt string.
• Many questions per call. Independent questions against the same state go into one request and are answered in parallel. You pay for the state once.
• "Confidence" is arithmetic, not a second model. From the official SDK source, a Choice's confidence is (K·p_top − 1) / (K − 1) for K options. It rescales the top probability so that a uniform guess reads 0 and certainty reads 1. It carries no information beyond the distribution itself.

In code, a call looks roughly like this. This is pseudocode for the shape, not the real SDK signature:

r = jev.decide(
    state=ticket_json,
    questions={
        "team":        Choice(options={"billing": "...", "technical": "...", "account": "..."}),
        "frustration": Score(levels=["calm", "annoyed", "furious"]),
        "refund":      Noul("Does this message ask for money back?"),
    },
)

match r.team.choice:                     # Choice  -> switch on an enum
    case "billing":   route_to(BILLING)
    case "technical": route_to(TECH)
    case "account":   route_to(ACCOUNTS)

if r.refund.p > 0.9:                     # Noul    -> if
    open_refund_flow()

queue.sort(key=lambda t: -t.frustration.expected)   # Score -> sort

The part that matters is that none of those branches parse a string.

3. How it's used

The pattern: decompose, then threshold

The main piece of usage advice from TypeSafe is to break the decision into its smallest semantic units and ask each one as its own question. Almeida's example on the podcast was refusals. Don't ask "should I refuse here?". Ask separate, specific questions for each situation where you'd want to refuse, then combine the answers in code.

The reason is that it turns prompt engineering back into software engineering:

If you find a situation where it's like, oh, it didn't refuse because of this reason — I didn't specify this part of the task. That is awesome. That's what software engineering is about. You fix the bug by adding that question in, adding the threshold, maybe remembering that as a test case. And now it is just solved forever.

Almeida calls it "ML without the ML." Each question gets its own threshold, set from real labelled examples, and the threshold should scale with the cost of being wrong. Above the threshold, code acts. Below it, the case goes to a human, a bigger model, or a request for more context.

This whole pattern depends on the probability meaning something. If a model says 0.95 about things that turn out true only 70% of the time, every threshold you set is wrong. So calibration isn't a nice-to-have here. It's what the interface rests on.

Two usage tips that fall out of the architecture

• Pay for the state once, ask many questions. The state is shared across all the questions in a request, so questions are nearly free once the state is loaded. For a long conversation or log, Almeida's advice is to put IDs on every message and then ask one question per ID. You pay for the long state once and get a per-message judgement for each.
• Keep arithmetic, dates and counting in code. TypeSafe's own "jaggedness" page lists math, counting and date comparison as weaknesses. Compute the number of days in Python, put it in the state, and ask Jev about the result.

What people are building

TypeSafe sorts the use cases into four families. The community added a fifth within days.

Vercel reported 5–18× speed-ups after replacing an LLM classifier. The weakest category was trading bots, which several people measured at worse than a coin flip. On the podcast, Almeida said of automated trading: "I just think that people should leave it to the professionals."

4. Why it's fast: no decode loop

TypeSafe has said almost nothing about the architecture, only "a new model architecture, a parallel sampler, and a training method we call RLCD." The rest comes from outside. The most-cited source is Archer Hume's "Jev's Architecture Unmasked", built on about 10,000 API calls. Elon Salfati later re-checked it and confirmed 41 of its 49 claims.

The reconstruction everyone has roughly converged on looks like this:

The measurements behind each part of that picture:

On the base model, the evidence points to a pretrained causal transformer, probably from the Qwen family, post-trained end-to-end for this interface. The tokenizer's closest public match is Qwen (348 of 415 probes). When asked which lab built it, Jev leans heavily towards Alibaba. When asked why it doesn't know it's Jev, Almeida said they deliberately don't train identity in, because that "fractures" intelligence. TypeSafe's own position is "new architecture." Both could be true: a new serving and readout design on top of an adapted trunk.

Why is this worth knowing if you only use the API? Because the fact that TypeSafe is guarded about the architecture tells you where it thinks the value is. Several teams rebuilt the architecture in a weekend (section 7). Almeida has said the company "could probably have released a year and a half ago if all we wanted was a fast/efficient model. The tricky part is making its intelligence general." That part is RLCD.

5. RLCD: training for probabilities that mean what they say

What TypeSafe means by it

The docs define it in one sentence: "Reinforcement learning for calibrated decisions trains TypeSafe to return decisions and calibrated probabilities instead of generated text." The launch post calls the target "answers with epistemically honest probabilities on System One tasks."

On the podcast, Almeida pushed back on the idea that RLCD names an algorithm. The comparison offered was RLHF itself. "RLHF" has come to mean the task of instruction following, not the PPO algorithm from the original paper. DPO and everything after it "also do RLHF despite not using the algorithm in that paper." RLCD, in the same sense, names a new north star:

RLHF is please humans… RLVR is optimize benchmarks… RLCD is make it reliable for programmatic use.

By Almeida's count, the field has picked a genuinely new task for LLMs "2.2 times": RLHF, then RLVR as "a tiny little edit to the direction," and now RLCD. That claim is contestable, but the comparison is useful:

First, what "calibrated" means

A forecaster is calibrated if, across everything they said was 80% likely, about 80% actually happened. It is a property of groups of predictions, not of any single one. TypeSafe's docs say this explicitly: "These rates describe groups of predictions, not a guarantee about any single answer."

The standard summary statistic is ECE (expected calibration error). You sort predictions into confidence bins and average the gap between stated confidence and observed accuracy in each bin. Zero is perfect. The bottom row in the picture has an ECE of about 0.19.

Why RLHF breaks calibration: mode dropping

Almeida's most interesting argument on the podcast was about why chat models are overconfident. The explanation offered is that it's forced on them by the reward, not an accident.

A model trained to produce long strings of text for a reward model faces a lopsided penalty. A visible error, such as a wrong fact stated plainly or a sentence that goes off the rails, is easy for the reward model to catch and gets punished hard. A subtle error that looks right barely gets punished at all. The safest policy under that reward is to be conservative and hyperconfident: put almost all the probability on the most typical answer and drop the alternatives. In Almeida's words, models "need to be hyperconfident in order to not go off the rails… calibration is total poison into the probability distributions of strings."

Almeida compares it to GANs, which learned to produce sharp images by mode dropping: they stopped generating the minority classes and made only the common ones well. Earlier models that tried to cover the whole distribution produced blurry images instead. RLHF'd language models are the GAN in this analogy.

This is also why "just read the logits of a chat model" doesn't give you a good decision model. The first wave of open clones did exactly that: take a frozen LLM, run one forward pass, and softmax over the logits of the answer tokens. The probabilities are there, but the post-training has already squashed them into spikes. In Harvey's Gabe Pereyra's words: "LLM softmax probabilities aren't necessarily calibrated."

Why RLVR's reward can't produce calibration either

RLVR (reinforcement learning from verifiable rewards) gives a model 1 when its answer checks out and 0 when it doesn't. That's perfect for training a model to get answers right. It's useless for training a model to say how likely it is to be right.

Suppose the true chance that "billing" is correct for some kind of ticket is q = 0.7, and the model reports a probability p. There are three ways to reward it:

• 0/1 reward on a sampled answer (RLVR-style). The model says "billing" with probability p and gets 1 if that's right. Expected reward is $pq + (1-p)(1-q) = 0.3 + 0.4p$. That's a straight line, so the best p is 1.0. The reward pushes towards certainty, whatever the truth is.
• Log score. The reward is $\log p$ if billing was correct and $\log(1-p)$ if not. Expected reward is $q \log p + (1-q)\log(1-p)$, which peaks at p = 0.7.
• Brier score. The reward is minus the squared distance between the forecast and what happened. Expected reward is $-[q(1-p)^2 + (1-q)p^2]$, which also peaks at p = 0.7.

In the animation, each ball starts at a low reported probability and climbs its curve as training would push it:

A reward with this property, where the best strategy is to report exactly what you believe, is called a strictly proper scoring rule (Gneiting & Raftery, 2007). Log score and Brier are the two standard ones. Since RLCD's stated goal is probabilities that match outcome frequencies, some proper scoring rule is almost certainly at its core. This is the one thing about RLCD the community broadly agrees on. Elon Salfati's reconstruction puts it at 0.80–0.85 probability.

A short line from @1louder describes the bet well: "RLCD never optimizes for the mode, and trains a proper scoring rule across a very wide range of tasks. The result is that calibration generalizes zero-shot."

So where is the "reinforcement"?

This part is less exciting than the name suggests. When the correct answer is known, the gradient of the log score is the gradient of ordinary cross-entropy, the same loss used to train any classifier. Minimising expected log loss against outcomes is supervised learning on (possibly soft) labels. You don't need policy gradients, rollouts or PPO for that.

So if RLCD contains genuine reinforcement learning, it's probably not in the optimiser. The candidates are all about where the outcomes come from:

1. Environments where the model's own decision changes what happens next. Jev's demos include games (Doom, a Wikipedia race) and browser agents. In those, the outcome of a decision is only observed after the model acts, which is a bandit or RL setting.
2. Outcomes that arrive later and are shared across several questions, such as whether the whole task eventually succeeded.
3. The data loop itself. Generate tasks, find where the model is wrong or badly calibrated, generate more tasks there, and retrain. That is "reinforcement" in the same loose sense that RLHF's data collection was.

Salfati gives only even odds that there's RL beyond the name: "The name may describe the data loop, not the loss." Almeida said on stage that "it is definitely not RLVR," and pointed people interested in prior work to the InstructGPT paper. That fits the reading that RLCD, like RLHF, is mostly a recipe for data and a task definition, with whatever optimiser works.

The closest published relative is RLCR (RL with Calibration Rewards; Damani et al., MIT, 2025). It trains a reasoning model with a reward of correctness minus a Brier penalty on its stated confidence, so a confidently wrong answer is punished twice. The differences are that RLCR keeps a text-generating model and bolts calibration onto it, while RLCD drops generation entirely.

6. The data is the moat, according to TypeSafe

If the optimiser is probably ordinary, the training data has to be doing most of the work. TypeSafe says as much, repeatedly:

• "We consider ourselves a data research lab! The vast vast vast majority of research was on making data that is truly general… and 100% of our data is synthetic (but not the type of crap that is just spit out from an LLM obviously)."
• "The bottleneck for a new task/north star is data and not an architecture… you need an extremely diverse input distribution to make a non-jagged model."
• On the podcast: "Data is so unbelievably complicated and that is what gets nines."

Almeida onboards data people with "a talk longer than this podcast." The outline given on air has three principles:

1. Don't train on user data, even if you could. Real traffic follows a power law, with everyone asking roughly the same things. Train on it and you "overfit to it and fracture to it."
2. Design for the future, not the present. "Even if we had all of the data of the present, we would just overfit to the present." The model is meant to be infrastructure for uses that don't exist yet. The analogy: "UDP as LLMs and TCP as our models."
3. Treat data work like art. The data team studies the model, finds where it's jagged, and patches each weak spot "in every single possible dimension… general case rather than the specific case."

TypeSafe hasn't published how it builds the data. The open reproductions have, and two of their recipes show what "not the kind of crap that is just spit out from an LLM" can look like in practice.

Recipe 1: minimal pairs with labels computed by code

Bespoke Labs' Nimble and Jared Palmer's Kev both build examples in the same way. First you write a rule, then you generate facts, then you compute the correct label in code, and only then do you render it all as text. For every example you also make a minimal pair: change one decisive fact (at most 8 words in Nimble's recipe), and the label flips.

Kev adds a third variant: remove the decisive fact entirely, so the rule returns "unknown," and train that example toward a uniform distribution. That is what teaches a model to not be confident when the evidence isn't there.

This is a good fit for calibration. A pair like A/B forces the model to work out which fact carries the decision. Records like C stop it from guessing confidently. Kev measured the effect: of items that are genuinely unknowable, Kev-9B answered only 5% at ≥ 0.9 confidence, against 9% for Jev and 26% for an earlier Kev without those records.

The rest of what the reproductions learned about data design:

• Hold out structure, not rows. Test on rule shapes and rendering styles the model never saw in training, or you're only measuring memorisation.
• Shuffle options. Jev reads options as a list, so option order is part of the input and should vary in training.
• Fix weaknesses with data, not loss tweaks. Kev found date arithmetic eroding under fine-tuning (0.82 → 0.72). The fix was to state day counts explicitly in the data. A registered screen of loss variants (Brier term, label smoothing, focal loss) found none that beat plain cross-entropy plus temperature.
• Many questions per state. Because questions are isolated, one synthetic state can carry dozens of labelled questions, which gives a lot of supervision for each token of state.

Recipe 2: the jaggedness loop

The second thing TypeSafe describes is a loop more than a recipe, and Almeida presents it as the core of what the data team does:

The important word is general. Patching a single failed example is overfitting. Working out the class of failure and writing data that covers the whole class is what makes the fix transfer to use cases nobody has thought of yet. That, at least, is the claim.

7. How it compares

Against the other ways of making a decision in code

Jev's critics have a fair point: "it's just a zero-shot classifier; encoders have done this for years." Here is how it lines up against the alternatives:

The honest summary is that Jev combines things that used to come separately. You get the labels-at-request-time flexibility of zero-shot models, knowledge close to an LLM's, and the speed and probability outputs of a classifier. None of those is new on its own. Having all of them in one model is.

What the independent tests actually show

The first row contains an apparent paradox. The model sold on calibration loses on average calibration error to an open encoder, yet automates twice as much traffic at the same precision. The last Kev row shows the same pattern: the clone matches Jev's ECE and still trails it badly on coverage. The explanation is the most useful idea in this whole story.

Scale vs. ordering

ECE measures whether confidence has the right scale: whether 0.8 means 80% on average. It says nothing about ordering, meaning whether the model's right answers get higher confidence than its wrong ones. For automation, ordering is what counts. You sort by confidence, automate from the top, and stop as soon as the errors you're letting through exceed your budget.

The numbers in the picture match the real gap: Kev automates 45–57% of decisions under a 5% error budget, and Jev automates about 70%. Every open clone reaches its calibration the same way, by training with cross-entropy and then fitting a single temperature that rescales all the confidences. A temperature is a monotone function, so it can't change which answer is ranked tenth. That is why the clones can match Jev on ECE and still lose on coverage.

If Jev ranks its own mistakes better, that ranking came from training, and most plausibly from the data, which is exactly the part TypeSafe keeps secret. The metric that exposes the gap, coverage at a fixed error budget (or its area version, AURC), is also the one you should measure on your own workload. ECE alone won't tell you how much you can automate.

8. Where it breaks

TypeSafe publishes its own list of failure modes, which it calls "jaggedness." It's unusually candid, and worth reading in full before you build on Jev:

1. Literal reading. It answers the question you wrote, not the one you meant.
2. Math and counting. These are unreliable. Almeida put sequential reasoning at "like gpt-4 level."
3. Dates. They're read as text, not as ordered quantities.
4. Indirection. Multi-hop and double-negative questions degrade, and get worse with each additional hop.
5. Large irrelevant state. It "suffers from context rot," so filter the state first.
6. Adversarial state. "State is data, and jev-1.13 does not treat it as hostile by default." One tester raised Jev's probability on a hateful statement from 3% to 30% by planting a fake "verified" knowledge graph in the state.
7. Contradictory instructions.
8. Structural invariants aren't guaranteed. A Noul asking "refund?" can say 0.72 while a yes/no Choice on the same question says 0.47 for "no." The two sum to more than 1.
9. Generation. It can't do it. Use an LLM.

Add two from outside testing. It is not deterministic: identical requests give slightly different numbers, and Almeida argues that robustness to semantically identical inputs matters more than bit-exactness. And it is order-sensitive, so shuffle the options when you set thresholds. Finally, calibration holds across groups of predictions and varies by task. A viral post about Kelly-sizing trades directly from Jev's probabilities got the right reply: "That's backwards and it's how you blow up."

9. What to take from it

What's solid. The interface is a real idea, and a good one. Typed questions, answer sets defined at request time, probabilities instead of strings, the state read once and shared, and input-only pricing all hold up. Dozens of independent developers reproduced the speed and cost within days. Jev is more accurate than off-the-shelf zero-shot encoders without any training on your side. The developer experience, meaning code that branches on numbers instead of parsing prose, explains much of the excitement, even among people who think the ML underneath isn't new.

What RLCD most likely is. It's a training target rather than an algorithm: probabilities that match outcomes, optimised with a proper scoring rule over a very wide synthetic task distribution. The "reinforcement" most likely lives in the data loop and in environments where decisions have consequences, not in the optimiser. That is the same structure RLHF had. The algorithm in the InstructGPT paper mattered less than the decision to optimise for instruction following and the data built to support it.

What's genuinely open.

• What the label y is: code-computed outcomes, simulator outcomes, frontier-model consensus, or a mix.
• Whether there is any true multi-step RL.
• Whether some term in the objective directly rewards ranking, which is where Jev leads.
• How the calibration holds up on messy, non-English or adversarial production traffic.

Where the moat is. The open reproductions agree that the architecture is the easy part, since an open LLM plus LoRA plus a small head gets within a few points of Jev in a weekend. What they can't yet match is generality across unseen formats and the ordering of confidence. Both of those come from data. That fits Almeida's claim that "the bottleneck for a new task is data and not an architecture." Whether the lead lasts depends on whether the data recipe can be worked out by others, or whether the frontier labs ship a "decision mode" of their own.

The bigger claim, and the reason this matters beyond one product, is that the most useful thing a strong model can give a program may not be text at all. It may be an honest number. Almeida's hint on naming, "current jev can be called a decision model, but I don't think the shape should be called that," suggests TypeSafe thinks there are more of these machine-facing model types still to come.

Appendix: vocabulary

Sources

TypeSafe and its founders

• Introducing System One Models & Jev: launch blog, including its own "Nuance" caveats
• The Bitterest Lesson: "doing the right task > data > compute > algorithms"
• TypeSafe docs: System One, Confidence, AI primer, Noul, and Jev 1.13 jaggedness
• Latent Space: Diogo Almeida on Jev and RLCD (21 September 2026): the source of every podcast quote above
• Diogo Almeida on X: 100% synthetic data, data is the bottleneck, the Jevons bet, launch thread

Reverse engineering and analysis

• Archer Hume, Jev's Architecture Unmasked (thread): about 10,000 API probes
• Elon Salfati, What Jev most likely is, and why the logit hacks are not it (X Article, 19 September): the proper-scoring-rule argument and the odds on each component
• Charly Poly, Jev vs open zero-shot encoders: F1, ECE and coverage at 90% precision
• Roy Chen, Behind Jev: Two Hypotheses About Its Base Model
• Sam Parker's four open questions about RLCD

Open reproductions

• Bespoke Nimble: contrastive minimal pairs
• Kev: executable rule trees, unknowable records, and the coverage comparison
• AutoJev: agent-generated SFT data. "Tried RL, but it hasn't worked out."
• Open-Jev: mixed public, game and workflow data with soft targets

Prior work

• Gneiting & Raftery, Strictly Proper Scoring Rules, Prediction, and Estimation (JASA, 2007)
• Guo et al., On Calibration of Modern Neural Networks (ICML 2017): temperature scaling
• Ouyang et al., Training language models to follow instructions with human feedback (2022): InstructGPT
• Damani et al., Beyond Binary Rewards: Training LMs to Reason About Their Uncertainty (2025): RLCR
• OpenAI, GPT-4 Technical Report (2023): the calibration-before-and-after-post-training figure