What RLCD stands for
RLCD is Reinforcement Learning for Calibrated Decisions, the post-training method TypeSafe says produced Jev.
TypeSafe’s own docs put the goal in one line: “Reinforcement learning for calibrated decisions trains TypeSafe to return decisions and calibrated probabilities instead of generated text.” The launch post adds the target the reward is meant to hit, “calibrated decisions: answers with epistemically honest probabilities on System One tasks.”
That phrase is doing the work. The goal is a model whose stated probabilities can be trusted as probabilities, rather than one that picks the right option more often.
Two spellings are in circulation, which matters if you go searching. TypeSafe’s docs write it as reinforcement learning for calibrated decisions. TechCrunch’s 18 September 2026 piece quotes Almeida calling it “reinforcement learning from calibrated decisions.” Same acronym, different preposition.
How RLCD training works, as far as TypeSafe has said
TypeSafe has published an objective and a data source. It has not published a method.
The objective is calibration, defined by TypeSafe itself: “Across many predictions from a well-calibrated model: Outcomes assigned a probability of 0.2 should occur about 20% of the time… 0.8… about 80%… 1.0… 100% of the time. These rates describe groups of predictions, not a guarantee about any single answer.” That last clause is the one people skip. Calibration is a property of a batch of answers, not a promise about the answer in front of you.
The data is synthetic. TechCrunch reported on 18 September 2026 that “Almeida says Jev is trained exclusively on synthetic data using a technique he calls ‘reinforcement learning from calibrated decisions,’” and quotes him on the decision behind it: “We made an early bet that we will be making all of our data, and that has been one of the best bets I’ve ever made in my life.”
TypeSafe’s machine learning primer sets out what RLCD is positioned against rather than how it runs. It names RLHF’s failure modes, sycophancy and mode dropping, drawing the analogy to mode collapse in GANs, and lands on a line worth keeping: “An output can be compelling to a person without being reliable enough for unattended automation. Human preference and machine trustworthiness are different optimization targets.”
What is missing is everything a researcher would need to rerun it. No reward function is given, and no proper scoring rule is named or described anywhere in the docs, the primer or the launch post. There is no dataset, no training code, no step count and no calibration figure for any task family. The architecture guide covers the same gap on the model side.
RLCD vs RLHF vs RLVR
All three are reinforcement learning from a reward signal. What differs is what the reward measures.
| RLHF | RLVR | RLCD | |
|---|---|---|---|
| Objective | Responses people prefer | Outputs a program can verify | Decisions with probabilities that match outcomes |
| Reward source | Human preference ratings | An automatic checker: test suite, answer key, arithmetic | Not published. TypeSafe states the target, not the signal |
| Output shape | Generated text | Generated text, usually with reasoning steps | A typed answer plus a probability distribution |
| What it optimises for | Persuasiveness alongside correctness | Mechanically decidable correctness | Honesty of the stated probability |
| Known cost | Sycophancy, mode dropping | Slower and more expensive at inference | Not published |
| Canonical paper | Ouyang et al. 2022, arXiv 2203.02155 | DeepSeek-R1, arXiv 2501.12948, and Tulu 3, arXiv 2411.15124 | None exists |
RLHF, Reinforcement Learning from Human Feedback, rewards responses that human raters prefer. It is the method that turned pretrained models into chat assistants, and it has a known side effect: models learn to sound confident, because confident answers rate better. TypeSafe’s docs note that RLHF “was used to train InstructGPT and ChatGPT and was co-invented by Diogo Almeida, cofounder of TypeSafe,” which makes the change of objective a deliberate move rather than an accident.
RLVR, Reinforcement Learning with Verifiable Rewards, rewards outputs a program can check. Did the code compile, did the unit test pass, did the arithmetic come out right. TypeSafe’s primer describes it as having “created reasoning models that are strong at tasks such as mathematics, but slower and more expensive.” It works where correctness is mechanically decidable and says nothing about how sure the model should have been.
RLCD, as TypeSafe describes it, rewards probabilities that match outcomes. A yes/no answer given at 0.8 should be right about 80% of the time across the whole distribution of such answers. Getting the answer right is necessary but not sufficient, because the objective is the honesty of the number.
What calibrated means
A model is calibrated when its confidence matches its accuracy. Take every answer it returned at 80% confidence. If roughly 80% of them turned out correct, the model is calibrated at that level. If 60% were correct, it is overconfident. If 95% were, it is underconfident, which sounds harmless and is not: your code will escalate cases it could have handled.
Expected calibration error is the standard measure: the average gap between stated confidence and observed accuracy, computed by bucketing predictions and comparing each bucket’s mean confidence to its hit rate. The paper usually cited for it is Naeini, Cooper and Hauskrecht (2015), “Obtaining Well Calibrated Probabilities Using Bayesian Binning,” in the Proceedings of the AAAI Conference on Artificial Intelligence 29(1).
Accuracy and calibration are separate properties. A classification model can be right 90% of the time and useless for gating if it says 99% every time. A weaker model that honestly reports 70% when it is right 70% of the time is the one you can build a threshold on.
This is why confidence gating only works on top of a calibrated model. TypeSafe’s confidence docs suggest acting automatically at high confidence, confirming at medium, and routing to a human at low, with a worked example using 0.5 as the floor for genuine uncertainty and 0.9 as the bar for destructive operations. Those numbers mean nothing unless the underlying probabilities track reality.
Is there an RLCD paper?
No. An arXiv search on 20 September 2026 for the exact phrase “reinforcement learning for calibrated decisions” returned zero results, and a search for TypeSafe together with Jev returned zero results as well.
Everything public about RLCD comes from three places: the launch post, the docs primer, and the TechCrunch interview. None of them contains a reward function, a dataset description or an evaluation you could rerun.
Models trained with RLCD
Jev is the only model TypeSafe describes as RLCD-trained, and even that description is a name and an objective rather than a method. Nobody outside TypeSafe has reproduced RLCD, because there is nothing published to reproduce.
Cloudflare uses the same name for its own method. Its 1 October 2026 launch post for Clef describes Reinforcement Learning for Calibrated Decisions as a second training stage that gives partial credit to adjacent ordinal choices, rewards fully precise record outputs, and applies a reference penalty to limit drift. Cloudflare does not say this matches TypeSafe’s method, so treat it as a separate technique that shares the name.
The name has spread anyway. A Hugging Face search for rlcd on 20 September 2026 returns an active cluster of models, nearly all of them created between 16 and 19 September 2026, in the days after the Jev launch. The list includes harshatheg/Qwen-2.5-1B-RLCD, notnotsamuel/LFM2.5-350M-RLCD, monotykamary/LFM2.5-2.6B-RLCD, anthonym21/qwen3-0.6b-rlcd-decision and larkooo/gemma-e2b-rlcd. Creation dates that close to a launch say more about naming than about training.
The clearest case is the one this directory lists. The HuggingFace Space behind Parallel Constrained Decoding (Qwen2.5-1B-RLCD) runs the stock mlx-community/Qwen2.5-1.5B-Instruct-4bit checkpoint. Its README never defines RLCD, never mentions reinforcement learning, and never claims any fine-tune at all. What it documents is an inference-time technique: “KV-Cache Broadcasting” and “Logit Slicing” to evaluate multi-field JSON schemas at once, reporting a 5.6x to 7.0x latency reduction on Apple Silicon. RLCD appears in the model’s name and nowhere in its method.
One model in the cluster looks like a serious attempt at the objective. heman10x/rlcd-modernbert-151m carries tags for expected calibration error, Brier score and proper scoring rules, which suggests its author is chasing the calibration target rather than the branding. Its model card has not been checked in full, so treat it as a lead rather than a verified reproduction.
One older result will mislead anyone searching the tag. TaylorAI/Llama-3B-RLCD-SFT predates Jev by years and uses RLCD for an unrelated technique, an acronym collision rather than prior art for TypeSafe’s method.
Why a model trained this way looks different
Three consequences fall out of the objective, and they show up in Jev’s API.
The probability distribution is the primary output rather than a debug field. Every Choice answer returns a probability for each option, and every Score answer returns one per level. The chosen answer is derived from the distribution, not the other way round.
Confidence is computed, not claimed. TypeSafe describes it as “a statistic computed from the probability distribution the answer already gives you.” Nobody asked the model how sure it was. The shape of the distribution is the certainty measure, which removes the failure mode where a model asserts 95% because assertive text scores well.
Noul returns no confidence value at all, since a probability from 0 to 1 already is one. A second number would be redundant.
Calibration does not fix the rest
TypeSafe’s own jaggedness page for Jev 1.13 is the useful corrective. Version 1.13 is weak at arithmetic and counting, “reads dates as text, not as ordered quantities,” degrades as unrelated content grows in the state, and does not treat input as hostile by default.
One entry on that list matters more than the others for anyone reasoning about calibration: the model gives no guaranteed mathematical relationship between related questions. Ask “is this urgent?” and “is this not urgent?” and the two probabilities need not sum to 1. TypeSafe’s own worked example on that page has a Noul and its negation summing to 1.19, with the page stating that “there are many reasons that P(noul) and 1 - P(not noul) may not be directly comparable.” Per-answer calibration is a statistical property across many answers. It does not impose logical consistency within a single call.
If you need that consistency, your code enforces it. Ask one question rather than its mirror, or reconcile the pair yourself. The build guide treats the whole jaggedness list as a set of design constraints rather than a bug report.
How to check calibration on your own data
Log every answer with its probability and, later, the true outcome. Bucket the answers by probability, say in ten bins. For each bin, compare the mean stated probability to the fraction that turned out correct. Plot the two against each other. A calibrated model sits close to the diagonal.
Do this per question type and per state shape. Calibration is not a single global property of a model, and a distribution that is honest on support ticket categories can drift badly on legal clauses. Self-consistency checks cover the related pattern of asking the same thing more than one way.
FAQ
Is there an RLCD paper?
No. An arXiv search on 20 September 2026 for “reinforcement learning for calibrated decisions” returned zero results. TypeSafe has published the name, a one-line objective in its docs and launch post, and nothing else: no dataset, no training code, no reward function and no evaluation methodology.
What is the difference between RLCD and RLHF?
RLHF rewards the answer a human rater prefers, which trains for persuasiveness alongside correctness. RLCD rewards probabilities that match observed outcomes, so a model gains nothing by sounding certain. TypeSafe’s own docs put it as training the model to return decisions and calibrated probabilities instead of generated text.
Can I train my own model with RLCD?
Not as TypeSafe defines it, because the reward function, the dataset and the training recipe are unpublished. Several Hugging Face models carry RLCD in their names, nearly all created within days of the launch, and none documents a reproduction of the method. You can still measure and tune calibration on your own data.
Does RLCD make Jev more accurate?
Calibration and accuracy are different things. RLCD targets honest probabilities, not a higher hit rate. A calibrated model tells you when it is unsure, which lets your code escalate those cases instead of acting on them. TypeSafe publishes accuracy figures for Jev on its own eval site, evals.typesafe.ai, but no calibration figures. Independent builders have measured calibration themselves; the Jev benchmarks guide collects their results.
Can I measure Jev’s calibration myself?
Yes, and it is the only way to get a number. Log each answer with its probability, record the real outcome, bucket by probability, then compare each bucket’s mean probability to its actual hit rate. Do it separately for each question type, since calibration varies by task.
Do complementary questions sum to 1?
No. TypeSafe’s jaggedness page for Jev 1.13 says there is no guaranteed mathematical relationship between related questions, so a yes/no question and its negation can both come back at 0.7. Enforce that kind of consistency in your own code if your logic depends on it.