RLCD, and what is actually known about it

The positioning#

TypeSafe places RLCD as a third branch off a pretrained language model, alongside the two everyone already knows:

The output contract RLCD is said to optimise for is stated in three lines in TypeSafe's AI primer: the model does not generate text; it returns decisions and probabilities; higher probability should correspond to a greater chance the answer is correct.

Mode dropping, the stated motivation#

TypeSafe's argument for why a new method was needed centres on what RLHF does to a distribution. Preference optimisation causes mode dropping — the model learns to favour a particular style, such as instruction following, while reducing the probability of other possible outputs. The probabilities that survive that process are shaped by what raters liked, not by how often the answer is right.

If your product is the probability, that is fatal. So the claim is not that RLHF models cannot classify — obviously they can — but that their confidence numbers are not recoverable as calibrated ones, however you prompt for them.

What has not been disclosed#

• The reward formulation. Whether it is a proper scoring rule — Brier, log loss — used as an RL reward is unstated.
• The base model, parameter count, and architecture of the sampler.
• The training data. TypeSafe says only that Jev is not trained on customer requests or responses.
• Any ablation, any benchmark against an RLHF baseline trained the same way, any reliability curve.
• A paper or preprint. On Hacker News the CEO said the architecture is "close to the chest for now, but we have talked about writing a paper," and argued data matters more than architecture.

Two things to keep straight#

RLCD is a training method, not an architecture#

The Register's launch coverage described RLCD as "a different architecture". That is wrong, and it matters because the two claims have different evidential status. The architecture claim is a parallel, non-autoregressive sampler — which is at least partly verifiable from the outside, since you can measure whether latency scales with the number of questions. The training claim is RLCD, and nothing about it is externally checkable today.

There is an unrelated paper with the same acronym#

Anthropic published RLCD: Reinforcement Learning from Contrastive Distillation in 2023. Different method, different problem, same three letters. If you search for the term you will find that one first.

Is the idea itself new?#

Not entirely, and TypeSafe has not claimed otherwise in its documentation. Reinforcement learning aimed at calibration has prior art — Maio points to work such as Rewarding Doubt. What is new is the packaging: a hosted frontier-scale model whose entire output contract is typed decisions with calibrated probabilities, defined per request with no training step of your own.

That is a real product even if the method turns out to be an assembly of known parts. It is also why the evaluation question keeps coming back to calibration metrics rather than architecture disclosure: you do not need to know how it was built to test whether the probabilities are honest, and that test is the one that matters.