People searching for Jev architecture or Jev RLCD usually want to know how Jev turns a question into calibrated probabilities without writing any text. The honest answer is that TypeSafe AI has not published it. Jev’s weights, base model, size and training recipe are private. This page collects everything TypeSafe and its founder have said in public, marks what is unknown, explains how the open models that copy Jev’s API actually work, and weighs the argument that Jev is “just a classifier”.

What TypeSafe has said

TypeSafe’s public description of Jev comes from its launch post, its docs, and founder Diogo Almeida’s replies on Hacker News and in a podcast. Put together:

  • Three parts. The launch post credits “a new model architecture, parallel sampler for maximum efficiency, and training method we call Reinforcement Learning for Calibrated Decisions (RLCD)”.
  • Parallel, not autoregressive. “Jev outputs all probabilities in parallel instead of autoregressively generating by token.” Every question about the same state is answered in one query.
  • No strings out. Almeida explained on HN that strings and other sequential outputs are not allowed at all, which is what lets every output be computed in parallel. That is why Jev has only three answer types: yes/no (TypeSafe calls this noul), choice (up to 255 options) and score (2 to 10 levels).
  • Not an LLM, in TypeSafe’s words. The launch FAQ says Jev “is neither small nor an LLM”. Almeida put it more narrowly: it is “technically not a language model (it doesn’t generate language)”.
  • A general model. No per-task training: you define the question at request time. Almeida prefers to call it “zero-shot”.
  • Same weights for everyone. The models page says Jev “is not fine-tuned or LoRA-adapted with customer data” and the same weights serve every account.
  • Synthetic data. The FAQ says “we make all the data ourselves”, and Almeida posted that it is entirely synthetic.
  • Known weak spots. TypeSafe publishes a jaggedness page for jev-1.13 listing nine failure modes, including arithmetic, date comparisons, large irrelevant state, and a bias toward options listed first.
Left: a text model writes its answer one token at a time, feeding each token back in, and the text then has to be parsed. Right: Jev reads the state and questions once and returns a typed answer with a probability for every question at the same time.
What TypeSafe has described: Jev returns every answer in one parallel pass instead of generating text. How that pass works inside is not public.

What RLCD is (and isn’t)

TypeSafe presents RLCD as the third way to post-train a pretrained model, next to two familiar ones:

MethodOptimises for (TypeSafe’s wording)Typical result
RLHFHuman preferenceChat assistants
RLVRVerifiable rewardsReasoning models
RLCD“Calibrated decisions: answers with epistemically honest probabilities on System One tasks”Jev

TypeSafe’s argument is that RLHF optimises for text a human rater prefers, which is the wrong target for automation, and that RLVR produces “spikey” intelligence. RLCD aims for the property in the docs primer: “Higher probability should correspond to a greater chance that the answer is correct.” Across many answers given at 0.9, about 90% should be right.

That is a goal, not a recipe. On the Latent Space podcast, Almeida described RLCD as “this new task” rather than a specific algorithm, and when asked whether it was published, said “No, not yet.” Nothing public names the reward function, the scoring rule (log loss, Brier score or something else) or the RL algorithm. Note too that other projects now use the name for their own objectives: Cloudflare describes a secondary training objective for Clef as RLCD, and Laya labels its REINFORCE training with proper scoring rules the same way. Those are their methods, not TypeSafe’s.

For how well calibration holds up in practice, including an independent test where Jev was confidently wrong on a question nobody could answer, see what Jev does.

What is not public

QuestionStatus
WeightsNot released. API only.
Base model, if anyNot stated. The docs draw RLCD as a branch from pretrained language models, and Almeida said on the podcast he “wouldn’t pre-train” even with a billion dollars and spoke about “Frankensteining” models together. Neither is a statement about Jev’s base.
Parameter count and sizeNot stated. The FAQ only says Jev is not small.
Transformer, encoder or decoderNot stated. Almeida: “architecture is close to the chest for now, but we have talked about writing a paper.”
RLCD reward, loss and algorithmNot published.
Training dataDescribed only as synthetic and made in-house.
Calibration metricsTypeSafe publishes none and chose not to report public benchmarks.

