Jev: When Software Just Needs a Decision

I recently came across Jev and found it interesting. We have grown used to asking a model to write a response and having our code extract a judgment from it. Yet plenty of software only needs to know where a request should go, whether a document is relevant, or whether to call a tool now.

When I wrote about Interaction Models, I was interested in whether models could move beyond question-and-answer turns into continuous interaction. Jev raises another question for me: when software is using the model, what form should its intelligence take?

What Jev offers

Jev is a product from TypeSafe AI. The company calls this class of models System One Models, borrowing the distinction between fast and slow thinking. It targets decisions with a clear scope that need to be made repeatedly.

For example, provide a customer support message as the state and offer three options: billing, technical support, and sales. The model returns its choice and the probability of each option. It can choose an answer, score against a predefined scale, or estimate the probability that a statement is true. Several questions about the same state can be answered in parallel, after which code combines the results and decides what happens next.

Classifiers have been around for a long time, and ordinary language models can do these tasks too. But not every application can accept the latency and cost of a model call, especially when judgments need to happen repeatedly. Training a separate model for each task can make inference fast, but data preparation, training, and maintenance also have a cost. New settings require further adaptation.

What I find interesting about Jev is the balance it tries to strike: retain some ability to understand complex text and work across tasks while making judgments fast and cheap. Software can try different tasks by changing the questions and answer options, without retraining a model for every new classification scenario. The output can be simple even when the input is not. This also makes me think that building on language or multimodal understanding, with different training objectives and output methods, could be a worthwhile way to design models for fast judgments. Some uses that previously relied on agents to make decisions, but ran into cost and latency limits, could consider this design.

TypeSafe reports end-to-end latency of 70–500 ms, with an input price of $0.042 per million tokens and free output. Jev skips generating an answer token by token, making frequent calls more practical. How much understanding and versatility it retains still needs to be tested on specific tasks, but this design makes me think that many applications could reconsider which judgments are worth handing to a model.

A timeline of the past few weeks

These are the publicly verifiable milestones as of October 4, 2026.

Date	What happened
2026-09-15	TypeSafe released Jev in early access and introduced System One Models.
2026-09-24	Alibaba Cloud Model Studio launched `decision-model-preview`, supporting classification, yes/no judgments, and scoring.
2026-09-29	OpenAI announced the Decisions API at DevDay, directing Luna to answer from predefined, finite options. It launched in limited preview, with broader availability planned to follow.

Other vendors are already offering similar capabilities. Alibaba Cloud Model Studio provides a dedicated decision model API, while OpenAI puts this capability into Luna’s interface and accepts both text and image context. Both aim to give software a quick judgment it can act on.

On the open-weight side, the community is also adapting models such as LLaMA to similar decision interfaces, returning choices and probabilities locally. This lets people deploy and adjust the capability themselves. There are now public evaluations of these models (those papers came out ridiculously fast), but practical performance, transfer across tasks, and whether the probabilities can be trusted still need to be tested in real applications.

What this could change

What I most want to see is how many software features this balance could make viable. Some decisions do not require extended reasoning, yet are difficult to handle with a few fixed rules. Others need more understanding, but cannot necessarily afford the cost and wait of calling a large model every time. Which team should handle a request, whether a document is worth reading further, and whether a result needs another check are all recurring questions in software. If these judgments can be made at an acceptable cost, semantic understanding can reach more of the small steps inside ordinary applications.

Within an agent, routine decisions can be handled quickly, uncertain tasks escalated, and complex problems passed to a stronger generative model, with code responsible for execution. Software can reserve more of its budget for steps that require deeper reasoning while a decision model handles the smaller judgments in the workflow. To me, this suggests that the division between fast and slow thinking can extend beyond whether a model produces a chain of thought (CoT) to the design of the model itself: fast judgments and extended reasoning may need different training objectives and output methods.

This balance still needs to be tested. Beyond speed and price, we need to know how complex an input it can handle, whether it remains reliable on a different task, and how many judgments it gets wrong among the tasks a system handles automatically. Stable output formatting is only one condition.

This reminds me of the Jevons paradox I discussed before: greater efficiency and lower costs can expand total demand. When one judgment becomes cheaper, software may make more judgments and gain features that previously were not worth building. If these models can balance understanding, versatility, and the cost of a call, I think their uses could extend well beyond what we picture today.