Jev in production: guardrails, routing and classification

A support inbox receives a message that says "cancel my order and tell me why the charge was double". A language model can write a reply to it in a few seconds. Before that reply is worth writing, the application has to make several small decisions: which team owns this, whether it involves money, whether the person is angry enough that a human should read it first, and whether the message is trying to make the assistant ignore its instructions. Each of those is a question with a fixed set of answers. A single word answers each one.

That is the gap a decision model fills. Jev, released by TypeSafe AI on 15 September 2026 as the first public System One model, takes a state (a string, a JSON object or an array of text) and a map of named questions, and returns a typed answer with a probability for each one [1]. It never writes text. TypeSafe reports 70 to 500 milliseconds end to end and prices it at $0.042 per million input tokens with output free [2][3]. Those are the vendor's figures, and this guide marks them as such throughout.

This page is the map. It explains where a decision model fits in an application, which product moments are decisions and which are generation, the four patterns TypeSafe names and how we use them, the three places a decision model is worth using in the safety layer, and what running one in production asks of your operations. Each section links to the page that goes deeper. If you want the definitions first, Jev and System One models covers the three question types and how confidence is computed, and this guide assumes you have read it or will.

What a decision model does inside an application

Three question types cover everything Jev can answer. A Choice question picks one option from a list of up to 255 and returns the choice, a probability per option and a confidence number [4]. A Score question places the state on an ordered scale of 2 to 10 levels described in words, and returns the expected level as a number that can be between levels. A Noul question is a yes or no statement and returns one probability from 0 to 1, with no separate confidence number [1]. Every question in a request is answered in parallel and in isolation, and TypeSafe's introduction says "Adding questions barely changes the response time" [5].

The practical consequence is that a decision model behaves like a function your code calls, with a number coming back that your code can compare against a threshold. There is no prompt to parse, no JSON to repair, no retry because the model wrote prose instead of a value. TypeSafe describes this as an answer that always matches the schema (the exact answer format you asked for), and calls it "can't hallucinate" in its own material. Read that carefully: it means zero structured-output errors, and the answer can still be wrong [6]. We treat it as a typed function that is sometimes mistaken, which is exactly how we treat every other classifier.

TypeSafe's own coding-agents page is clear about what Jev is not for. It "is not a drop-in replacement" for the language model that runs a coding agent, meaning you cannot swap it in where a model writes code or text; it is used inside the application for routing, rubric scoring and statement verification [7]. Our AI agents in production guide covers the agent itself. This guide covers the decision points inside it.

The one rule: code owns the flow

TypeSafe's design guide opens with the sentence we would give any team adopting a decision model: "Keep control flow, deterministic rules, and side effects in code" [8]. The model answers a narrow question. Code decides what to do with the answer, applies the rules that have a fixed right answer, and performs the action. The model never calls a tool, never loops, never decides what to ask next.

That rule puts Jev in a middle position between two designs teams already know. Hard-coded rules are fast, cheap and fully predictable, and they cannot read a sentence. An agent loop can read anything, and every extra turn of the loop, in TypeSafe's words, is another chance for the run to go wrong [8]. A decision model gives you the reading without the loop: one request, one set of answers, and code in charge of everything before and after. Where a decision model fits in an application lays this out with the three anti-patterns TypeSafe names (broad questions, hidden context and agent loops) and a worked example.

The same guide says to break a broad judgment into atomic questions asked in parallel, then combine them in code with weights you control [8]. "Is this spam?" becomes three questions: does it ask for credentials, does the sender name mismatch the address, does it promise a reward. Each answer can be inspected, tuned and logged on its own, and the combination rule is a line of arithmetic you can read in a code review.

Which product moments are decisions

The fastest way to find where a decision model belongs is to go through the product and label each moment as a decision or a generation. A decision has a fixed set of possible answers. A generation produces new text, code or an image. Jev only does the first.

Four kinds of decision come up in nearly every product. Route: which handler, team, model or workflow should take this. Gate: should this action happen now, wait for confirmation, or go to a person. Score: how urgent, how risky, how complete, how satisfied. Verify: is this statement true of this document, does this extracted value match the source, did this reply follow the instruction. Every one of those maps to a Choice, a Score or a Noul question, and every one of them used to be done with a language-model prompt that asked for JSON and hoped.