Some outsiders have tried to infer the design by probing the API, for example by comparing tokenizers and timing. Those write-ups label themselves as speculation, and so should anyone quoting them. Until TypeSafe publishes a paper, any confident statement that Jev “is” a specific model is a guess.

How open re-implementations work

Within days of launch, developers published open models that accept Jev’s request format. Their designs are public, and they show the common ways to build a decision model. None of them is Jev, and none claims to reproduce RLCD.

The core trick is shared: run a pretrained model once over the state and question (a “prefill”, with no text generated), then turn its internal signals into one score per option and normalise them into probabilities. Because nothing is generated, every option and question can be scored in parallel. The llama.cpp pull request that added these models describes them, a little bluntly, as “just fancy wrappers around traditional embedding models”.

A pretrained Qwen or BERT-style model reads the state, question and options once without generating text. Then either the label logits for options A, B and C are read directly, or a small trained head scores each option from hidden states, as in Clef, Kev, Laya and Open-Jev. Scores are turned into probabilities per question and calibrated.
The two published ways open models turn one prefill pass into probabilities. Neither is confirmed to be how Jev works.
ModelBackboneHow it scores optionsTraining and calibration
Clef and Clef-flash (Cloudflare)Qwen3.8-27B or Qwen3.5-9B, frozen, with rank-256 low-rank adaptersA prefill-only pass, then a small transformer head (Cloudflare calls it a routing or schema head) reads the final hidden states and gives one logit per option, softmaxed per questionLabel-smoothed cross-entropy plus a Brier loss, on internal synthetic data
Kev (Jared Palmer)Qwen3.5 0.8B–9B with LoRA; Kev-27B is a full fine-tune of Qwen3.8-27BA pointer head compares each option’s end-token hidden state with the question’s, then softmaxCross-entropy; one fitted temperature per checkpoint. The README says no Jev outputs were used.
LayaModernBERT-large (421M) or a multilingual BERT (322M), an encoder rather than a chat modelEach option gets its own mask token; a head scores it, then softmax over the question’s optionsREINFORCE with proper scoring-rule rewards; ships overconfident and needs temperature fitting
Open-JevQwen3.5 (2B, 9B, 27B) with LoRAA scalar head, initialised from the model’s own yes-minus-no signal, scores each candidate separatelySoft cross-entropy plus 0.1 × Brier; saved temperature
CLM-v0.1-8BQwen3-8B, frozenTwo projection heads embed the state and each option; probability comes from their similarityContrastive (InfoNCE) loss
“Jev in 25 lines”Qwen3-0.6B, unchangedReads the logits of the option letters A, B, C at the last positionNone. A deliberately minimal demo.

So there are two main families. One reads the language model’s own next-token logits for a label per option, as the 25-line demo does. The other trains a small head on hidden states, as Clef, Kev, Laya and Open-Jev do; Unsloth’s guide shows how to train one yourself on a small GPU. Which approach Jev takes, if either, is not public.

These designs explain why the open models differ in practice. Laya’s encoder is tiny and fast but reads only 512 to 1,024 tokens by default. The Qwen-based 27B models read more and some accept images, because their backbones do. For how they score against Jev, see Jev alternatives.

Is Jev just a classifier?

This was the most common reaction on Hacker News and X after launch, and it came back with Clef. Both sides have a point.

The case that it isn’t new

  • Probabilities over a fixed set of labels are what classifiers have always produced. Encoder models such as BERT gave calibrated-looking probabilities without generating text years ago.
  • Zero-shot classification already existed: constrain a language model to yes or no and read the logits, which is exactly what the 25-line demo does.
  • Several commenters argued the novelty is the branding and the use case rather than the architecture, and that “decision model” is a marketing name.
  • Almeida himself reached for the analogy, replying to a hallucination question with “Would you say a linear classifier hallucinates?”

