Jev: An AI Model for Classification, Scoring, and Automated Decisions
An article already has a summary; the next decision is whether it is worth reading now. A support ticket has entered the system; the next decision is which team should handle it. These questions require language understanding, yet their answers may consist of just a few options. What the software needs is a judgment it can use to rank or route something.
Jev is designed for this kind of work. Developed by TypeSafe AI, it takes information to evaluate and questions defined in advance, then returns choices, scores, or probabilities for code to process. It does not generate summaries, explanations, or code. It can serve as one decision step within existing software.
This article describes Jev as of September 18, 2026: how to ask it questions, how to interpret its answers, what supports its speed and cost claims, and which parts of a practical application should remain with ordinary code or people.
What System One Means
TypeSafe introduced Jev publicly in September 2026 and calls this class of models System One. The name borrows Kahneman's distinction between fast intuition and slow reasoning; Jev is named after the economist William Stanley Jevons. The company hopes that cheaper judgments will make more kinds of automation economical. Its release announcement also describes parallel sampling and a training approach focused on decisions.
“System One” is the name of a product and research direction here. To understand it, start with the shape of the task: provide enough context, then ask for a focused judgment that can be made quickly. Investigating an unfamiliar question, planning a long sequence of actions, or developing a complete argument requires retrieval, reasoning, and generation to be organized separately.
TypeSafe calls its training method RLCD, or “Reinforcement Learning for Calibrated Decisions.” According to its technical primer, the aim is to produce decisions accompanied by useful probability information. The public material explains this objective but does not provide enough detail to reproduce the full training process. This article therefore makes no assumptions about parameter count or internal network architecture.
What a Request Needs
A request has two parts: material and questions, called state and questions in the API. The first contains the information the model needs to see; the second specifies what to judge and which answers are allowed. One request can contain several questions that share the material and are evaluated independently. The question definitions explain this structure. If a later question needs an earlier answer, the program must connect those steps in sequence.
For a reading recommendation, the material could be a summary and the topics the reader currently cares about. The question would be whether this content is worth reading now, with the answers defined as:
- Read now: Directly helps solve a current problem.
- Keep: Useful background, but not urgent.
- Skip: Unrelated to the current focus.
- Unsure: Not enough information for a reliable judgment.
The options need clear definitions. If both “Keep” and “Read now” mean only “useful,” the model has little basis for distinguishing them. Without “Unsure,” insufficient information can also be forced into one of the other categories.
The model can judge only the material it receives. If it receives a title, the conclusion can concern only that title. If it receives a summary, that does not mean it has read the full article. Fetching pages, extracting subtitles, and ensuring that a summary is faithful remain the responsibility of the program supplying the material.
Three Output Types for Different Questions
A Score is a probability-weighted position across the levels. For example, after defining “unrelated,” “relevant background,” and “directly relevant” as three levels, a fractional value represents the model's judgment between them. It is not inherently a percentage score. Change the level descriptions and the number's meaning changes too.
A low Noul probability can be useful as well. A result of 0.02 for “Does the material lack body text?” means the model leans toward the body text being present. Reading that as “the model is only 2% confident” confuses the probability of the proposition with uncertainty about the judgment.
An ordinary chat request to “give this a score” often leaves these definitions unstated. Jev requires the application to define the scoring criteria first, which also forces the developer to answer a practical question: what will the application actually do with the score?
Probability, Confidence, and Accuracy
A Choice could assign 0.51 to “Read now” and 0.49 to “Keep,” or it could assign them 0.97 and 0.03. The preferred option is the same in both cases, but the first has almost no clear advantage. Keeping only the final category loses that distinction.
TypeSafe's confidence is a statistic between 0 and 1 calculated from the complete probability distribution of a Choice or Score. It summarizes how concentrated the distribution is. It is neither a second, independent judgment nor the probability of the most likely option. Noul does not include this separate field.
Seeing both a high probability and a high confidence therefore does not provide two independent pieces of evidence. Both describe the same output distribution. Displaying more decimal places adds no factual support.
“Calibrated probabilities” must be understood across many predictions with known outcomes. For example, if a group of predictions assigns roughly an 80% probability to an event, good calibration means the event occurs in close to 80% of those cases. A single output cannot establish this property.
A reading tool can initially keep model recommendations alongside human choices, observe which materials are often misclassified, and then decide how clear a result needs to be before it changes the reading order. Moving a worthwhile article farther down the list has different consequences from deleting it automatically. There is no reason for both actions to share a threshold.
Likewise, showing “Unsure” when the highest probability falls below a certain value is an application rule. That threshold needs to be adjusted using real material. The presence of probabilities does not turn an arbitrary number into a validated standard.
How to Interpret “Zero Hallucinations”
Defining the answer space in advance removes one kind of problem: when the program asks for an existing option, the model cannot invent a different response in prose. This makes the interface easier to check and errors easier to locate.
But an answer of the correct type can still be the wrong choice. A classifier can use a valid format while routing a complaint to the wrong team. Format constraints address whether the result follows the interface; the application must still decide whether the result makes sense. This is also the distinction between tool contracts and task correctness.
TypeSafe's own known limitations of Jev 1.13 include numerical tasks, counting, date comparisons, reasoning across several steps, long irrelevant context, and adversarial text. When asked separately, a proposition and its negation are not guaranteed to satisfy the probability relationships one might expect.
These limits directly affect how the model should be used. Code can compare monetary amounts; the model can judge whether text is relevant. A sentence supplied by a reader cannot authorize the model to rewrite the classification rules. When a result needs an explanation, it should be traced back to the input evidence, not handed to another model to invent a plausible-sounding reason.
The Experiments Behind the Speed Claims
TypeSafe's homepage has advertised comparisons of 193.6 times faster and 444.6 times cheaper. Those figures need to be read alongside the tasks and comparison methods. They cannot be translated directly into gains that every application will receive.
Its workflow evaluation covers security incidents, agent execution records, invoices, and customer service, with equal weight given to the four tasks. Reference answers average judgments from GPT-6 Astra and Claude Fable 5.1 at high reasoning settings. This is a comparison designed by the vendor and evaluated against other models.
It supports a direction worth testing: breaking complex tasks into explicit judgments and combining them in code may work better than generating a long response at every step. But model consensus does not automatically establish real-world truth. If the reference models share a bias, answers close to theirs may preserve the same bias.
Actual latency also depends on network distance, input length, the gateway, concurrency, and client-side processing. For a personal tool, the most meaningful measurement is how long a user waits after clicking. For a batch system, sustained throughput and failure rates also matter, as does how long the slowest requests hold up later work.
Pricing, Input Capacity, and Chinese-Language Performance
On the day checked, Vercel's public model catalog listed Jev's exact input price as 0.042 USD per million tokens, with no charge for output tokens. The model page rounds the input price to 0.04 USD. Tokens are units used to measure the text a model processes; they cannot be treated as a count of Chinese characters.
As a simple arithmetic example, suppose 10,000 requests use a total of 20 million input tokens. At that rate, the model input charge would be about 0.84 USD. This accounts only for model usage. Additional requests, longer material, infrastructure, and human handling all change the actual cost. Cheap individual judgments can still become a recurring expense when calls are numerous.
TypeSafe's current model documentation lists these limits:
Even with a large enough context window, send only what the judgment needs. When a lengthy meeting transcript contains one crucial requirement, locating the relevant passage first is often easier to check than sending everything to the model.
Chinese-language use especially needs local examples. Accepting Chinese input and returning a plausible option establishes only that the interface and one example work. Domain abbreviations, irony, double negatives, and unstated context all belong in a meaningful validation set.
Integrating Jev into Existing Software
Connecting directly to TypeSafe and accessing it through a gateway are different integration paths. This section covers the Vercel AI Gateway evaluation interface used in this trial. It requires AI SDK 7, uses the model name typesafe-ai/jev, and is called through experimental_evaluate. It is not a chat generation interface; replacing a chat model's name is not enough to make the same call work.
The interface accepts choice, score, and boolean questions, with boolean used for yes-or-no judgments. The AI SDK evaluation documentation provides the full contract. Through Gateway, TypeSafe's additional confidence values appear under providerMetadata.typesafe.confidence, separately from the probability distributions in answers. The API still carries an experimental label, so its behavior should be checked again when dependencies are upgraded.
The following fictional reading scenario illustrates the request structure. The key is supplied through AI_GATEWAY_API_KEY in the server environment, and the example enables the no-training option:
import { experimental_evaluate as evaluate } from 'ai';
const result = await evaluate({
model: 'typesafe-ai/jev',
state: {
interest: 'Local speech tools and privacy',
excerpt: 'A fictional offline speech tool caches audio locally.',
},
questions: {
reading: {
type: 'choice',
instructions: 'How relevant is this excerpt to the current interest?',
criteria: {
read: 'Directly useful now',
keep: 'Useful background for later',
skip: 'Unrelated',
unsure: 'Not enough information',
},
},
},
maxRetries: 0,
providerOptions: {
gateway: { disallowPromptTraining: true },
},
});
console.log(result.answers.reading);
Once the application receives the reading answer, it can display the recommendation directly or use the probabilities to adjust the reading order. The program still supplies the classification criteria; a different set of topics can produce a different result for the same material.
No Training and Zero Data Retention Are Different Requirements
The gateway, model provider, and application itself may all process the same request. Privacy discussions need to distinguish which layer a requirement applies to.
Vercel's disallowPromptTraining restricts requests to provider routes that meet its no-training requirements and is available on all plans. It does not promise that content will never be retained. Requests that use your own provider keys, known as BYOK, also have separate rules.
zeroDataRetention adds a requirement for zero data retention by the provider. Vercel currently offers request-level ZDR to Pro and Enterprise teams. A model's presence in the public catalog does not mean an account can enable every privacy option.
Using Jev for Reading Decisions
This trial used a fictional Chinese description of a tool and a related set of reading topics, with the outputs limited to “Read now,” “Keep,” “Skip,” and “Unsure.” After the request was sent through Gateway in ordinary mode, Jev chose “Read now” with a probability of 1.0. That request completed in about 0.8 seconds, including the gateway call and result processing.
The topic was clear in this example, and the result matched expectations. More tangibly, it showed where Jev fits into software: material goes in, a choice with probabilities comes out, and the interface can use it directly without extracting a category from a long explanation.
The more interesting cases to examine next are the difficult choices. If the topic is relevant but the content is vague, should the result be “Read now” or “Keep”? With only a striking title, can it reliably choose “Unsure”? These situations can form a set of examples to compare against human choices. Such comparisons can gradually establish whether its Chinese judgments are consistent and whether its probabilities are useful.
When Jev Is Worth Considering
A suitable starting point is one frequent, clearly bounded judgment in an existing system whose errors can be corrected. First see whether it consistently reduces manual work, then decide whether to expand its use. Instead of letting one model response decide the entire workflow, keep exact calculations in code and use language understanding only for the step that needs it.
This division of work can be combined with an agent loop and can also guide model selection. Who will consume the output, and what happens if it is wrong, often determine a model's suitability more clearly than whether it is the most powerful model available.