Jev: State In, Typed Decisions Out

TypeSafe announced Jev, a model that takes unstructured state as input and returns typed, probabilistic decisions — Choice, Score, and Noul — rather than free text, claiming it is 20-200x faster and 40-400x cheaper than a normal LLM call. TypeSafe says the questions run in parallel over a single encoded state and that adding more questions "barely changes response time," while the company's post-training method, Reinforcement Learning for Calibrated Decisions (RLCD), targets correct, calibrated probability distributions. TypeSafe has not published Jev's architecture, and the article notes that an existing model, Qwen-2.5-1B-RLCD, achieves similar constrained output on top of Qwen2.5-1.5B-Instruct without a new architecture.

Jev: State In, Typed Decisions Out Diogo Almeida posted on X https://x.com/CompleteSkeptic/status/2099925682726002904 about a new model, Jev, from a company called TypeSafe. The claim: 20-200x faster and 40-400x cheaper than a normal LLM call, built for making decisions rather than writing text. What it actually does A normal LLM takes unstructured state in and returns unstructured text out. Ask it “given this incident, what should we do?” and it answers with something like: <think Let's look at the incident closely...</think Fetch up metric for service A. Jev takes unstructured state in and returns typed, probabilistic decisions out. Ask it the same question, and it returns something like: {"check up metric": 0.9, "page engineer": 0.1} TypeSafe ships three primitives for this: - Choice — a categorical distribution over a fixed set of alternatives. - Score — a distribution over an ordered scale. - Noul — the probability that a boolean statement is true. Every question sees the same state, and each one runs independently. TypeSafe says the questions are computed in parallel, not generated one token after another. It can’t produce text Choice, Score, and Noul all output a probability distribution over a fixed schema you define upfront. None of them output free text. That constraint is what makes the speed and the “can’t hallucinate” claim possible in the first place. I saw someone work around this anyway. Define a Choice over a single-character alphabet, “which letter comes next,” and ask that question over and over, appending each answer to the state before the next call. Run enough rounds, and you’ve spelled out a sentence one character at a time. It works, but it’s an abuse of the design. Each character costs a full round of encode-plus-head, so generating a paragraph this way costs far more than a normal model just writing the paragraph. Jev is built to pick one of a few known options fast, not to write open-ended text. Why it can run this fast My best guess at the architecture: One expensive step encodes the input state into a representation $h = \text{Encoder} \text{state} $. After that, each question runs a cheap head over that same $h$: $p i = \text{Head} h, \text{question} i $. In the diagram, the encoder box lights up once per request, and the head boxes light up together. Compare that to a normal LLM, which generates a probability over the next token conditioned on everything before it: $$ p x t \mid x {<t}, \text{state} $$ and repeats that hundreds or thousands of times to produce a full answer. Jev skips the repetition. TypeSafe says adding more questions “barely changes response time,” and recommends firing off every question you might need in one request, then throwing away the answers you don’t use. TypeSafe hasn’t published the architecture, so this is a guess. Can an LLM do that too? Yes. Qwen-2.5-1B-RLCD https://huggingface.co/harshatheg/Qwen-2.5-1B-RLCD does it on top of an ordinary instruction-tuned model, Qwen2.5-1.5B-Instruct , no new architecture needed. One caveat: the repo name says RLCD, but what it describes is an inference-time technique, constrained decoding plus a softmax over masked logits, bolted onto a model that was never trained with a calibration reward. A softmax score isn’t automatically a calibrated one. The masking can guarantee the output is always a valid schema value. It can’t guarantee that 0.99 means “correct 99% of the time.” The real claim: RLCD Reinforcement Learning for Calibrated Decisions RLCD is the post-training method TypeSafe uses, and it’s the more interesting part of the announcement. TypeSafe lines it up against two other post-training objectives: RLHF: human-preferred text RLVR: correct or verifiable answers RLCD: correct, calibrated probability distributions RLHF is Reinforcement Learning from Human Feedback. RLVR is Reinforcement Learning with Verifiable Rewards. TypeSafe’s definition of “calibrated” is the standard statistical one: if Jev outputs 0.8 across many similar predictions, about 80% of them should turn out correct. TypeSafe hasn’t published the RLCD algorithm. The closest published work I found is RLCR Reinforcement Learning with Calibration Rewards https://proceedings.iclr.cc/paper files/paper/2026/hash/615675cc6e94ddb1a783904fb178b5f6-Abstract-Conference.html . Its reward is a simple combination of correctness and a Brier score. “Can’t hallucinate”? TypeSafe says Jev “can’t hallucinate.” I read that as a claim about the output’s shape. If the schema is: Choice "refund", "rebook", "support" Jev cannot return "give customer a free spaceship" . No malformed JSON, no invented enum value, no fake function name, no stray prose, no parser failure. But it can still assign the wrong option a high probability. It might return page engineer: 0.9 when paging the engineer is the wrong call. Whether that happens depends on the training data, same as any model.