The case that it is still useful

  • No training per task. A traditional classifier needs labelled data and retraining whenever the labels change. Jev takes new options, rubrics and questions in each request.
  • Breadth. One model handles routing, moderation, extraction checks and scoring across domains, which a classifier trained for one job doesn’t.
  • Calibration as the goal. Many zero-shot setups give probabilities that are not meant to be trusted. Jev is trained so that confidence tracks accuracy, though independent tests show this holds better on some question types than others.
  • Cost and speed close to a small classifier, with the reading ability of a large model.

Sebastian Raschka’s history of text classifiers lands in the middle: Jev is “not ‘just’ a text classifier” because labels and criteria are defined at request time, but its calibration still needs checking, and he suspects the advantage lies more in the data than in the training algorithm.

A practical way to settle it for your use: if you have thousands of labelled examples and fixed labels, a trained classifier may match Jev for less. One independent test cited in what Jev does found a statistical tie with a logistic regression trained on about 14,800 examples. If your labels change often, or you have no training data, a zero-shot decision model is where Jev and its alternatives earn their keep.

What this means if you use Jev

  • Don’t build on guesses about the internals. TypeSafe can change the model behind jev-latest. Pin jev-1.13.0 if you need stable behaviour, and re-test thresholds when the version changes.
  • Read the jaggedness page. Option-order bias and weak score-level calibration are documented. Shuffle options in tests and don’t treat a score of 2.5 as exactly halfway.
  • Check calibration on your data. RLCD aims for calibrated probabilities; it does not guarantee them for your inputs.
  • Keep code portable. Because open models copy the request format, you can compare Jev against Clef, Kev or Laya with the same code. Is Jev open source? covers self-hosting.

For the company behind the model, see TypeSafe AI.

Frequently asked questions

What is RLCD in Jev?

RLCD stands for Reinforcement Learning for Calibrated Decisions. TypeSafe says it trains Jev to give "epistemically honest probabilities", so that answers given with higher confidence are more often right. TypeSafe has not published the reward, loss or algorithm, and its founder has described RLCD more as a training goal than a single published method.

What architecture does Jev use?

TypeSafe has not said. Its launch post mentions "a new model architecture", a parallel sampler and RLCD training, and says Jev outputs all probabilities in parallel rather than generating tokens one by one. The base model, parameter count and internal design are private; the founder said the architecture is "close to the chest for now".

Is Jev an LLM?

TypeSafe says no: its FAQ calls Jev "neither small nor an LLM", and the founder says it is technically not a language model because it doesn't generate language. TypeSafe's docs also draw RLCD as a post-training path from pretrained language models, so Jev may well build on one. Whether it does is not public.

Are Jev's weights or training method public?

No. Jev is available only as a hosted API, and the same weights serve every account. The founder said in September 2026 that RLCD is not published yet and that TypeSafe has talked about writing a paper.

Is Jev just a classifier?

In output shape, yes: it returns probabilities over options you define. Critics point out that zero-shot classifiers and encoder models have existed for years. Supporters reply that Jev takes new labels, rubrics and questions at request time with no retraining, across a wide range of tasks, cheaply and with calibrated probabilities. Both points are fair; the useful test is whether it beats a classifier you could train on your own data.

How do open Jev alternatives like Clef and Kev work?

Most run a Qwen language model over the state and question once, then score each option without generating text. Cloudflare's Clef freezes Qwen, trains low-rank adapters and a small head that gives one score per option; Kev scores option end-tokens against the question token; Laya uses a ModernBERT encoder and scores a mask token per option. None of them claims to reproduce TypeSafe's RLCD.

Sources

Checked on 11 October 2026. Statements by TypeSafe and its founder are quoted from TypeSafe’s blog and docs, his Hacker News replies and the Latent Space transcript. Descriptions of open models come from their own model cards, READMEs and the llama.cpp source. Outside guesses about Jev’s internals are labelled as guesses. This site is not affiliated with TypeSafe AI or any project named here.