WHAT IS JEV?

WHAT IS A SYSTEM ONE MODEL

TypeSafe borrows the name from Daniel Kahneman. System 2 thinking is slow, deliberate and effortful; System 1 is fast, automatic and intuitive. Every reasoning model on the market is System 2 by design — chain of thought is literally the product, and the longer the model thinks the better it tends to do. Jev is the other one. A System One model does not deliberate in the open. Jev looks at the state and answers.

Architecturally that means Jev is not a language model, even though Jev is a transformer. There is no autoregressive decoding, so there is no token-by-token generation to wait through. A parallel sampler produces every answer in the request at once. This is why asking Jev six questions about one state costs roughly the latency of asking Jev one — a property that shapes how people actually design around Jev.

Jev was trained with a method TypeSafe calls RLCD, Reinforcement Learning for Calibrated Decisions. Where RLHF optimises for what humans prefer and RLVR optimises for verifiable answers, RLCD optimises for honest probabilities: when Jev says it is 70% sure, Jev should be right about 70% of the time. Calibration is the feature, and it is what makes a Jev confidence number safe to put a threshold on.

Not everyone accepts the framing. A common criticism is that Jev is a zero-shot classifier wearing frontier-model clothes, and that calling Jev a frontier model borrows credibility it has not earned when it cannot code, chat or write a sentence. That argument is worth taking seriously. What it does not explain is why several hundred developers pointed Jev at production problems within a week of release, which is the part of the story this site exists to document.

HOW JEV WORKS

A Jev request has exactly two parts. The state is whatever context the decision depends on — a ticket, a page, a diff, a candidate passage, a game frame — passed as text or as a structured object. The questions are what you want decided about that state, each declaring its type and its allowed answers up front.

Jev answers all of them in one parallel pass and hands the result back to your code. Your code then does what code is good at: reading the confidences, applying thresholds, enforcing authorisation, and performing side effects. Jev never acts. That division is the whole design, and every good Jev integration respects it — the model supplies judgement, the program keeps control.

This is also the safety story. Because Jev cannot call a tool, cannot write an argument and cannot emit a side effect, the blast radius of a wrong Jev answer is bounded by whatever your code does with a number. That is a very different risk profile from handing an agent a tool belt and hoping the prompt holds.

CHOICE, SCORE AND NOUL

Part of what is Jev, concretely, is that it has three question types. That is the entire surface area of the model, and the constraint is the point — you cannot ask Jev anything whose answer space you have not already drawn.

CHOICE

Pick one option from a set you define. Jev returns a probability for every option plus an overall confidence, so you see not just the winner but how close the runner-up was. One Jev Choice question can carry up to 255 options; deeper taxonomies are handled by chaining questions rather than by one huge list.

SCORE

Rate the state against ordered levels you describe — calm, concerned, angry; minor, material, critical. Jev returns a continuous value, the distribution behind it, and a confidence. Because the levels are described rather than numbered, a Jev Score question reads like a rubric instead of an arbitrary one-to-ten.

NOUL

Ask whether a statement about the state is true. Jev returns the probability that it is. This is the type most guardrails are built from — is this tool call destructive, does this passage support the claim, did the agent actually finish. Some SDKs spell the same Jev type type: "boolean".

from typesafe_sdk import Choice, Noul, Score

questions = {
    "intent":      Choice(instructions="Why is this customer writing in?",
                          criteria={"bug": "...", "billing": "...", "other": "..."}),
    "is_urgent":   Noul(instructions="Does the message state time pressure?"),
    "frustration": Score(instructions="How frustrated does the customer sound?",
                         criteria=["Calm", "Concerned", "Angry"]),
}

Because Jev runs the questions in parallel, the common design move is to ask more than you strictly need and let code discard the irrelevant answers. TypeSafe's own playbook calls this speculative fan-out, and it is only affordable because Jev prices output at zero.

WHAT JEV ACTUALLY RETURNS

The most practical part of what is Jev is this: every Jev answer arrives with a calibrated confidence, and that number is the most useful thing in the response. It lets your code express a policy a bare label cannot: act automatically above 0.8, queue for review between 0.5 and 0.8, escalate to a human below that. The threshold lives in your code, where you can reason about it, test it and change it without retraining anything.

