What Is Jev? TypeSafe AI's Decision Model and Where It Fits in an AI Gateway

Software already leans on AI for decisions. A support system decides which queue a ticket belongs in. An agent decides which tool to call next. A gateway decides which model should serve a request. The common way to make these decisions today is to ask a generative LLM: write a prompt, request JSON, parse the response, validate it, and retry when the model returns something the schema did not allow.

Jev inverts that flow. The application declares the valid answers before the model runs. Jev evaluates the current state against those typed questions and returns one of the declared answers, with a probability attached. There is no prose to parse, and there is no way for the model to answer outside the schema.

TypeSafe AI announced Jev in early access on September 15, 2026, describing it as “a frontier-intelligence function call” and calling it the first of its System One models. A day later, Vercel made Jev available through its AI Gateway as typesafe-ai/jev. Unlike a traditional LLM, Jev is designed to return constrained decisions rather than generate prose.

What is a System One model?

System One model is TypeSafe AI’s name for its own class of model rather than an industry-standard category, and Jev is the first one the company has shipped. A System One model is built for fast, focused decisions inside software: it consumes state plus typed questions and returns typed decisions and probabilities instead of generated prose. The name borrows the fast, intuitive “System 1” mode of thinking from Kahneman’s work, as opposed to slow deliberate reasoning. The framing describes speed and shape rather than reliability: a System One model answers quickly, and it can still answer wrong, which is why the probabilities exist.

How Jev works: state in, typed decisions out

The shape of every Jev call is the same:

state + typed questions ──► Jev ──► typed answers + probabilities

The application sends two things: the state (a string, object, or array describing the situation) and a set of typed questions, each declaring its valid answers. Per TypeSafe’s documentation, there are three question primitives:

• Choice chooses one option from a predefined list (up to 255 options).
• Score places the state on an ordered rubric the application defines.
• Noul estimates whether a statement about the state is true, returned as a probability between 0 and 1. Vercel’s integration describes this primitive as a Boolean question.

Two properties of the answers do most of the work. First, every answer arrives typed: route comes back as one of billing / support / fraud, never as a paragraph that mentions billing. Application code branches on the result directly instead of parsing and validating text. Second, every answer carries probability information, in two shapes worth keeping distinct. Choice and Score return a probability distribution over the declared options, plus a derived confidence value: a single statistic describing how concentrated that distribution is, provided so code can threshold on one number. Noul returns the probability of true itself and carries no separate confidence field.

A generative LLM produces output one token at a time, and a response with many parts takes proportionally longer. Jev evaluates all declared questions in parallel and in isolation against the same state, so a call with five questions costs roughly what a call with one question costs, and the questions do not contaminate each other’s context.

Jev vs. a traditional LLM

The rows compound. Because output is constrained, there is nothing to parse. Because there is nothing to parse, there is no retry loop for malformed responses. Because uncertainty is explicit, the application can automate the confident cases and route the uncertain ones to a person. A generative LLM can be pushed toward each of these properties with structured-output modes and careful prompting; Jev’s design starts from them.

What is Jev used for?

The use cases TypeSafe and Vercel document are the judgment calls that sit inside software today:

• Choose the next tool an agent should call, or choose a subagent to hand work to.
• Decide whether an agent should continue, retry, ask the user, or stop.
• Route a request to a queue, a workflow, a model, or a team.
• Score risk or urgency before acting on something.
• Verify an output: judge whether a generated answer meets a bar, enforce a guardrail, or detect a prompt-injection attempt before it does damage.
• Trigger human review when confidence is low, which is less a use case than a property every other use case inherits.

The pattern across all of them: the set of valid outcomes is known ahead of time, the input state is messy, and the decision has to be cheap and fast enough to sit inside a request path or an agent loop.

A Jev decision, end to end

A customer requests a refund on day 45 of a 30-day refund window. The application declares three questions: route (a Choice among billing / support / fraud), risk (a Score of low / medium / high), and autoApprove (a Noul asking whether the refund qualifies for automatic approval). One call returns a route and a risk answer, each with Jev’s derived confidence, plus a probability that the auto-approval statement is true. What to do with those numbers is the application’s decision.

The figure below runs that decision under three different automation policies. The state and the answers never change. What changes is the certainty the application requires before it acts without a human:

Because every answer carries a probability, the application can implement a policy that was previously awkward to express: high confidence leads to automation, low confidence leads to escalation. The useful question stops being only “what should the system do?” and becomes “is the system confident enough to do anything at all?”

Where Jev fits in an AI gateway

An AI gateway is the company-controlled endpoint that AI traffic passes through, and routing is one of its five responsibilities: deciding, per request, which provider, model, tool, or path should handle the work. Most writing about dynamic routing assumes the decision is made either by static rules or by another generative model reading the request.

A decision model adds a third option to that picture:

request
 │
 ▼
AI GATEWAY
 │  evaluate intent and state
 ▼
decision model (e.g. Jev)
 │  typed answer + probability
 ▼
model A │ model B │ skill │ tool │ human │ stop

