Jev: how AI built for fast decisions works
Neaptide · September 27, 2026 · 12 min read
How Jev works: Choice, Score, Noul, probabilities, and limitations. A guide to System One, published performance claims, and testing on your own tasks.
On this page
A customer writes: “I can’t export the catalog. CSV works, but XLSX doesn’t. I need to send the file to a supplier by this evening.” The application needs to identify the topic, assess the impact, and choose what happens next. A lengthy model response may add unnecessary work here: the system needs a few specific values.
Jev is TypeSafe’s model for these kinds of judgments. You send it context and questions with defined answer types; it returns values and probabilities that software can use. TypeSafe calls this approach System One. The model does not write emails or code, or explain its reasoning.
In its September 15, 2026 announcement, the company opened early access and emphasized fast, inexpensive decisions. To understand Jev’s practical value, it helps to follow the entire path from a question to an action in an application.
Where Jev fits in an application
A request contains state, the material to evaluate, and questions, the questions about that material. The context can be a message, a JSON object containing ticket fields, or an array containing text data. Questions within a single call share the context and are evaluated independently. Jev accepts text data only: images and audio need to be converted into text or relevant fields first.
In this example, you can ask separately which department the customer needs, how much the issue affects their work, and whether they want to speak to a person. The rule that sends technical tickets to the appropriate queue stays in code. If the support process changes, a developer can update that rule separately from the questions.
This separation is useful in itself. Asking “What should we do about this customer?” combines language understanding, business priorities, and permitted actions. Narrow questions make it easier to see where the system went wrong. TypeSafe recommends this way of organizing the work.
Three question types, three meanings
Jev provides three basic question types: Choice, Score, and Noul. The right one depends on what the application needs to know.
Choice fits a question with one answer from a defined set, such as technical, billing, or other. The response includes the selected option, a probability distribution, and confidence. Category descriptions should make the options distinguishable.
Score is for an ordered scale. To assess an issue’s impact, you could describe levels as “no effect on work,” “disruptive, but a workaround exists,” and “work has stopped.” The result can fall between levels: it is the average of their indices, weighted by the probability distribution. A score of 1.4 on a 0–2 scale does not mean that 70% of users are affected.
Noul evaluates a single yes-or-no question, such as “Does the customer explicitly ask to speak to a person?” A value from 0 to 1 expresses the probability of yes. A value near 0.5 means uncertainty, not a “moderate request.” Noul has no separate confidence field.
A useful wording check is whether a colleague can distinguish the options without a verbal explanation from their author. If not, clarify the categories and levels first. The model will not resolve an ambiguous business rule on the developer’s behalf.
What “no hallucinations” actually covers
In its announcement, TypeSafe links the absence of hallucinations to a constrained answer space: the model returns values allowed by the structure. This addresses a specific problem—an arbitrary answer appearing where the application expects a particular type.
If three departments are available, selecting an existing one does not prove that the ticket reached the right team. A format guarantee does not establish correct interpretation of the text. For the same reason, schema compliance does not establish that a business action was correct.
Comparing Jev only with a chat model prompted to “return JSON” is also insufficient. TypeSafe’s own adapter supports LLM providers’ native structured-output modes. For a real project, compare complete integration options: decision quality, latency, cost, and failure handling.
Probabilities help when the application can act on them
Imagine two Choice responses with the same winner: technical support. In the first, almost all probability goes to that option. In the second, two other options are close behind. The selected department’s name alone hides that difference.
For Choice and Score, confidence is derived from the shape of the probability distribution. It should not automatically be read as “the probability that this answer is correct.” TypeSafe suggests using it to guide subsequent behavior, with thresholds chosen for the task.
Calibration is a separate concept. Across a large set of comparable predictions assigned a probability of 0.8, an event should occur roughly 80% of the time if the model is well calibrated. This is a property of a group of predictions. It does not promise a correct answer in each individual case. TypeSafe describes RLCD—Reinforcement Learning for Calibrated Decisions—as a method aimed at training these probabilities.
The practical implication is to define a route for ambiguous tickets in advance. A confident department choice might allow automatic routing, while a spread-out distribution sends the ticket to a general review queue. Choose the threshold based on the cost of a wrong route and results on your own messages.
Reading the speed and cost claims
Published numbers can support an initial assessment, but they have different foundations. A documented price is a tariff. Response time is an observation under particular conditions. Performance on a test set is a comparison with selected alternatives.
| Metric | What is published | How to use it |
|---|---|---|
| Response time | The announcement gives a 70–500 ms range; evaluations were generally run from the US West Coast, where the service was based | Measure latency from your application’s region, including slower responses |
| Jev 1.13 price | $0.042 per million input tokens; output tokens are free | Price the entire input, including context and questions |
| Workflow quality | Four scenarios: security incidents, agent observability, invoice processing, and customer service | Examine the methodology and test your own scenarios |
Sources: measurement conditions in the announcement, models and pricing, and Workflow evals. Checked September 27, 2026.
Workflow evals builds its reference from the averaged responses of GPT-6 Astra and Claude Fable 5.1 with high reasoning settings; other participants use their providers’ defaults. The result therefore measures agreement with a chosen model reference within a defined process. It is not the same as accuracy against independently labeled real outcomes.
For a sense of scale, consider an illustrative calculation: one million calls with one thousand input tokens each means one billion tokens, or $42 at the published rate. Those thousand tokens must cover both context and questions. This excludes retries, other models, infrastructure, and human review.
When choosing a system, the cost per correctly handled ticket is more useful. A cheap call helps little if a substantial share of tickets requires a person to fix the result.
Where Jev helps—and where another tool is needed
Recurring decisions about text are a natural place to try it: identify a request’s topic, assess whether something matches a description, or select a category. What comes next depends on what the system needs to do with the result.
For the export failure, Jev can assess the complaint’s content. Checking service availability, calculating an SLA deadline, and changing the ticket status remain ordinary software operations. A reply can be assembled from a template or drafted by a generative model using verified facts and the chosen action.
This division reflects the limitations TypeSafe describes for Jev 1.13. The model is unreliable at precise counting and date comparison; irrelevant information in a long context degrades answers. Deliberately crafted text can influence classification. The developer recommends keeping calculations in code, removing irrelevant context, and testing difficult cases.
If your product handles languages other than English, build a separate test set for each relevant language. The documentation identifies English as the primary training language and the language with the best current accuracy; performance in other languages can differ. This matters when tickets contain abbreviations, typos, and specialist terminology.
Starting a pilot in your product
Choose one frequent decision with a clear correct outcome, such as assigning tickets to departments. Keep the current process as a baseline. Label real, anonymized examples, including ambiguous ones, and separate the material used for tuning from the final evaluation set.
Track two quantities together: the share of tickets handled automatically and the error rate within that automated share. A threshold that sends almost everything to a person can produce impressive accuracy with little automation. A more permissive threshold must be assessed against the cost of corrections.
Add p95 latency—the time within which 95% of measured requests finish—model spending, and human workload. Compare Jev with your current process and a suitable LLM on the same examples. TypeSafe’s adapter has modes for returning probabilities or discrete decisions; choose comparison conditions that reflect your application’s actual needs.
Store the model version, questions, and thresholds with the results. The jev-latest alias can point to a new release; the documentation recommends pinning a specific identifier once behavior has been tuned to it.
Jev has a clear engineering premise: turn a semantic judgment into a small, observable step in a program. Test it where these steps are frequent and the team can define an error precisely. A pilot can then show which decisions can be automated and how much uncertainty remains outside that automation.
Based on public primary sources checked on September 27, 2026. Examples and diagrams are illustrative. We did not make API calls or independently benchmark Jev.