Jev doesn't write. It decides.

What it actually is

Jev is a decision model. Not a chatbot, not an assistant, not a small LLM. It cannot produce a sentence, and that limitation is the design, not a shortcoming.

The interaction has exactly two halves. You send state — the context, which can be an email, a support ticket, a JSON object, a row from a database. And you send questions — each one a decision you want made about that state, with the allowed answers declared up front. Jev returns those answers, typed, each with a probability.

TypeSafe calls this class of model a System One Model. Your code doesn't parse anything. It branches on the values directly.

Where the two names come from

• System One — from Kahneman's Thinking, Fast and Slow. System 1 is fast, intuitive judgement; System 2 is slow deliberation. Jev is aimed squarely at the first.
• Jev — after the economist William Stanley Jevons. The Jevons paradox says that when a resource gets cheaper to use, total consumption goes up, not down. TypeSafe's bet is that the same happens to intelligence: make a decision cheap enough and you'll make millions more of them.

Why it exists

TypeSafe AI was founded by Diogo Almeida, previously at OpenAI where he worked on the instruction-following methods (RLHF) behind ChatGPT. The company spent roughly two years in stealth before launching Jev in September 2026.

Their founding question is a fair one, and worth sitting with for a second:

Their answer is that the bottleneck was never intelligence. Today's frontier models are already smart enough to do enormous amounts of useful work. The bottleneck is that they are awkward to build software on top of.

Look at how the two dominant training methods shaped what we got:

• RLHF trained models to produce answers humans like. That gives you a pleasant assistant — and a model that will tell you what you want to hear.
• RLVR trained models to produce answers a program can check — maths, code, tests. That gives you a reasoning model, slow and expensive by construction.

Both assume a human is sitting at the other end, reading. But TypeSafe expects large-scale automation to be roughly 99% machine-to-machine, with a human involved in a small fraction. Software talking to software needs different properties entirely: structured, testable, consistent, fast, cheap. They call this machine-native intelligence. Their slogan for it is "build prod, not God" — practical production systems rather than a race toward AGI.

The horseless carriage argument

TypeSafe's manifesto leans on an analogy that lands well. Early automobiles were literally called horseless carriages: the old carriage design with an engine bolted on, because nobody had yet worked out what a car should look like. Their claim is that chat-shaped AI inside automation is the same mistake — a genuinely new capability forced into the shape of the thing it replaces.

The comparison they draw is to databases. Databases existed for years before they enabled anything like Google. What changed was SQL: a dependable, composable interface that let ordinary software rely on them. TypeSafe wants an AI decision to become as dependable and as callable as a database query.

Whether or not they're the ones who pull it off, the observation is sound, and it's the most useful part of the story.

How it works

One request. Two parts. Three question types. That's the whole API surface, and it's small on purpose.

The state

A plain string, a JSON object, or an array of strings. Text only for now — no images, audio or video, so anything else has to be converted to text or a transcript first.

One thing that trips people up: an array is still one shared state, not a batch. Three support tickets in an array means "here are three documents about one situation", not "classify these three tickets". Separate items go in separate calls.

The questions

Each question carries a type, a key (the name you'll read the answer back by) and instructions in plain English. You can ask many in one request and they're all evaluated together. Crucially, questions are independent — one cannot see another's answer. If you need question B to depend on answer A, that's two calls with your own code in between.

The three question types

These three are the primitives — closer to logic gates than to prompts. Anything complicated gets built by combining many small questions with ordinary code, not by writing one elaborate instruction.

A real request

{
  "model": "jev-latest",
  "state": "Hi, I've been trying to connect my Stripe account for 3 days
            and it keeps failing. I'm losing sales. Please help ASAP.",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    },
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "options": ["billing", "technical", "account"]
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated is the customer? 0 = calm, 1 = frustrated, 2 = very frustrated"
    }
  }
}

And what comes back:

{
  "is_urgent":   { "type": "noul",   "noul": 0.999 },
  "team":        { "type": "choice", "choice": "technical",
                   "probabilities": { "billing": 0.06, "technical": 0.91, "account": 0.03 },
                   "confidence": 0.9 },
  "frustration": { "type": "score",  "score": 1.6 }
}

There is no text to parse and no malformed JSON to repair. Your code reads response.team.choice and moves on.

From code

from langchain_typesafe import Noul, TypeSafeClassifier

classifier = TypeSafeClassifier()
response = classifier.invoke({
    "state": "The deploy failed twice and customers are seeing 500s. Can someone look now?",
    "questions": {
        "urgent": Noul(instructions="Does this need attention right now?"),
    },
})
urgency = response.nouls["urgent"].noul   # e.g. 0.97