Generation stays with a language model: the reply to the customer, the summary of the ticket, the code change, the draft email. A common shape is a language model doing the generation and Jev making the decisions around it, before the generation (routing, screening the input) and after it (screening the output, checking it against the source). TypeSafe's guardrail cookbook is exactly that shape, and Guardrails for an LLM app with one Jev request explains it step by step.

The four patterns

TypeSafe's patterns page names four ways to use a decision model, and each is a page in this guide or a section of one [9].

Intent routing classifies a request and sends it to the right handler: deterministic code, a specialist model or a human. A Choice question over the handlers does the work, and confidence decides whether to trust the answer. TypeSafe's skill-suggestion cookbook is a large example: it picks one skill out of 182 in two stages, a wide ranking over all of them and a re-check over the top three, and in TypeSafe's own test on 488 requests wrong loads fell from 16.8 percent to 7.3 percent [10]. Intent routing with Jev covers the option limit, the two-stage approach for large lists, and the "none of these" case.

Confidence-gated routing uses confidence as a second decision axis. TypeSafe's confidence page gives the bands: at 0.9 and above "Act automatically", below 0.5 route to a human, ask for clarification, or use a different system instead, and in between proceed with caution [11]. The same page says different actions in one system should be gated at different levels depending on the consequences. Confidence-gated routing: act, confirm, or escalate turns that into a table of gates and shows the pattern of escalating to a reasoning model only in the uncertain band, which TypeSafe's extraction cascade cookbook does with a cheap model, a Jev verification step and an expensive model in that order [12].

Composite scoring breaks a complex judgment into atomic scores and combines them with weights in code. TypeSafe's example scores a candidate on four dimensions from 0 to 4, normalises each to 0 to 1, and applies a different weight set for a senior engineer and for an engineering manager [13]. The advantage is that the final number has a formula you can read.

Speculative fan-out sends every question you might need in one call, including questions that may turn out to be irrelevant, and lets code discard the answers it does not use [14]. Because questions run in parallel, the extra questions cost tokens and almost no time. TypeSafe's batching cookbook measured 13 questions against the 53,777-character Wikipedia GDPR article: one batched call cost $0.000497 and took 0.27 seconds, against $0.006090 and 2.71 seconds for thirteen single calls, which TypeSafe reports as 12.2 times cheaper and 10.0 times faster, with the answers unchanged by what else was in the request [15].

A fifth use, extraction, is where teams most often misunderstand what a decision model can do. Jev cannot write out a value it found in a document. It can pick one from a list your code built. TypeSafe's pre-parsed extraction cookbook finds every email, phone number and money amount with regular expressions (text patterns), then asks a Choice question to pick the right one or "none" [16]. Extraction and verification with Jev covers that, the date cookbook that reads date parts as choices and does the arithmetic in code, citation checking against a source, and entity matching over 450 catalogue pairs.

Where a decision model belongs in the safety layer

Three of the pages in this guide are about safety, because that is where a fast, cheap, typed answer changes what is affordable.

The first is screening a language-model application. TypeSafe's guardrail cookbook asks one request per message with named questions (jailbreak, harmful_request, medical_advice, self_harm) and a severity score from 0 to 3, then routes on thresholds: 0.35 for review and 0.70 or 0.85 for action depending on how strict the policy is, with precedence support, block, review, pass [17]. The point of the design is that the screen costs one Jev request rather than a second language-model call, so it can run on every message in both directions. Openlayer's jevals library packages the same idea as a security namespace with PromptInjection, Jailbreak, PII, PHI and SecretsExposure among its checks, and reports a p50 of 244 milliseconds and a p95 of 371 milliseconds per request on its own benchmark [18]. A p50 is the time half of requests beat; a p95 is the time 95 percent beat.

The second is gating an agent's tool calls before they run. LangChain's harness post describes a middleware, code that sits between the agent and the tool, which uses Jev to classify a tool call's risk and block it before execution [19]. jevals has ToolCallRisk and ExcessiveAgency checks with approve, escalate and block outcomes [18]. Our version is a Noul question per side effect (a delete, a payment, an external send), each with its own threshold and a human confirmation step in the uncertain band. Gating agent tool calls before they run has the thresholds, and it uses Browser-use's Jev Ultrafast as the example of a decision model choosing actions: in six alternating runs of one Google Flights task, median time fell from 9.45 to 7.09 seconds and browser protocol calls from 1,092 to 101, with Browser-use's own caveat that this is one task and no general benchmark [20]. Our permissions and guardrails for AI agents page covers the permission model itself.