Model routing does not always require another generative model. A decision model can evaluate the request first and let the gateway determine what should happen next: send routine work to a cheaper model, send hard work to a frontier model, answer from a cache, invoke a tool, or hold the request for review. The decision itself is fast enough and cheap enough to run on every request, which is the constraint that rules out most generative approaches on the hot path.

The gateway still owns everything around the decision: the policy that constrains which answers are allowed to take effect, the record of what was decided and why, and the fallback when the decision layer is unavailable. That division of labor is the subject of the semantic gateway page.

Can Jev do semantic routing?

Yes, with nuance worth being precise about. Semantic routing names routing schemes whose decision signal comes from reading the request. Jev can produce exactly that signal: classify the request’s intent as a Choice, score its complexity as a Score, and return a constrained routing decision with a confidence value. That makes it a natural component of a semantic-routing system.

Jev is a model rather than a router, so it is one component instead of the system. Something still has to sit on the request path, derive the state to evaluate, call the model, apply policy to the answer, handle the low-confidence cases, and forward the request. In gateway terms, Jev can supply the decision signal; the semantic gateway is the deployment that applies it to traffic and answers for the result.

Why use a decision model instead of a generative LLM?

Teams pick a decision model over prompting a generative LLM for cost, latency, and control.

Cost. A routing or verification decision does not need paragraph generation; it needs one answer from a known set. TypeSafe prices Jev input at $0.042 per million tokens with output free. Decisions that run on every request stop being a meaningful line item.

Latency. Request-path decisions have a latency budget: a router that adds seconds to every call is a router nobody enables. TypeSafe reports end-to-end response times of 70 to 500 milliseconds, and up to 193.6x faster and 444.6x cheaper than generative LLMs on its own workflow evaluations. Those numbers deserve their caveats, which TypeSafe itself discloses: the workflows were built by its own team, the reference answers averaged two frontier LLMs, and the headline figures sit at the high end of real-world gains. Treat them as vendor-reported until independent benchmarks exist. The claim that matters architecturally is more modest and more durable: a model that skips token-by-token generation can answer in the time budget a request path allows.

Control. The application defines valid outputs before inference rather than asking an LLM to generate something and validating it afterward. The failure mode shifts from “the model returned something my parser cannot handle” to “the model picked the wrong valid answer,” and the probabilities give the application a principled way to catch the second case.

Jev confidence scores and human-in-the-loop automation

TypeSafe trains Jev with a method it calls Reinforcement Learning for Calibrated Decisions (RLCD), and calibration is the property the company leads with: across many predictions, outcomes assigned a probability of 0.8 should occur about 80% of the time, so the numbers are information an application can act on rather than decoration. Its framing of why this matters is worth restating in plain terms: a model that does a task correctly 95% of the time, but cannot tell you when it is in the other 5%, cannot safely automate that task. A model whose probabilities flag its own uncertain answers can.

That is the property the worked example above demonstrates. The threshold becomes a policy dial the team owns, applied to Jev’s derived confidence for Choice and Score answers or to a Noul probability directly: set it permissively and more decisions automate, set it conservatively and more decisions reach a human. The dial can differ per question, per team, or per blast radius of the action being automated. None of that logic lives in the model. It lives in the application, or, when the decision runs on the request path, in the gateway, where the threshold sits next to the policy, the budget, and the record of every decision made.

Jev vs. rules, classifiers, and LLM routers

Jev enters a field that already has three ways to make software decisions, and it replaces none of them wholesale. The honest comparison is by job:

There is no winner in the table. A production system routinely uses all four: rules for the clear cases, a decision model for the fuzzy structured ones, and a generative model where the decision itself needs reasoning a constrained answer cannot carry.

What Jev is not

• Jev is not a text generator. It gives up string generation entirely. If the output you need is prose, code, or an explanation, a generative LLM is the tool.
• Jev is not a gateway or a router. It makes decisions when called. It does not sit on a network path, apply policy, record traffic, or forward requests. Pairing it with a gateway is what turns its answers into routing.
• Jev is not a guarantee of correct judgment. The schema guarantee means it cannot answer outside the declared options; TypeSafe notes its zero-hallucination figure follows from that format guarantee rather than from empirical measurement. Picking the wrong valid option remains possible, which is exactly what the probabilities and the escalation path are for.
• Jev is not independently benchmarked yet. As of mid-September 2026, the performance numbers in circulation are TypeSafe’s own, published with self-disclosed caveats. That is normal for a model a few days into early access, and worth remembering when the numbers get quoted without the caveats.

The bigger shift: separating decision-making from generation

Jev is interesting for a reason that outlasts any one model: it shows AI infrastructure separating decision-making from generation. For the past few years the default architecture has been one shape:

old mental model:
request ──► LLM

emerging model:
request ──► gateway ──► decide what intelligence is needed ──► execute

In the emerging shape, generation is one destination among several rather than the default handler for everything. A cheap, fast, calibrated decision runs first; generation happens when the decision says it should; a human enters when the decision is not confident enough to proceed. Whether the decision layer is Jev, a successor, or a different probabilistic decision model entirely, the architectural move is the same, and it runs at the place that sees every request: the gateway.

Last verified: 2026-09-17. Jev is in early access; primitives, pricing, and reported benchmarks are as published by TypeSafe AI and Vercel on that date.