Jev is TypeSafe AI's decision model: state in, typed answers with calibrated probabilities out, no text generation. The three primitives, the use cases that fit, what the first independent benchmarks and the Laya comparison show, the documented failure modes, and how an FDE should place it in a customer's pipeline.
BY MEI LIN · FDEINTERVIEWS EDITORIAL · UPDATED SEPTEMBER 21, 2026 · 18 MIN READ
PRACTICE THIS:System One decision models, the concept ·LLM and GenAI questions ·RAG and agent design questions ·The must-know FDE questions
Jev is a hosted AI model from TypeSafe AI that makes typed decisions instead of writing text. You send it a state (a support ticket, a customer record, a passage, a JSON object) and one or more typed questions. It returns answers your code can branch on directly: a probability for a yes/no question, a choice from a closed set with the full probability distribution, or a score along rubric levels you define. TypeSafe announced it on 15 September 2026 as the first of what it calls System One models, after two years in stealth, and it is available in early access. There is no generation step, so there is nothing to parse and no way for the model to invent an option you did not offer. For a forward deployed engineer the interesting part is where it sits: inside ordinary software, as a fast, cheap, confidence-bearing judgment, while the workflow, the arithmetic and the side effects stay in code.
What Jev is, and what it is not
The name comes from Daniel Kahneman's System 1, the fast, intuitive mode of thinking, and TypeSafe's docs say the emphasis is on fast, focused judgments. The model is trained with a method the company calls Reinforcement Learning for Calibrated Decisions (RLCD), in contrast to the RLHF that produced chat models and the verifiable-reward training behind reasoning models. TypeSafe's founder, Diogo Almeida, worked on the RLHF research at OpenAI, according to the company's own launch post, and the pitch is that chat-shaped models were the wrong interface for automation.
| Chat and reasoning LLMs | Jev, per TypeSafe's launch post and docs | |
|---|---|---|
| Trained for | Responses people prefer (RLHF), or verifiable answers (RLVR) | Decisions with calibrated probabilities (RLCD) |
| Output | Strings: prose, code, JSON you must parse and validate | Typed values constrained to the options you supplied |
| Sampling | One token at a time | All answers in one parallel pass |
| Confidence | Overconfident and inconsistent when asked | A probability distribution on every answer, and a confidence value on Choice and Score |
| Best at | Human-in-the-loop work, verifiable problems, prototypes | Judgments a knowledgeable person makes in a second, embedded in software |
| Not for | Cheap, high-volume, structured decisions | Generation of any kind, arithmetic, dates, multi-hop reasoning |
Two clarifications matter before the design questions. The TypeScript and Python SDKs are MIT licensed and public on GitHub; the model is served from TypeSafe's API, and we found no public release of weights. And a Jev request is a function call, not a workflow: durable state, retries, transactions and replay belong to your application or a workflow engine.
Three primitives, one request
Every request carries one state and a map of questions. Every question sees the same state, is evaluated independently and in parallel, and comes back under the key you chose.
| Primitive | The question shape | What comes back | Limits (jev-1.13) |
|---|---|---|---|
| Noul | Is this true? "Does the customer request a refund?" | noul, a probability from 0 to 1 | No separate confidence |
| Choice | Which of these? "Which team should handle this?" | choice, probabilitiesover every option, confidence | Up to 255 options |
| Score | Which level? "How frustrated is the customer?" | scorealong your levels, legend, probabilities, confidence | 2 to 10 ordered levels |
The docs are explicit about the granularity: ask for a judgment a knowledgeable person makes in a second given the right context. "Does this message convey urgency?" is a good question. "Analyze this and decide what to do" is not, and is the signal to split the task into small questions and compose them in code. That decomposition costs no extra round trips, because questions over the same state run in parallel.
One ticket, two ways
The clearest way to see the difference is to run the same ticket through both shapes. The ticket reads: "Hey, I was charged twice this month. Can someone fix this?" A generative model routes it by reasoning: it notes the double charge, considers whether that is billing or general support, recalls that billing handles refunds, and writes "Billing." That is several hundred output tokens, a second or more of latency, and a string your code has to parse and trust. A Choice question routes it by scoring. The request carries the ticket as the state and one question with five options and their criteria, and the response is a distribution over those five, a
choice
field naming the top one, and a
confidence
value derived from the shape of the whole distribution.
The numbers in the chart are illustrative, drawn to show the shape of a confident answer rather than recorded from the API. The thresholds are TypeSafe's own worked example from its confidence-routing pattern: below 0.6 the case goes to a person, between 0.6 and 0.85 code acts on low-stakes decisions and asks for confirmation on moderate ones, and above 0.85 it acts on high-stakes ones too. Everything the generative version reasoned about aloud is now either in the criteria you wrote for each option or in the branch your code takes on the confidence. That is the whole trade: you give up the explanation and get back a distribution, a threshold and a millisecond-scale call that costs a fraction of a cent.
| Generative model routes it | Choice routes it | |
|---|---|---|
| What you send | A prompt with the taxonomy and instructions to reason | The ticket as state, five options with one-line criteria |
| What comes back | Prose ending in "Billing", to parse and validate | choice, probabilitiesover five options, confidence |
| What decides | The model's reasoning, which you cannot threshold | Your code, on a confidence you can threshold per action |
| When it is wrong | You find out from the customer | Low confidence routes to a person before anyone is wrong |
| Cost per ticket | Hundreds of output tokens | A few hundred input tokens, output free |
Where it fits: AI inside code, not code inside an agent
TypeSafe describes three architectures. Traditional software is a decision tree of reliable primitives. An agent loop chooses its own next step, which works with a person watching and drifts without one. AI-powered software, the target here, keeps the control flow, the deterministic rules and the side effects in code and inserts the model only where the system needs a semantic judgment over unstructured data. That is the shape of most enterprise automation an FDE actually ships.
The confidence gate is the part that makes this safe to automate. TypeSafe's own banking example uses a 0.6 floor below which everything goes to a person, lets a balance check through at 0.6 because the worst case is reading the wrong screen, and demands above 0.85 before approving a transfer. The thresholds are yours; the rule that they scale with the cost of a wrong action is the design.
Use cases that fit the shape
The strongest uses share one trait: the hard part is a bounded semantic judgment and the consequential action stays in code. These come from TypeSafe's published use-case map and pattern pages.
| Use case | The questions | What stays in code |
|---|---|---|
| Ticket triage | Choice for the queue, Score for frustration, Noul for "refund requested", all in one call | SLAs, routing tables, the write to the ticketing system |
| LLM guardrails and verification | Nouls on every LLM input, output and tool call: injection, policy violation, contradicts the context, sensitive data | The allow-list, the authorization check, the regex for account numbers |
| Model routing | Choice: deterministic handler, fast model, reasoning model, human | The budget, the latency target, the fallback order |
| RAG relevance and reranking | One Noul per passage, fanned out; pairwise Choice for reranking | Retrieval, chunking, the top-k cut |
| Extraction over a bounded space | Choice over enumerated components, with an explicit "not stated" option | Assembling the parts, every comparison and calculation |
| Features for classical ML | Probabilities from many narrow Nouls as feature columns | The model with ground-truth labels |
| Map-reduce over a corpus | The same question battery over every document | The partitioning, the aggregation, the storage |
| Tool and skill selection in an agent | Choice over the closed list of tools; a Noul per argument for "did the user state this?" | The loop itself, the tool registry, argument validation, execution |
| The agent's stopping and escalation checks | Nouls: does the result satisfy the request; is the extracted field wrong; does this step need a stronger model | The acceptance criteria, the retry budget, the fallback model, the human queue |
The last two rows deserve a paragraph, because the popular framing is "let Jev control your agent" and TypeSafe's own guidance is more careful than that. Its build guide says an agent that chooses its own next step "works well when a person is monitoring the process, but every loop introduces another opportunity to go off the rails," and the design it recommends keeps "control flow, deterministic rules, and side effects in code." So the decision model does not run the loop. It answers the loop's questions. The function-calling cookbook routes a request to one of ten trading functions with a single Choice whose options are the functions, fills each argument with a question about meaning rather than parameter name, and reports the call's confidence as the least certain of those judgments, "because one wrong argument is enough to spoil the result." The skill-suggestion cookbook ranks 182 agent skills in two requests and offers at most one, with a floor of 0.30 below which it stays silent, and it reports the cost of that design honestly: wrong loads fell from 16.8 to 7.3 percent and needless loads from 9.8 to 4.0 percent, while seven requests that were already right got worse, since "a confident wrong suggestion is more persuasive than no suggestion at all." And the extraction cascade cookbook is the "does this need a smarter model" pattern made concrete: a cheap model extracts, one Noul per field asks whether the value is wrong, and any field above 0.7 sends the whole item to a reasoning model. Same shape every time: code owns the loop, the model answers narrow questions inside it, and the threshold decides who acts.
Some arithmetic, using list prices only. A triage pipeline that sends a 300-token state for each of one million tickets a month uses 300 million input tokens. At the listed 0.042 dollars per million that is about 12.60 dollars, with output free. The launch post puts frontier LLM input at 0.20 to 10 dollars per million tokens before output, so the same volume runs from about 60 dollars to about 3,000 dollars on input alone. That is why the use-case map talks about classifying every agent trace and scanning giant corpora: jobs that were too expensive to run become routine at this price, if the judgment is the System One kind.
The numbers, as of 20 September 2026
| jev-1.13.0, from TypeSafe's models page | |
|---|---|
| Price | 0.042 dollars per million input tokens; output tokens free |
| Context | 64k tokens per request; 32k for the state plus the longest question |
| Rate limits | 250,000 tokens per second and 1,200 requests per minute, adjusting dynamically |
| Latency | Most queries about 100 ms, per the docs; independent runs over the public internet measured 236 to 276 ms and 422 ms at p50 |
| Input | Text only: a string, a JSON object, or an array of text. English best; other languages accepted with lower accuracy |
| Aliases | jev-latestand jev-previewboth resolve to jev-1.13.0today; aliases move when a release ships |
| Data | Requests are not used for training; zero data retention is offered to enterprise customers |
Verify against the docs before you quote any of these to a customer. Early-access numbers move.
What the first benchmarks say, and how to read the chart going around
Five days is enough for a benchmark ecosystem to appear, and it already tells two stories. The first is the one in a chart that has been circulating: Laya, a 421M-parameter open-weights model released by ConvAI Innovations four days after Jev under Apache 2.0, "beats" Jev 83.8 percent to 67.8 percent overall. Read the axes before you repeat it. Laya's 83.8 is its own evaluation over 23,024 questions in eleven task families, run by its authors on a fine-tuned checkpoint. Jev's 67.8 is a different number entirely: TypeSafe's own workflow evals, where 67.8 percent is Jev's average agreement with an ensemble of two frontier LLMs across four business workflows, at 0.0004 dollars and 0.4 seconds per case, against 73.1 percent for Opus 5 at 0.1761 dollars and 37.8 seconds. The two numbers share nothing but a percent sign, which is the point a Hugging Face dataset card makes before re-running both models itself.
The second story is what happens under one frozen protocol. An independent zero-shot benchmark gave Jev, Laya and an open NLI classifier the same text, the same instruction and the same label names on four public datasets, with the protocol frozen before inference.
Independent zero-shot accuracy under one frozen protocol (elcronos, 20 September 2026). Jev leads the two topic datasets by 16 to 33 points and ties Laya exactly on emotion. On dialogue emotion every zero-shot system sits below the 0.82 majority-class baseline. The outlined bars are a logistic-regression or LightGBM model trained on each dataset's own labels: with labels, a plain supervised model beat every zero-shot system on every dataset.
Three findings from that repository matter more than the ranking. Task type beat model family: the same Jev prompt shape scored 0.587 on emotion and 0.793 on tweet topics, and its calibration error ranged from 0.063 to 0.281 across the four sets, so nothing in the API tells you which you will get on your data. The break-even against a trained model was a few hundred to a few thousand labels: 500 labeled tweets were enough for logistic regression on sentence embeddings to match Jev, 1,000 on finance topics, about 5,000 on emotion. And Laya's advertised win did not reproduce zero-shot; the same card that shows the 83.8 also states that the base model scores near random on its typed-decisions benchmark until fine-tuned on that benchmark's training split.
A third source is narrower and, for an FDE, the most reassuring. A reproducible benchmark of Jev on classifying agent tool calls as read-only, destructive, privileged or exfiltration, on 60 hand-labeled cases including 12 adversarial ones wrapped in benign language, found 91.7 percent accuracy, 11 of 12 adversarial cases caught, 71.4 percent on the deliberately ambiguous slice, and a calibration result that held across repeated runs: every wrong answer came with hedged confidence, and the model was never wrong at a confidence of 1.000. Latency measured client-side over a residential connection was 422 ms at p50 and 542 ms at p95, which is far above the docs' "about 100 ms" and is the number to plan around until you have measured your own.
| Source | What it measured | Headline | Read it as |
|---|---|---|---|
| TypeSafe workflow evals | Agreement with a two-LLM reference on four vendor-built workflows | Jev 67.8% at 0.0004 dollars and 0.4 s; Opus 5 73.1% at 0.1761 dollars and 37.8 s | Vendor-run; the cost and speed gap is the claim, not the accuracy |
| Laya model card | Its own 23,024-question suite, fine-tuned checkpoint | 83.8% overall; 32.8 to 39.5 ms per question on a T4 | Self-reported; not comparable to the 67.8 it is placed beside |
| elcronos, frozen protocol | Zero-shot accuracy and ECE on four public datasets | Jev 0.79 / 0.67 / 0.71 vs Laya 0.63 / 0.34 / 0.61; tie at 0.59 on emotion | Independent; task type dominates; labels beat zero-shot |
| themsquared tool-call risk | 60 labeled agent tool calls, accuracy, latency, calibration | 91.7%, ECE 0.07, zero misses at confidence 1.0, p50 422 ms | Independent, small n, raw results committed; the calibration claim held |
| Luni dataset card | Phishing and typed-decisions, both models re-run | Phishing: Jev 0.626 raw, Laya 0.505 raw and 0.611 after Platt scaling, Claude Haiku 4.5 0.813 | Independent; also shows question-plus-negation sums of 0.09 and 1.73 from Laya |
The chart's one genuinely useful panel is the selective-automation curve, accuracy on automated decisions against the share of traffic automated. Laya reports 92.2 percent at 50 percent coverage against 83.8 percent at full coverage. Whatever the numbers, that curve is the shape to demand from any decision model, because it is the confidence gate drawn as a picture: you choose the coverage, the vendor cannot choose it for you, and the labeled set that draws the curve is the same set that sets your thresholds.
Where it breaks, in TypeSafe's own words
The docs keep a page of jagged edges for jev-1.13, last reviewed 17 September 2026. The line an FDE should underline is that the model "answers the question you wrote, not the one you meant". Scoping words, negations and implied conditions are read literally.
| Failure mode | What TypeSafe says to do instead |
|---|---|
| Literal reading | Write the exact condition; put boundary cases in the criteria |
| Arithmetic and counting | Keep the math in code; iterate and ask one Noul per item, then add in code |
| Date and time comparison | Extract components as a Choice; assemble and compare dates in code |
| Indirection and multi-hop reasoning | Reduce hops; point the question at the relevant part of the state |
| Large state with irrelevant detail | Filter first; the docs call the accuracy loss context rot |
| Adversarial content | State is not treated as hostile; be explicit in criteria and test edge cases |
| Structural invariants | A question and its negation do not sum to one; do not carry thresholds across primitive types |
| Generation | Use a generative model |
The invariants row deserves its own example, because it surprises people who reason about the outputs as probabilities in the textbook sense. In TypeSafe's worked case, "is the customer asking for a refund" returned 0.72 and "is the customer asking for something other than a refund" returned 0.47 on the same ticket, a sum of 1.19. Ask each decision one way and enforce identities in code.
How a forward deployed engineer should think about it
Design it like a smart if-statement, because that is what it is. Decompose the judgment into atomic questions, keep every calculation, date comparison, authorization decision and irreversible side effect in code, and combine the answers with explicit weights or rules your customer can read. When priorities shift, you change a weight rather than rewrite a prompt.
Calibration is a population property, so you still need a golden set. A calibrated 0.8 means that outcomes at 0.8 come true about 80 percent of the time across many predictions. It does not make any single answer right. The independent runs above make the case concrete: one prompt shape produced accuracies from 0.59 to 0.79 and calibration errors from 0.06 to 0.28 depending on the dataset. Build a labeled set from the customer's own data, plot confidence against accuracy, choose thresholds per action, and rerun the sweep when the model version changes. And run the comparison the benchmark authors ran: a linear model trained on the same few hundred labels, scored on held-out rows, because it may be the better deal once the labels exist. Pin
jev-1.13.0
rather than the alias, and log the
model
field the response returns with every decision.
It is five days old, so wrap it the way you wrap any external dependency. Rate limits are dynamic, the SDK is at version 0.6.0, and the docs do not publish an SLA. Put the call behind a timeout and a fallback, record the decision in an outbox before you act on it, and design the retry so a duplicate call cannot cause a duplicate action. The site's concepts on fallbacks and provider failover and on idempotency are the reference for both.
Treat the state as untrusted input. The model does not defend itself against text written to steer it, so a Noul asking "is this a prompt injection" is one layer, not the layer. Keep the deterministic checks that already exist, and for regulated customers get the zero-data-retention terms in the contract rather than assuming them.
Look for the steps in an engagement that are already burning LLM tokens on snap judgments. Triage, routing, verification, relevance filtering, trace classification. Those are the first candidates, and they are also the ones where a wrong answer is cheap to catch with a threshold and a human queue.
Set it up in a coding agent in five minutes
The fastest way to try the shape is inside the coding agent you already use, because TypeSafe publishes an agent skill that carries the API's three question types, its patterns and its evaluation advice into the agent's context. Everything below is from the docs and the skill repository as of 21 September 2026; check both before relying on it, because early-access products move.
- Get a key. Create one in the TypeSafe console and export it as
TYPESAFE_API_KEY
. That is the variable name the SDKs and the quickstart's curl example read. - Install the skill. In a project,
npx skills add typesafe-ai/skills --skill typesafe-ai
, and pick your agent when asked; add-g
to install it for every project. The docs name Claude Code, Codex and Cursor. Claude Code also has a plugin route:claude plugin marketplace add typesafe-ai/skills
thenclaude plugin install typesafe@typesafe-ai
. - Install an SDK for the code the agent writes. Python is
pip install typesafe-sdk
; the TypeScript package is@typesafe-ai/sdk
. Both are MIT licensed. - Point the agent at a real step. Ask it to find one place in the codebase where a prompt-and-parse call or a brittle rule set is really a closed-set decision, and to rebuild that step as typed questions with a confidence gate. The skill's own rule of thumb is to reach for the model "when an LLM prompt-and-parse step could become a structured decision," and to "ask one narrow, coherent judgment per question."
Two cautions. The skill is guidance for the agent, not a policy for your repository, so if you want the agent to prefer typed decisions by default, say so in your own project instructions in your own words rather than copying a template from a social post. And an installed skill does not make the round trip cheaper to get wrong: the labeled set, the threshold sweep and the pinned model version from the section above still apply to every step the agent rebuilds.
What this means for FDE and Applied AI interviews
Expect the design rounds to add a third option to "rules or a model": rules, a generative model, or a decision model. The answer they want has four parts: name the shape of the judgment (a snap judgment or a chain of reasoning), say what stays in code, tie the confidence threshold to the cost of a wrong action, and describe how you would evaluate it on the customer's data before and after a version change. We have added a concept page on System One decision models and two practice questions, one on replacing an LLM classifier with a decision model and one on building a guardrail layer with it. The wider preparation is the same as before: the LLM and GenAI questions, the RAG and agent design questions, and the skills guide for the role.
Turn it into offers. Work the real questions and concepts this maps to:
FAQ
Jev is a hosted AI model from TypeSafe AI, announced on 15 September 2026, that returns typed decisions instead of generated text. You send it a state (a ticket, a record, a passage) and typed questions, and it returns a probability for a yes/no question, a choice from a closed set with the full probability distribution, or a score along rubric levels you define. TypeSafe calls this class of model a System One model.
No, in the sense that matters for design. Jev understands natural-language input like an LLM, but it does not generate text, code or explanations. Its outputs are constrained to the options you supply and come with calibrated probabilities. TypeSafe trains it with a method it calls Reinforcement Learning for Calibrated Decisions rather than the RLHF used for chat models.
As of 20 September 2026, TypeSafe lists jev-1.13.0 at 0.042 dollars per million input tokens, with output tokens free. The request budget is 64k tokens, with 32k for the state plus the longest question. Rate limits are listed as 250,000 tokens per second and 1,200 requests per minute, and TypeSafe warns they are adjusting dynamically during early access.
They are Jev's three question types. Noul is a yes/no judgment returned as a probability from 0 to 1. Choice picks one option from a closed set of up to 255 and returns the whole probability distribution plus a confidence value. Score rates the state against 2 to 10 ordered rubric levels and returns a probability-weighted position plus confidence. All questions in one request see the same state and are evaluated independently, in parallel.
The client SDKs for TypeScript and Python are MIT licensed. The model itself is served from TypeSafe's hosted API, and we found no public release of its weights. Treat it as an external inference service, with the same fallback and data-handling questions you would ask of any hosted model.
Not on the evidence so far. The chart showing Laya at 83.8 percent against Jev at 67.8 percent compares two different benchmarks: Laya's own suite on a fine-tuned checkpoint, and TypeSafe's workflow-eval agreement with an LLM ensemble. Under one frozen zero-shot protocol on four public datasets, Jev led Laya by 10 to 33 points on three and tied on the fourth, and Laya's own card says its base model scores near random on its typed-decisions set until fine-tuned. Laya is open weights, Apache 2.0, and roughly ten times faster on a local GPU, which makes it a strong base to fine-tune when you have labels and cannot send data out. It is not a zero-shot replacement.
It can answer those questions; it should not run the loop. TypeSafe's own build guide keeps control flow, rules and side effects in code and warns that an agent choosing its own next step goes off the rails without a person watching. Its cookbooks show the working shape: a Choice over the closed list of tools with a question per argument, a Noul per extracted field asking whether it is wrong with escalation to a reasoning model above a threshold, and a two-stage skill ranker that stays silent below a floor. Code owns the loop; the model answers narrow questions inside it.
Install TypeSafe's published agent skill with npx skills add typesafe-ai/skills --skill typesafe-ai (add -g for every project), or in Claude Code add the typesafe-ai/skills marketplace and install the typesafe plugin. Export TYPESAFE_API_KEY from a key created in the TypeSafe console, install the Python or TypeScript SDK, and ask the agent to rebuild one prompt-and-parse step as typed questions with a confidence gate. The skill carries the three question types, the patterns and the evaluation advice into the agent's context.
Not on the critical path without a fallback. It launched in early access five days before this article, rate limits are dynamic, and TypeSafe's own docs list nine failure modes for jev-1.13. It fits well as a confidence-gated judgment inside a workflow that code controls, evaluated on the customer's own labeled data, with the model version pinned and a path to a human or an LLM when confidence is low.
Discussion (5)
The cleanest way I have found to explain this to a customer's platform team: it is the return of the classifier, but you do not train it. A fine-tuned BERT gave you a label and a softmax you could not trust past the training distribution. Here you write the options and the criteria in the request, get a calibrated distribution back, and change the taxonomy by editing a map instead of retraining.
And the thing that makes it more than a classifier is the fan-out. Twelve independent questions against one state in one call, then your code composes them. That is a decision tree with a model at the leaves, which is the shape most enterprise automation actually needs.
Reader question: how is the confidence value different from just reading the top probability off the Choice? If billing is 0.88, is that not the confidence?
Close but not the same. Confidence is a statistic TypeSafe derives from the shape of the whole distribution, so a 0.88 with the rest spread thinly across ten options reads differently from 0.88 against a single 0.12 rival. Noul answers carry no confidence at all, only the probability. The practical rule from their docs: do not carry a threshold tuned on a Noul over to a Choice, and do not expect a question and its negation to sum to one.
The line in their failure-mode page that I would underline for any FDE is that state is data and the model does not treat it as hostile by default. A ticket written to argue for its own classification can move the answer. So the guardrail layer still has to be layered, and the allow-list, the authorization check and the PII regex stay in code where they always belonged.