Jev: TypeSafe's System One model explained

Jev is TypeSafe's System One model. It answers typed questions with probabilities and writes no text at all. What it does, costs, and cannot do.

TypeSafe launched Jev on 2026-09-15, into what its post calls public early access, and the thing that makes it hard to file is that it emits no text at all. You hand it some state and a list of typed questions, and it hands back one typed answer per question with the probability distribution that produced it.

TypeSafe call this a System One model: fast intuitive judgment, as against the System Two deliberation a language model performs by writing its way to an answer. The framing is marketing. The constraint under it is real, and that is the interesting part. Every Jev figure below is vendor-published, and where TypeSafe's own surfaces disagree with each other, we say so.

The three questions it can answer

The whole API is one shape: here is some state, here are N questions, give me N answers. The state is your material, an email, a ticket, a record. There are three question types.

The ids you give your questions are for your code only: "Question IDs are for your code. They are not sent to the model." All the meaning lives in the question text and the criteria.

A choice, in plain English

Which queue does this support email belong in? You supply the options as names with descriptions: billing, bug report, account access, sales, none of these. Back comes one of them, a probability against every option, and a confidence.

Names and descriptions both reach the model, so the docs tell you to "write descriptions that separate the options from each other". A choice cannot express an answer outside its own set, so include the other or none of the above the same page asks for, or everything unfamiliar lands in whichever option is closest, silently.

A score, in plain English

How urgent is this, from "no rush" to "this week" to "today" to "now"? Back comes a probability-weighted mean plus the spread across the rungs, landing between rungs rather than on one. TypeSafe's example returns 1.30.

A noul, in plain English

Does this message ask for a refund? Back comes one number, say 0.93, and nothing else. No confidence field, because the probability already is the certainty. When you want intensity rather than a yes or no, the docs say to use a score instead of bending a noul into a spectrum.

Confidence that is measured, not claimed

Ask a language model how sure it is and you get a sentence, generated the way every other sentence is: a claim about certainty written by a system good at writing plausible claims. Jev's confidence is arithmetic over an object it had to produce anyway. The API reference: choice and score answers "carry a confidence between 0 to 1, derived from the answer's probability distribution". The confidence page adds the intuition, that "concentrated on one outcome means a confident answer, spread out means an uncertain one". That is calibrated confidence in the weak but useful sense: a number computed from the answer rather than asserted beside it.

TypeSafe describe three bands in prose. High: act automatically. Medium: proceed with caution. Low: do not act, route to a human, ask for clarification, or fall back to another system. Numbers appear only inside one worked example, where the branch above 0.9 is a high-stakes action that still confirms with the user, so nothing there authorises unattended action at a given number. The governing sentence is about stakes: "Different actions within the same system should be gated at different levels depending on the consequences of getting it wrong." The right values, they add, depend on your domain and your use case, so any ladder you read online, this page included, is somebody else's homework. Confidence threshold is how to pick your own.

The trap: a noul near 0.5

A noul returns the probability that a statement is true. A 0.5 is not "medium" or "half urgent". It means yes and no are equally likely, which is the model saying it does not know. Read it as an intensity and you have built something that acts most confidently where it has least information. TypeSafe's pages do not address this case, so the reading is ours.

What it costs, and why that is the actual news

The launch post prices Jev at $0.042 per million input tokens. Output tokens are reported in the response envelope but not billed, the vendor's phrasing being that they are too cheap to meter. Note where that number lives: the launch post, not the docs, which carry no pricing page. The only rate in the documentation is a cookbook table pinned to "TypeSafe jev-1.12 as of 2026-09", so this is a dated per-version rate, and TypeSafe say it may be subsidised.

Against the general-purpose models at live WorkerKit list prices, for those same 10,000 items with about 30 tokens of answer each:

Many questions also ride one request, evaluated independently: N single-question calls pay to read the document N times, the batched call pays once. TypeSafe's cookbook benchmark puts 13 questions against one article of about 54,000 characters, five times under each strategy, and reports the batched run 12.2x cheaper and 10.0x faster without changing the answers. Another of their pages gives 11.5x and 9.6x for what reads as the same test. One document, one model, one set of runs, and two published numbers, so take the direction and not the decimal.

So Jev's input rate is a little under 5x cheaper than a general-purpose model such as GPT-5.6 Luna at $0.20 in and $1.20 out, and the output half does not bill. That discount is not the news: five times cheaper than something already costing $1.36 is a line item. The news is the third row of the first table. A million judgments for about $21 means whole categories of backlog stop being a budget conversation, starting with every list nobody triages because triaging costs more than ignoring it. So the question is not whether this beats a small model by 5x, but which work it moves from "not worth it" to "obviously worth it", which is screen cheap, spend expensive. Left out of the arithmetic: a request budget the primitives page gives as roughly 32,000 tokens, or "roughly 150,000 characters of English text", and the work after the decision, which is where the money usually goes.

What it cannot do

This is the half that matters most, and it is the shape of the thing rather than a list of missing features.

• It cannot write. The concepts page: "System One models do not write replies, produce code, or generate explanations of their reasoning." No reply, no summary, no subject line, no account of why it picked what it did.
• It cannot call a tool or take a step. TypeSafe's framing is that these are not agents: the model "does not generate code or choose its own next action", and your "code remains in control". It answers what you asked and stops. There is no loop to watch and no turn after this one.
• It cannot answer outside your schema. The anti-hallucination story is structural: the model "returns a full probability distribution over those options rather than inventing a value outside the schema". So a typed answer guarantees the interface, not the truth. The pick is always well formed and not always right.
• It cannot fill in a free-text argument. TypeSafe's function-calling cookbook simulates tool use by asking "which function next?" as a choice, and is honest about the ceiling: only arguments with a closed set of values can become a question. Free text, numbers and dates get none, so the default stands. Something that picks the next function but cannot write its arguments can sort your work and cannot do it.