if urgency > 0.9:
    page_oncall()

Writing questions that hold up

Most of the difficulty in using Jev well is in question design, and it's a different discipline from prompt engineering. The patterns that work:

• Keep each question narrow and bounded. "Which team should investigate first?" is answerable. "Handle this incident" is not a question.
• Make options non-overlapping and observable. "Urgent" and "important" bleed into each other; definitions tied to something you could point at don't.
• Add an "insufficient evidence" option whenever the state might not support a decision. Otherwise you're forcing a guess and then trusting it.
• Ask what the evidence can actually support. "Which team should investigate?" and "which team caused the outage?" are very different questions about the same paragraph.
• Keep the evidence separate from the question — preserve timestamps and original wording rather than paraphrasing.
• Test for consistency. Reordering options or adding one can shift the result. Check that before you rely on it.
• Keep policy in your code. Jev proposes a decision. Whether to act on it is your application's business, and it should stay that way.

Why it's fast

The speed isn't a tuning trick. It comes from removing the single most expensive thing an LLM does: generating an answer one token at a time.

No generation loop

When an LLM answers "technical, 91% confident", it produces that one token at a time, each token waiting on the one before it. A reasoning model may produce hundreds or thousands of internal tokens before it gets to the answer you wanted. Processing the input is already parallel — it's the writing that's serial.

Jev never enters that loop. It reads the probabilities for every allowed answer directly out of the model's internal representations, in a single forward pass.

Encode once, branch in parallel

TypeSafe hasn't published the architecture. What follows is their public description plus an independent reconstruction based on roughly ten thousand API calls — so treat it as a well-supported guess rather than fact:

1. A transformer with pretrained knowledge processes the shared state once.
2. Each question becomes a separate branch attending to that shared state plus its own tokens.
3. An attention mask stops branches seeing each other — which is exactly why questions are independent.
4. Each branch's answer probabilities are read out directly.

The practical consequence: with a state of S tokens and Q questions, the repeated work drops from roughly Q × S to about S. Asking ten questions instead of one costs you the ten question tokens, not ten passes over the document. This is why batching your questions is the single easiest optimisation available.

The numbers, and how much to trust them

Two other factors are plausible but unconfirmed: a mixture-of-experts design (only part of the network running per token), and ordinary hardware-aware serving. Latency also depends on where you are — the service currently runs from the US west coast, which is a real tax if your users are in India.

Calibration: the real idea

Speed and price are the headline. Calibration is the part that actually changes what you can build, and it's the least understood thing about Jev.

Jev's training method is called RLCD — Reinforcement Learning for Calibrated Decisions. It sits alongside the two methods that produced everything else you've used:

What "calibrated" means

A model is well calibrated if, across many predictions, its stated probabilities match reality. Things it called 0.2 happen about 20% of the time. Things it called 0.8 happen about 80% of the time.

The thing calibration unlocks

Once probabilities are trustworthy, you can set thresholds. This is the whole game:

TypeSafe's objection to RLHF

Worth understanding, because it explains the whole design. RLHF rewards what sounds good to a person. That reliably produces two things nobody wants in an automated system: sycophancy, and hallucinations delivered in a confident register. It also causes mode dropping — the model narrowing toward one favoured style and quietly losing the other valid outputs it used to produce.

The core point stands regardless of what you make of Jev: being convincing to a human and being reliable for unattended software are different optimisation targets. We have spent four years optimising hard for the first one.

How RLCD might work

TypeSafe has not published the algorithm, so this is background rather than description. The standard ways to reward calibration are log loss (punishes assigning low probability to the right answer, and punishes confident mistakes severely) and the Brier score (squared difference between predicted probability and what happened). Post-hoc methods like temperature scaling can sharpen or soften probabilities without changing which answer wins. Which of these RLCD uses, if any, is unknown.

What is known: Jev is reportedly trained exclusively on synthetic data, which Almeida has described as one of the better bets he's made.

Jev vs an LLM

"Couldn't an LLM already do this?"

Functionally, yes — an LLM with structured output returns the same labels. The differences are all in the properties around the answer:

• Speed. Autoregressive generation can't easily get under a second.
• Cost. You pay for output tokens and any reasoning tokens, and output is where LLM pricing hurts.
• Confidence. An LLM writing "91% confident" is generating characters that look like a number. It isn't a measured probability. Jev's probability is the model's output distribution.
• Reliability. No parsing failures, no JSON repair step, no retry logic for malformed output.

Which one, when

Where it fits

Jev belongs wherever software makes many small judgements that are too fuzzy for hand-written rules, but too frequent or too time-sensitive to hand to an LLM.

On its own

