Jev: how AI built for fast decisions works
Neaptide · September 27, 2026 · 12 min read · Updated: October 3, 2026
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 has to work out what the message is about, how badly the failure hurts, and what happens next. A long reply from a model is no help here. The system needs a handful of specific values.
Jev is TypeSafe’s model for this kind of judgment. You send it context and questions with defined answer types, and it returns values and probabilities your software can use directly. TypeSafe calls the approach System One. The model writes no emails and no code, and it does not explain its reasoning.
In its September 15, 2026 announcement, the company opened early access and pitched Jev on speed and low cost per decision. To see what that is worth in practice, follow the whole path from a question put to the model to an action taken by the application.
Where Jev fits in an application
A request has two parts: state, the material to evaluate, and questions about that material. The context can be a message, a JSON object with ticket fields, or an array of text values. Questions in a single call all see the same context and are evaluated independently. Jev takes text only, so images and audio have to be converted into text or into the relevant fields first.
In this example you can ask three separate things: 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 right queue stays in code. If the support process changes, a developer updates that rule and leaves the questions alone.
The split pays off on its own terms. “What should we do about this customer?” bundles language understanding, business priorities, and permitted actions into one question. With narrow questions you can see which step went wrong. TypeSafe’s documentation recommends working this way.
Three question types, three meanings
Jev has three basic question types: Choice, Score, and Noul. Which one to use depends on what the application needs to find out.
Choice fits when you need one option from a defined set, such as technical, billing, or other. The response contains the selected option, a probability distribution, and confidence. Write the category descriptions so that the options can be told apart.
Score is for an ordered scale. For the impact of an issue, the levels might be “no effect on work,” “disruptive, but a workaround exists,” and “work has stopped.” The result can land between levels because 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 gives the probability of yes. A value near 0.5 means the model is unsure; it does not mean a “moderate request.” Noul has no separate confidence field.
To check your wording, ask whether a colleague could tell the options apart without the author explaining them out loud. If they could not, tighten 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 ties the absence of hallucinations to a constrained answer space: the model can return only the values the structure allows. That removes one specific problem, an arbitrary answer turning up where the application expects a particular type.
Say there are three departments. Picking one that exists does not prove the ticket reached the right team. A guarantee about format says nothing about whether the text was understood correctly, and schema compliance does not show that the resulting business action was the right one.
Comparing Jev only with a chat model that has been told to “return JSON” is not enough either. TypeSafe’s own adapter supports LLM providers’ native structured-output modes. For a real project, compare complete integrations on decision quality, latency, cost, and failure handling.
Probabilities help when the application can act on them
Picture two Choice responses with the same winner, technical support. In the first, nearly all the probability sits on that option. In the second, the other two options are close behind. The department name alone hides the difference.
For Choice and Score, confidence is derived from the shape of the probability distribution. Do not read it as “the probability that this answer is correct.” TypeSafe suggests using it to decide what the application does next, with thresholds chosen for the task.
Calibration is a separate idea. If a well-calibrated model assigns a probability of 0.8 across a large set of comparable predictions, the event should occur roughly 80% of the time. That is a property of the group of predictions and promises nothing about any single case. TypeSafe describes RLCD (Reinforcement Learning for Calibrated Decisions) as its method for training these probabilities.
In practice, decide in advance where ambiguous tickets go. A confident department choice might allow automatic routing, while a spread-out distribution sends the ticket to a general review queue. Set the threshold from the cost of a wrong route and from results on your own messages.
Reading the speed and cost claims
The published numbers are good enough for a first estimate, but they do not all rest on the same footing. The documented price is a tariff. The response time was observed under particular conditions. A lead 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 October 3, 2026.
Workflow evals builds its reference from the averaged responses of GPT-6 Astra and Claude Fable 5.1 at high reasoning settings; the other participants run at their providers’ defaults. So the result measures agreement with a chosen model reference within a defined process. That is not the same as accuracy against independently labeled real outcomes.
For a sense of scale, take an illustrative calculation: one million calls at one thousand input tokens each comes to one billion tokens, or $42 at the published rate. Those thousand tokens have to hold both the context and the questions. Retries, other models, infrastructure, and human review are not included.
When you choose a system, cost per correctly handled ticket is the more useful figure. A cheap call helps little if a person has to fix a substantial share of the results.
Where Jev helps—and where another tool is needed
Recurring decisions about text are the natural place to try it: identifying a request’s topic, judging whether something matches a description, picking a category. What comes next depends on what the system has to do with the result.
With the export failure, Jev can assess what the complaint says. Checking service availability, calculating the SLA deadline, and changing the ticket status remain ordinary software operations. The reply can be assembled from a template or drafted by a generative model that is given the verified facts and the chosen action.
This division matches the limitations TypeSafe itself lists for Jev 1.13. The model is unreliable at exact counting and at comparing dates, and irrelevant detail in a long context makes its answers worse. Deliberately crafted text can sway a classification. The developer recommends keeping calculations in code, trimming irrelevant context, and testing difficult cases.
If your product handles languages other than English, build a separate test set for each one. The documentation names English as the primary training language and the one where accuracy is currently best; other languages can perform differently. That matters when tickets are full of abbreviations, typos, and specialist terms.
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 the baseline. Label real, anonymized examples, ambiguous ones included, and keep the material used for tuning apart from the final evaluation set.
Track two quantities together: the share of tickets handled automatically and the error rate within that share. A threshold that sends almost everything to a person can show impressive accuracy and automate very little. A more permissive threshold has to be weighed 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 can return either probabilities or discrete decisions, so pick comparison conditions that reflect what your application actually needs.
Store the model version, questions, and thresholds with the results. The jev-latest alias can move to a new release, which is why the documentation recommends pinning a specific identifier once behavior has been tuned to it.
The engineering premise behind Jev is clear: make a semantic judgment a small, observable step in a program. Test it where such steps are frequent and the team can say precisely what counts as an error. A pilot will then show which decisions can be automated and how much uncertainty is left outside that automation.
Based on public primary sources checked on October 3, 2026. Examples and diagrams are illustrative. We made no API calls and ran no benchmarks of Jev ourselves.