# Jev: State In, Typed Decisions Out

> Source: <https://julin.ai/2026/09/16/jev-typed-decisions/>
> Published: 2026-09-15 12:00:00+00:00

# 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.