The common thread: fast enough to run on everything rather than a sample, cheap enough that running it on everything doesn't change your margins, and calibrated enough to know which cases are safe to leave alone.

Alongside an LLM

This is the more interesting half, and the architecture is easy to state: Jev decides, the LLM writes.

Already shipped

• LangChain ModelRouterMiddleware — Jev picks the cheapest model that can handle each request.
• LangChain AutoModeMiddleware — Jev inspects risky tool calls (a bash command, say) and blocks them before they run. This brings the "auto mode" safety pattern of closed coding harnesses to any agent.
• Community work: browser agents running for fractions of a cent, a live trading agent, email triage at scale.

What actually changes

If you build automation for a living, here is the honest list of what a calibrated decision model moves — and it's less about capability than about which things stop needing a person.

And one that's easy to miss: things that were never worth automating become worth automating. Calling a model on every row, every message, every event or every game frame used to be absurd on both latency and cost. That constraint moving is where the genuinely new use cases come from, and it's the Jevons point the name is making.

Is this a transformation?

Our read: significant, but evolution rather than revolution — at least for now.

The likeliest shape of the next year or two is that serious AI stacks end up with two layers: a fast decision layer that routes, gates, scores, filters and verifies, and a reasoning layer that plans and writes. The real shift isn't Jev replacing LLMs. It's AI moving out of chat windows and into the background of ordinary software, making millions of invisible decisions a day that nobody reads.

The broader lesson, which outlives whatever happens to this particular model: the field is widening from one giant general model for everything, toward models built for the right constraints.

Cost, limits, access

Where to get a key

• TypeSafe console — console.typesafe.ai (early access / waitlist)
• Docs — docs.typesafe.ai
• Gateways — Vercel AI Gateway (experimental_evaluate in the AI SDK), OpenRouter, Cloudflare
• LangChain — pip install langchain-typesafe, then set TYPESAFE_API_KEY

What to stay sceptical about

This section exists because most of what's written about Jev right now repeats TypeSafe's own numbers without saying so. Here's the other side.

• The benchmarks are self-reported. The evals were built by TypeSafe's team, and they use the average of two frontier models as the "reference answer" — a proxy for ground truth, not ground truth.
• Type-safe is not the same as correct. Evaluate decisions against known outcomes before you let any of them trigger an action.
• Calibration may not transfer to your data. It has to be tested on your inputs, and re-tested as those inputs drift over time. Calibration measured elsewhere tells you very little about calibration here.
• The reported calibration figure covers mostly high-confidence predictions. It says much less about how the model behaves in the middle of the range — which is exactly where your escalation threshold will sit.
• Options are load-bearing. Adding or reordering choices can change results. Treat your option list as part of the system, and version it.
• The pricing may not be sustainable. TypeSafe concedes it can't yet prove the price isn't subsidised. They expect prices to fall; plan for the possibility they don't.
• It's early access. Availability, limits and model versions can change under you.
• Latency depends on geography. Serving is currently US west coast. From India that's a meaningful share of your budget before the model does anything.
• There is no paper. No calibration curves, no methodology, no independent reproduction. Everything structural in this page's section 4 and 5 is reconstruction, and we've flagged it as such where it is.

How to start

Not "migrate your stack". Pick one decision your system already makes badly, and measure.

1. Pick one bounded workflow — a single routing or classification step. Something where you already know what the right answer looks like, and where being wrong is recoverable.
2. Log predictions next to real outcomes. Don't act on them yet. Run Jev in shadow alongside whatever you do today, and write both to the same table.
3. Measure accuracy within each confidence band — not overall. Overall accuracy tells you nothing about where to put a threshold. You want to know how often the 0.9-to-1.0 bucket is right, separately from the 0.6-to-0.7 bucket.
4. Set thresholds from the cost of mistakes, not from round numbers. If a missed urgent ticket costs nine times what a needless escalation costs, escalate whenever the probability of urgent is above 0.1 — even though that feels far too low.
5. Expand only where the evidence supports it. Each new workflow gets its own shadow period. Calibration on one task says nothing about calibration on the next.

Glossary & sources

Sources

Primary material from TypeSafe, plus the independent write-ups that informed the architecture and speed sections. Where the two disagree, we've said so in the text.

• TypeSafe AI — Introducing System One Models & Jev
• TypeSafe AI — Manifesto
• TypeSafe Docs — System One concepts
• TypeSafe Docs — AI primer
• LangChain — Building a harness with Jev
• Vercel — What is Jev?
• Bijit Ghosh — Inside Jev: architecture of a decision model
• Anthony Maio — Jev: the language model that won't
• systemonemodels.org — RLCD explained
• MindStudio — RLCD vs RLHF