Jev by TypeSafe AI: What's New, How It Works, and Alternatives (2026)
Most model launches this year have been about doing more. This one is about doing less, on purpose.
TypeSafe AI has released a model that does not chat, does not write, and does not explain itself. It answers questions with typed values and probabilities. That is the entire product surface.
This guide covers what the model is and how its three question types work. It also covers pricing, what the vendor says it is bad at, and where it sits next to the work most teams actually have.
What shipped
Jev is TypeSafe's flagship model. Per the vendor's official documentation, it is also "the first System One model."
The framing starts from a complaint about how the rest of the category works. Large language models, the documentation says, "are designed to produce text for humans to read." When you need a judgment your code will consume, "that creates a mismatch."
The documentation spells out the mismatch. You are "coercing a text-generation system into outputting structured decisions, then parsing the results back into something your code can depend on."
The alternative on offer removes the round trip. Jev "evaluates typed questions against a state and returns structured results directly. No text generation, no parsing."
The company's own site places Jev at the end of a lineage. Early language models, then pre-trained LLMs, then RLHF chat models, then RLVR reasoning models. Now RLCD, which it expands as "reinforcement learning for calibrated decisions."
What a System One model is
The name is borrowed, and the documentation says so directly. It "comes from the concept Daniel Kahneman popularized in his book Thinking, Fast and Slow."
System 1 is fast and intuitive. System 2 is slower and deliberate. Here "the emphasis is on fast, focused judgments."
The functional definition is narrower than the metaphor. These are "a class of AI models built to make fast, structured decisions that software can use directly." Such a model "evaluates a state and returns typed answers and probabilities."
One line separates Jev from everything else on the market. "Like an LLM, a System One model understands natural-language input. It returns typed decisions and probabilities rather than generated text."
The negative space is stated plainly by the vendor too. System One models "do not write replies, produce code, or generate explanations of their reasoning."
The three question types
You do not prompt Jev. You define an answer space, and it picks inside it.
There are three primitives. The documentation gives an example of each.
| Primitive | Question | Answer space | Output |
|---|---|---|---|
| Choice | Which team should handle this ticket? | billing, technical, or account | choice: "billing" |
| Score | How frustrated is this customer? | 0 = calm, 1 = frustrated, 2 = very frustrated | score: 1.4 |
| Noul | Does this message request a refund? | True or false | noul: 0.95 |
Choice selects one option from a defined set. Score rates against ordered, descriptive levels. Noul returns the probability that a yes/no question is true.
The Score example repays a second look. The answer is 1.4, not 1. Jev is placing the case between two named levels rather than snapping to the nearest one. That is a different output shape from anything a text model returns.
What it costs and what it accepts
The pricing page is unusually legible. That is not something one often writes about a model launch.
The current model is jev-1.13.0. Price is $42 per billion tokens, or $0.042 per million. The documentation is explicit that the charge is "per input token" and that "Output tokens are free."
Rate limits are published as 250,000 tokens per second and 1,200 requests per minute. Context length is 64k tokens per request. Of that, 32k is available for the state plus the longest question.
Input is text only. The documentation notes that Jev "evaluates strings, JSON objects, and arrays of text." It adds that "Images, audio, and video are not supported (yet)."
Everything runs through a single endpoint, POST /v1/systemone. A model field selects which model handles the call.
| Property | Value |
|---|---|
| Model | jev-1.13.0 |
| Price | $42 per Btok / $0.042 per Mtok, input only |
| Output tokens | Free |
| Rate limits | 250,000 tokens per second; 1,200 requests per minute |
| Context | 64k per request; 32k for state plus longest question |
| Input types | Text only |
Confidence is the part to pay attention to
The pricing is the headline. The confidence handling is the more interesting design decision.
Every Choice and Score answer carries a probabilities property across the options or levels. The documentation explains what to read from it. A distribution "concentrated on one outcome means a confident answer, spread out means an uncertain one."
A separate confidence property collapses that shape into a single number from 0 to 1. The documented purpose is "so you can threshold on it without doing the math yourself."
The reasoning behind shipping that number is stated as a principle. "If an intelligent system, whether human or machine, cannot express honest uncertainty, the system cannot be trusted."
What this buys you is a routing rule rather than a better answer. High confidence goes straight through. Low confidence goes to a person. The documentation frames it as deciding "when to act and when to escalate to a person or a reasoning model."
Anyone who has shipped a classification pipeline recognizes why that matters. The escalation path, not the accuracy number, decides whether the thing survives contact with real data.
What the vendor says it is bad at
TypeSafe publishes a page called model jaggedness, reviewed 2026-09-17. It lists the failure modes the company knows about. Shipping that alongside a launch is rare, and it saves everyone a round of guessing.
The summary line is candid. Jev 1.13 "is fast, calibrated, and good at common-sense judgment but it is not perfect."
Three weaknesses are named directly. It "may struggle with tasks that require additional levels of indirection." It "can be quite literal in its understanding." And it "struggles with tasks that require numeric precision."
The table of failure modes pairs each one with a remedy. Two are worth repeating for anyone sizing up a pilot.
- For math and numbers, the documented advice is to "Keep the arithmetic in code."
- For a large state full of irrelevant detail, it is to "Filter first; send only what the question needs."
Both point at the same design assumption. This is a judgment engine, not a calculator and not a search index. It works best when the surrounding system has already narrowed the question.
Where this sits next to the work you already have
There is a clean division of labour hiding in the vendor's own example. Naming it decides whether this launch is relevant to you at all.
The documented refund workflow builds a state and asks several independent questions at once. It then combines the answers "with deterministic checks in code" and routes the case "for action or review."
Every step there assumes a developer, an application, and high request volume. Per-token cost has to be a real line item before any of this pays back.
Most reporting work is the other shape. You have a file rather than a request stream. The judgments are a means rather than the product. What has to exist at the end is a document somebody reads.
Classifying four thousand rows of customer feedback is the middle of that job. The end is a summary naming the three themes and flagging the exceptions.
That second half is what a file-first workspace handles. You upload the export and describe the categories in natural language. The rows come back labelled, and the report explaining them arrives in the same pass. Powerdrill Bloom works this way, and the free tier already covers basic slides, docs, sheets, and images.
The two are not competing for the same slot. One is an API you wire into a product. The other is where a spreadsheet goes when a person needs an answer by Thursday. If your version of this problem arrives as a file, Try Powerdrill Bloom.
For the spreadsheet-side version of the labelling task, there is a walkthrough on categorizing Excel data. For the theme-finding version, there is a roundup of tools for customer feedback analysis.
Alternatives worth comparing
Three approaches cover the same ground. The right one depends mostly on volume.
General-purpose models with structured output. Every major provider now constrains responses to a schema. You get one model for judging and generating. The cost is paying generation prices for judgment work, and doing your own calibration.
Classical classifiers. A fine-tuned small model or a gradient-boosted tree is cheaper still and entirely predictable. That holds provided you have labelled data and a stable label set. It will not understand a policy written in prose.
File-first analysis workspaces. These handle judgment as one step inside producing a deliverable. No API, no schema, no per-token budgeting. Also no ability to sit inside a request path.
| If your situation is | Look at |
|---|---|
| Millions of judgments inside a product | A decision-only model |
| Mixed judging and drafting, low volume | A general model with structured output |
| Stable labels and plenty of training data | A classical classifier |
| A file that has to become a report | A file-first workspace |
There is a related roundup on tools for report generation covering the last of those.
Who should care now
Teams running high-volume judgment inside a product have the clearest case for Jev. Ticket routing, moderation queues, lead qualification, and eligibility pre-checks all fit. The pattern is a narrow question asked thousands of times a day, feeding a branch in code.
Teams doing occasional classification as part of analysis have the weakest case. The economics that make Jev compelling at scale are invisible at a few thousand rows. You still need something to write the summary afterwards.
Everyone else has a vocabulary to borrow rather than a tool to adopt. Separating fast judgment from slow synthesis is a useful lens on your own pipeline. It stays useful whether or not you ever send a request to this API.
One more practical note for anyone evaluating. Read the jaggedness page before the pricing page. Knowing where a model is weak shapes the pilot far more than knowing what it costs.
Frequently asked questions
What is a System One model?
It is a class of model built to make fast, structured decisions that software can use directly. It evaluates a state and returns typed answers and probabilities. The name references Kahneman's System 1, the fast and intuitive mode of thinking. Unlike a chat model, it does not write replies, produce code, or explain its reasoning.
How much does Jev cost?
The published price for jev-1.13.0 is $42 per billion tokens, or $0.042 per million. Charging is on input tokens only, and output tokens are free.
What can Jev take as input?
Text only, as strings, JSON objects, or arrays of text. The documentation states that images, audio, and video are not supported yet. Context is 64k tokens per request, with 32k for the state plus the longest question.
How is it different from asking an LLM for JSON?
Both understand natural-language input. The difference is what comes back and how it was trained. Jev returns typed decisions with a probability distribution and a confidence value. Calibration is measured across groups of predictions, so it does not guarantee any individual answer is correct.
What is Jev not good at?
The vendor's jaggedness page lists literal reading, math and numbers, and date and time comparison. It also lists indirection, large states full of irrelevant detail, adversarial content, and contradictory criteria. Its documented advice for the arithmetic case is to keep the arithmetic in code.
Sources: TypeSafe AI documentation — Introduction, System One, Models, Confidence, and Jev 1.13 jaggedness, docs.typesafe.ai, as of September 18, 2026.