The third is the limit. TypeSafe's page on the model's known weaknesses says adversarial content in the state "can move the answer" [21]. A decision model is a screen, and a screen can be fooled, so it is never the only defence. Prompt injection and adversarial input explains how to separate untrusted text from instructions inside the state, keep questions narrow, add code checks such as allowlists and schemas, test with known attack strings and keep an audit log.

What running it in production asks of you

A decision model on the request path is a dependency with a rate limit, a version and a failure mode, and each of those needs an answer before launch.

TypeSafe publishes the limits: 1,200 requests per minute and 250,000 tokens per second, 64k tokens of context per request with 32k for the state plus the longest question [3]. The API (the web service your code calls) returns 429 when you exceed the limit and 529 when TypeSafe is overloaded, and the docs say to retry with exponential backoff, meaning a wait that doubles after each failure [22]. The Python SDK, TypeSafe's client library, has a default policy of two retries after the first attempt, starting at 0.5 seconds and capped at 5 seconds with 25 percent jitter, inside a 30-second budget [23]. Rate limits, retries and latency in production covers timeouts, the safe default action when Jev is unreachable, and batching to cut the request count.

Versions move. The current model is jev-1.13.0, and both aliases, jev-latest and jev-preview, point to it today. TypeSafe's models page says "An alias moves when a new release ships, so the answers behind it can change without a change on your side", and the response carries a model field with the versioned ID that answered [3]. Pin a version in production, keep a labelled set, and re-run it on every version change. Versions, drift and monitoring a decision model explains what to watch and what to alert on, including the probability distribution over time and the fact that English is the primary training language.

What it costs, in the vendor's numbers

TypeSafe's public price is $0.042 per million input tokens, or $42 per billion, and output tokens are free [3]. A route over a 500-token message therefore costs $0.000021 at the list price, and a guardrail screen of a 2,000-token conversation costs $0.000084. Those are arithmetic on the public price, so they are exact for the price and say nothing about volume discounts or future changes.

TypeSafe's headline benchmark reports Jev finishing a workflow decision in 0.114 seconds for $0.000081 against GPT-5.6 Terra at 8.566 seconds for $0.013880, which TypeSafe calls "193.6x faster and 444.6x cheaper" [6]. TypeSafe's own capabilities team wrote the workflows, and TypeSafe says it cannot prove the price is unsubsidised. Read it as the vendor's claim about the vendor's tasks. LangChain's independent test of Jev as an agent evaluator, five weather-agent cases with 100 repetitions each, measured 0.44 seconds per call at $0.00035 against 2.16 to 2.83 seconds for the language models it compared, with a full run costing $0.34 on Jev and $28.17 on Claude Sonnet 4.6 [24]. The authors call their result "promising, but early", and five cases is a small set.

Where Reveneau fits

Reveneau builds AI agents and product features, and we write all of our code with AI. Every change has to pass a large eval suite, written from the specification, before it is released, and we take responsibility for the whole project through production and after release. Jev sits in two places in that work.

Inside the products and agents we build, it takes the decision points: which handler a request goes to, whether an action runs or waits for a person, whether an extracted value matches the source, and whether a message going into or out of a language model needs review. Everything with a deterministic answer stays in code, and everything that generates text stays with a language model. This guide is the set of patterns we use.

Inside our own delivery, Jev grades the eval suite. Checks with a deterministic answer (a test passes, a schema validates, a migration holds) never go to Jev. The checks that used to need a language model as judge, such as whether a change matches a written acceptance criterion or whether an agent's trace followed the plan, are now a Noul or a Score question with the rubric written into the criteria. On our own suite, measured against our previous grader, the suite runs ten times faster. Evals with Jev explains how the grader is set up, and eval-driven development is the practice it belongs to.

We publish no client claims here and no defect rates, because we have not run the controlled experiment that would justify one. If you are building an agent and want the decision points designed this way, our AI development work is where we do it, and decision models for product teams is the version of this guide written for the person approving the build. If you would rather talk it through, contact us.

Sources

The numbered references below are the pages every figure on this page was read from, on 2026-09-22. Vendor figures are TypeSafe's, third-party figures belong to Openlayer, LangChain and Browser-use, and the one Reveneau figure is our own statement about our own suite.