Jev also cannot produce a type error. The answer is drawn from the schema you supplied, so there is no malformed JSON, no invented enum member, and no retry loop wrapped around a parser. TypeSafe reports a 0% structured-output error rate and a 0% tool-call error rate for Jev, and unlike the accuracy numbers, this one follows from the architecture rather than from training.

import { experimental_evaluate as evaluate } from 'ai';

const result = await evaluate({
  model: 'typesafe-ai/jev',
  state: 'The support agent issued a full refund to the customer.',
  questions: {
    refunded: {
      type: 'boolean',
      instructions: 'Was a refund issued?',
    },
  },
});

if (result.refunded > 0.8) closeTicket();

WHAT JEV COSTS

Jev costs $0.042 per million input tokens, and Jev output is free — TypeSafe's phrase is "too cheap to meter," which is easier to say when the output is a handful of floats rather than an essay. There is no free tier on any route, so the first Jev call is billed like every other one.

Put concretely: half a million decisions a month at 800 input tokens each costs under twenty dollars on Jev. The same workload on a general-purpose model of the class Jev is benchmarked against runs into the high hundreds or low thousands. Our Jev vs text LLMs page has a calculator you can move to see where your own volume lands.

One Jev specification is genuinely unclear. Vercel's model page lists the context window as 32,000 tokens, while several press write-ups say 64k. We have not been able to settle it against primary documentation, so we are flagging the conflict rather than picking a side.

JEV BENCHMARKS, HONESTLY READ

Two numbers follow Jev everywhere: 193.6 times faster, 444.6 times cheaper. They are real measurements, but they come from a single recorded demo in which Jev plays Doom, not from the benchmark suite. The suite is less flattering and considerably more useful.

Anyone asking what is Jev good at should read the accuracy column before the cost column. Jev does not win it. On TypeSafe's own 711-case suite Jev ties GPT-5.6 Terra and trails GPT-5.6 Sol and Opus 5 by five to six points, and on the weakest sub-task — invoice processing — the gap is far wider than the aggregate suggests.

What Jev wins is the trade, and the trade is enormous: roughly Terra's accuracy at about one seventy-sixth the cost and one twenty-fifth the latency. If your decision tolerates Terra-level accuracy — and most routing, triage and filtering decisions do — then Jev is not a compromise.

If your decision needs Sol-level or Opus-level accuracy and cannot be gated behind a confidence threshold, Jev is not the answer and no amount of cost saving changes that.

Two caveats belong on every Jev benchmark claim, including the ones on this page. The Jev weights are not public and the table above is scored by the vendor selling the model, so nothing in it has been reproduced by anyone else. And the accuracy figure measures agreement with a model-generated reference, which is not the same thing as being right. Independent evaluations of Jev do exist now — they are listed below, and they do not flatter it either.

WHEN NOT TO USE JEV

Understanding what is Jev also means knowing where it breaks. The failures below are not edge cases. They are the shape of the model, and knowing them is most of what separates a Jev integration that works from one that quietly degrades.

The judgement reduces to one sentence. Use Jev for high-volume, repeated decisions over shared state where every possible answer is known before the call. Everything else still wants a text model — and in practice most systems run both, with Jev as the cheap gate in front of the expensive one.

HOW TO START USING JEV

TypeSafe dropped the Jev waitlist on 20 September 2026, so a console.typesafe.ai account is the shortest way in, and it opens with $5 of credit. Several gateways serve Jev at the same published price: Vercel's AI Gateway exposes Jev as typesafe-ai/jev through the AI SDK's experimental evaluate path; Cloudflare Workers AI and OpenRouter both carry Jev as well. The official SDKs are typesafe-sdk for Python and @typesafe-ai/sdk for JavaScript, and LangChain, Pydantic AI and a growing set of MCP servers all have first-class Jev support.

The fastest honest way to answer what is Jev good for in your own system is to look at what other people already pointed Jev at. The two indexes below between them cover most of the shapes a Jev integration takes.

PROJECT INDEX · DECISION PATTERNS