When it is the wrong tool even though it fits

Everything above is what a decision model cannot express. This is the other half, and the more expensive mistake: work you can phrase perfectly well as a typed question and should still send somewhere else.

The pattern: a decision model earns its place where the input is genuinely ambiguous and the output is genuinely a short list. Where the rule is writable, write the rule. Code is cheaper than $0.042 per million tokens, it is exact, and you can test it.

So where does it sit next to an AI worker

They are not alternatives, and the reason is mechanical rather than a matter of taste. A worker run is a loop: a model reads, calls a tool, reads the result, decides again, writes into a real account and leaves a receipt. A model with no tools, no turns and no prose cannot be that loop's model. It is something a program calls and waits on, not something that runs.

The docs make the same point from their side, against loops nobody is watching: "every loop introduces another opportunity to go off the rails". Fair, and it cuts both ways, because the jobs people want done end in a draft, a ticket or a message, and none of those is a typed pick. The longer argument is decision models vs agents, on the older distinction in AI agent vs AI worker.

**So this is a different shape of worker, and that is the shape WorkerKit runs for it.** A decision worker has no loop: it fetches items, judges each one with typed questions, routes on the answer in code, and acts. It reaches your apps through the same firewall door an agent worker uses, so a judgment only ever sees what that worker was already allowed to read, already redacted.

What you can do about this today on WorkerKit

The useful takeaway is not a vendor. It is the split: judging is cheap work, writing is expensive work, and paying one rate for both is a default rather than a decision. That split is already a live control here, in two places.

Pick the model per job. Every kit page grades itself per model, so you can see which ones hold the job before committing (model grade explains how to read one). You pick the model when you deploy, switch it whenever, and send a single run to another model to compare, at provider list price with no markup. A support inbox triager sorting a queue and an inbound lead qualifier drafting a first reply do not want the same model, even on the same message.

Or pick the worker class. Where the whole job is judging rather than writing, a decision worker is the other shape, its meter is the item judged rather than the token, and under its required confidence floor it escalates to a person instead of acting. How to pick a model per job is the method, and the other bill is tool calls, capped per plan rather than metered by token. Pricing has both halves.

The questions to ask before you send anyone's data through it

Not an accusation. It is a young launch, and this is what was unpublished as of 2026-09-16.

• Early access, and the two surfaces disagree about how open. The launch post describes a waitlist; the quickstart just says to get your API key from the dashboard. Price, latency and the subsidy note are on the marketing site, the model and the limits in the docs.
• No published rate limits, quota, concurrency ceiling or uptime commitment. The API reference covers 429 and 529 in retry terms only, advising "exponential backoff instead of retrying immediately".
• No published DPA, retention policy or training-use policy. We are not saying what TypeSafe do or do not do with submitted data, only that they had not published it, and "we will send the support inbox through it" needs the document, not an assumption. What a decision worker sends is bounded on our side by that worker's own app grants and redaction, so nothing reaches the model the worker was not already allowed to read.
• `jev-latest` is a moving pin. The cookbook's cost table names a dated version, jev-1.12, so versions exist behind the alias. Calling the alias means behaviour can change under you with no deploy on your side, after you tuned thresholds against the old behaviour.
• No confidence number fixes a legal exposure. Sorting and surfacing for a human reviewer is fine. Deciding about people unattended, hiring, firing, credit, benefits, discipline, attracts employment law and the EU AI Act however calibrated the distribution is.

For the concept without the vendor, see system one model; for the mechanism that makes it usable in code, structured output.

FAQ

What is Jev?

Jev is a model from TypeSafe, in public early access since 2026-09-15, that answers typed questions instead of writing text. You send it some state and questions of three types, choice, score or noul, and get one typed answer each, with the probability distribution behind it.

Can Jev write text?

No, by construction. TypeSafe's concepts page: System One models "do not write replies, produce code, or generate explanations of their reasoning", and no answer shape carries a free-text field. Work that produces prose needs a model that writes.

How much does Jev cost?

TypeSafe's launch post lists $0.042 per million input tokens, with output tokens reported but not billed. A 500-token item costs $0.000021 to judge, so 10,000 cost about $0.21 and a million about $21. TypeSafe say the price may be subsidised.

How do you run Jev in WorkerKit?

As a decision worker, which is a worker class rather than a model option. Jev is not in the deploy-time model picker, because that picker chooses which model does the writing work, and a decision worker does no writing: it fetches items, judges each one with typed questions, routes on the answer in code, and acts, through the same firewall door an agent worker uses.

What does Jev's confidence score actually measure?

The shape of the returned probability distribution, not the model's opinion of itself. Concentrated on one outcome means a high confidence, spread out means a low one, which is why choice and score answers carry it and noul answers, Jev's true-or-false question type, do not: a noul answer already is a probability. It says how decisive the answer was, not whether it was right.

When is a decision model the wrong tool?

When the rule is writable. Arithmetic, exact matching, lookups and thresholds on numbers you already hold are determined answers, and ordinary code gets them right every time for nothing. A decision model earns its place only where the input is genuinely ambiguous and the output is a short, known list, and even then only where something downstream checks the uncertain tail.

Browse decision model kits, language model kits, or both types in the directory.