Jev:TheAIThatDoesn'tWrite—ItDecides(200×Faster)

Here's something I didn't fully appreciate until recently: most of what companies actually use large language models for isn't writing. It's deciding.

Is this support ticket urgent or not? Which of these five categories does the email belong in? On a scale of 1–5, how good is this answer? Is this transaction fraud — yes or no? These are the calls that run millions of times a day inside real products. And today, we answer them with models built to write novels.

A new release from a company called TypeSafe AI takes a different swing at this. The model is named Jev, launched in September 2026, and it's the first of what they call "System One models." The pitch is blunt: for decisions, stop generating text. Just return the decision — with a confidence number attached.

The slow way we do it today

When a normal LLM makes a decision, it does it by writing. Ask it to classify something and, under the hood, it generates the answer one token at a time — hundreds or thousands of tiny sequential steps — even if the final answer is a single word like "urgent." That's a lot of machinery to produce one label.

It works, but it's slow, it costs real money at scale, and the answer comes back as free text you then have to parse and trust. It also tends to be overconfident — the model says "definitely yes" whether it's 95% sure or 55% sure.

What Jev does instead: parallel sampling

Jev's trick is that for a decision, the possible answers are already known. If you're picking one of five categories, there are exactly five options. So instead of writing the answer out token by token, Jev computes a probability across all the defined choices in a single forward pass, and hands back the top one.

That's the "parallel sampling" idea: one pass over a fixed menu of options, rather than a long sequential generation. TypeSafe reports end-to-end responses in the 70–500 millisecond range. It answers three shapes of question:

• Choice — pick one of up to 255 predefined options.
• Score — rate something against a scale or described levels.
• Yes / no — a single probability between 0 and 1.

And here's the part I like most: every answer comes back with the probability mass over the options and a calibrated confidence score — not just a bare label. So you don't only get "category B"; you get "category B, 78% confident." That's the "score the choice probability" piece — the model tells you how sure it is, in a number you can actually act on.

Calibration is the whole point

A calibrated model is one whose confidence matches reality: when it says "70% sure" across many cases, it's right about 70% of the time — like a good weather forecaster. That's genuinely useful. A calibrated confidence lets you set a threshold: auto-approve above 90%, send the rest to a human. You can't do that safely with a model that says "definitely" all the time.

TypeSafe says Jev is trained for this using a method they call RLCD — Reinforcement Learning for Calibrated Decisions — rewarding the model when its stated confidence lines up with whether it was actually right. (One caveat below on that name.)

Where this sits: RLHF vs. RLVR vs. RLCD

It helps to see these as three different things you can reward a model for:

• RLHF — Reinforcement Learning from Human Feedback. The standard recipe behind ChatGPT and friends: collect human preferences, train a reward model, then tune the model to produce answers people prefer. It optimizes for human preference. (InstructGPT paper)
• RLVR — Reinforcement Learning with Verifiable Rewards. Instead of a learned reward model, you use a checker that knows the right answer — did the math come out correct, did the code pass the tests? It optimizes for verifiable correctness, and it's a big part of why today's reasoning models got good at math and code. (Tülu 3, where the term was popularized)
• RLCD (TypeSafe's version) — Reinforcement Learning for Calibrated Decisions. Optimizes for calibration — confidence that matches real accuracy.

Human preference, verifiable correctness, calibrated confidence. Three different targets, three different tools.

The speed and cost claims — read with care

This is where I'll be straight with you, because the numbers are eye-watering and they come from the vendor.

TypeSafe claims Jev is roughly 20–200× faster and 40–400× cheaper than using a frontier LLM for the same decisions, with a headline real-world example of ~193× faster and ~444× cheaper. On pricing, they quote input at $0.042 per million tokens with output tokens free, versus frontier models in the dollars-per-million range.

Two things to keep in mind:

1. These are TypeSafe's own figures, measured against their own "workflow evals" using an average of two frontier models as the reference — not an independent, public benchmark. TypeSafe itself notes the biggest gains sit at the high end of real usage.
2. As of now there's no paper, no code, and no disclosed architecture. The mechanism above is reconstructed from the company's blog and third-party write-ups, not a peer-reviewed method. Treat the specifics as a well-described product claim, not settled science.

So: promising direction, genuinely useful idea (calibrated decisions as a first-class output), impressive-if-true numbers. I'd want independent benchmarks before betting a production system on the exact multipliers.

Two naming gotchas

Because I got tripped up by both:

• "Jev" is not an acronym. It's just the product name, like "Claude" or "Gemini." If you saw it written "JEV," that's the same thing.
• "RLCD" is an overloaded name. TypeSafe uses it for Reinforcement Learning for Calibrated Decisions. But there's an older, unrelated academic method also called RLCD — Reinforcement Learning from Contrastive Distillation (ICLR 2024), which is about generating preference pairs. Same letters, different thing.

Straight from the source (on X)

Most of what we know comes from the founder himself. Diogo Almeida — who describes himself as a co-creator of RLHF / ChatGPT and is now TypeSafe's CEO — announced Jev on X (@CompleteSkeptic) after roughly two years in stealth.

• His launch thread frames the motivation: even superhuman chat hasn't gotten us to AGI, so maybe "decisions" need a different kind of model.
• In a follow-up he's upfront about the trade-off — Jev can't generate text at all; it's parallel-not-sequential, which he compares to how Transformers leapfrogged older sequential networks.
• A useful usage note: Jev works better when you break a task into smaller, well-scoped questions.

The official account @typesafeai posted that Jev is now available to everyone, no waitlist. Worth reading as the makers' own framing — not independent analysis.

Try it yourself: the repo, the SDK, and a quickstart

There is an official codebase. The Python SDK lives on GitHub at typesafe-ai/typesafe-sdk-python ("the official Python library for the TypeSafe API"), with full docs at docs.typesafe.ai.

Getting started looks like this:

pip install typesafe-sdk        # or: uv add typesafe-sdk
export TYPESAFE_API_KEY="your-key"

from typesafe_sdk import Choice, TypeSafeClient

with TypeSafeClient() as client:
    response = client.system_one(
        state={"document": "I was charged twice. Please fix this ASAP."},
        questions={
            "category": Choice(
                instructions="What is this ticket about?",
                criteria={"billing": None, "technical": None, "other": None},
            )
        },
    )

print(response.choices["category"].choice)   # -> "billing" (with a confidence score attached)

Notice there's no prompt-wrangling and no output to parse — you hand it a fixed set of criteria, and it returns one of them plus a calibrated confidence. The three building blocks are Choice (pick one), Score (rate on a rubric), and a yes/no question type. Pricing at launch: $0.042 per million input tokens, output free (docs).

Heads-up: only the typesafe-ai GitHub org is official. There are several community "awesome-jev" and unofficial-client repos floating around — handy for examples, but not maintained by TypeSafe.

5 tips for your first time with Jev

1. Pre-define your options carefully. Jev can only return something from the criteria set you give it — that's the feature that stops it hallucinating a category that doesn't exist. Your option list is the design work.
2. Ask one small, well-scoped question at a time. Don't hand it a giant multi-part task. Decompose it into simple questions and stitch the answers together with your own code — the founder's own advice, and it matches how the API is built.
3. Actually use the confidence. The calibrated probability is the whole point. Set a threshold — auto-act above, say, 90%, and route the uncertain cases to a human. A bare label throws that away.
4. Match the primitive to the decision. Use Choice to pick one, Score to rate against a rubric, and the yes/no type for a single true/false call. Picking the right shape gives you cleaner probabilities.
5. Benchmark on your own data before trusting the headline numbers. The 20–200× speed and 40–400× cost claims are TypeSafe's own, on their own evals. Run it on your tasks and check both accuracy and calibration before you wire it into anything that matters. And remember: it can't write — pair it with a normal LLM for any text you need generated.

Why I think this matters

The interesting shift here isn't the benchmark numbers. It's the reframing: not every AI task needs a model that talks. A huge share of real-world AI is quiet, high-volume decision-making, and for that, a fast model that returns a calibrated probability may simply be the right tool — cheaper, faster, and easier to build reliable systems around.

Whether Jev specifically is the one that wins, we'll see. But "typed, calibrated decisions instead of generated text" feels like a category that's here to stay.

---

Sources: TypeSafe's Jev launch · Official Python SDK (GitHub) · Docs · Diogo Almeida on X · @typesafeai · Tülu 3 (RLVR) · InstructGPT (RLHF) · DPO · RLCD — Contrastive Distillation. Speed and cost figures are TypeSafe's own, self-reported against their internal evals, and not independently verified at the time of writing.