When AI no longer writes, but decides: what System One models are about

For the past few years, the development of artificial intelligence has been shaped mainly by one question: How can language models solve ever more complex tasks? They are meant to research, write code, analyse, and increasingly act on their own. For that they get more compute, more context, and more time to think.

Since September 2026, an interesting counter-movement has been taking shape. Instead of making AI models do ever more, vendors are building systems specialised in a single capability: They are meant to classify information and return decisions, not generate text.

TypeSafe AI, a US company, started on 15 September with its model Jev. Shortly afterwards, the first independent tests and open alternatives appeared. On 6 October, OpenAI presented its own Decisions API.

What began as an unusual product announcement is becoming a broader development. Companies now have to ask whether this makes it simpler, faster, and more economical to automate processes.

From language model to decision model

Anyone using AI in a company today usually thinks of language models such as ChatGPT or Claude. These systems can understand text, answer questions, summarise documents, and structure information.

In many business processes, though, no newly written text is needed at all.

An incoming customer email has to be assigned to the right team. A support request needs a priority. A sales contact should be scored against defined criteria. An automatically generated reply has to be checked for possible policy violations.

These are not writing tasks. They are classifications and assessments, on the basis of which something is then meant to happen.

Such tasks have long been solvable with AI. Classic classification models often need purpose-built training data. Modern language models can answer many of these questions immediately from a description, but they are not always the most economical tool.

That is exactly where the new decision models come in.

TypeSafe calls its development a System One Model, after psychologist Daniel Kahneman's distinction between fast, intuitive thinking and slow, analytical thinking.

While generative language models produce text flexibly, Jev is limited to predefined answer options. The model receives a piece of information and one or more questions. What comes back are structured results and probability scores.

An example from customer service:

A message reads: "Since the last update, our invoice overview no longer works. We urgently need help."

A decision model could answer three questions about it:

• Which team is responsible: engineering, accounting, or sales?
• How urgent is the request?
• Is this likely a complaint?

The answers can be processed directly by software. It does not first have to interpret a freely worded AI text.

So what is new is not that AI can classify text. What is new is that this capability is being offered as a standalone service, optimised for speed and structured decisions.

What has happened since September

The development is still young, but it has gained momentum within a few weeks.

15 September: TypeSafe introduces Jev.

The company presents a model that answers three kinds of questions: a choice among fixed options, a rating on a scale, and an assessment of whether a statement is true.

According to TypeSafe, Jev needs between 70 and 500 milliseconds per call. Input costs 0.042 US dollars per million tokens under the published terms; output is not billed separately.

TypeSafe uses a training method it developed itself, called Reinforcement Learning for Calibrated Decisions (RLCD). It is meant not only to enable correct decisions, but also to produce meaningful probabilities.

These are vendor figures for now. The quality of those probabilities in particular cannot be judged from the product announcement alone.

Source: TypeSafe AI, product page and documentation

29 September: inovex publishes the first practical tests.

AI specialists Nicolas Werner and Ivan Herreros Alonso examined Jev on several hundred requests and compared it, among other things, with a small Gemini language model.

The results show both the potential and important constraints.

In their tests, Jev answered after around 300 milliseconds, while the comparison model needed between two and seven seconds. For narrowly defined classification tasks, that is a clear difference.

At the same time, the testers found that the reported probabilities can fluctuate. Identical requests led to different values; the order of the answer options also sometimes affected the result.

Another finding is particularly interesting: if several related questions are asked, their answers can contradict each other, because Jev evaluates the questions independently.

That matters for operations. A model may reliably assign a message to a category. It does not follow that it will equally reliably handle complex decisions with several interdependent conditions.

The authors therefore see the greatest potential mainly in individual classification tasks inside large data streams.

Source: inovex, TypeSafe AI Jev im Test, 29 September 2026

Late September: open alternatives appear.

The idea does not stay with TypeSafe. Within a short time, projects such as Kev, SemIf, and djev appear, offering similar decision functions on top of other models.

An important difference: such solutions can in principle be run on your own infrastructure.

That gives companies an extra choice between a specialised cloud service and a self-hosted solution.

The open models are not automatically equally capable, though. Model size, training effort, language support, and accuracy differ. A working replica of the interface is not yet proof of comparable decision quality.

An overview of the open projects is in the inovex test report.

6 October: OpenAI publishes the Decisions API.

With the new Decisions API, OpenAI takes up the same basic idea: instead of freely worded answers, the system returns structured decisions.

The API supports yes/no assessments, choice decisions, and ratings on defined scales. Unlike Jev, it can process images as well as text.

According to OpenAI, processing is up to ten times faster than via the regular Responses API. At launch, GPT-6 Luna is available as the model. The interface is in public beta.

That does not mean both vendors have built technically identical models. The common ground is mainly the application pattern: AI is integrated into software as a fast decision component, not as a conversation partner that writes on its own.

Source: OpenAI, Decisions API documentation

Why this starts to matter for SMEs

For mid-sized companies, the possible value is not that a single decision costs a fraction of a cent less.

What matters is what happens when such decisions are needed regularly, and in many places.

A typical company is full of small work steps that rest on a human classification.

Someone reads an incoming message and forwards it. Someone else decides whether a case is urgent. In sales, requests are pre-sorted. In purchasing, documents are checked and assigned to the right people.

Each of these tasks looks too small on its own to justify a dedicated AI project. Together, they can create a substantial amount of handling work.

Decision models could be used in exactly those places.

Pre-sorting inbox and support automatically

One possible application is shared mailboxes and support systems.

Incoming messages are assigned to a category based on their content and, if reliability is high enough, forwarded directly to the responsible department.

Unclear cases still go to a person.

The value does not necessarily come from classifying a large email archive once, but from continuous relief in the daily inbox.

Pre-checking documents

Invoices, delivery notes, and order confirmations contain information that often has to be classified first.

A decision model can, for example, use text that has already been extracted to judge which document type is present, or whether certain details are recognisable.

The division of labour matters here: extracting scanned documents is first handled by a suitable OCR or document AI. The decision model then assesses the information that is available.

Binding checks, calculations, and booking rules remain the job of the line-of-business software.

Prioritising sales requests

Scoring incoming leads is another possible use case.

Instead of letting an AI decide in one go whether a request is good or bad, individual criteria can be examined: Is a concrete need described? Is there a time frame? Does the request fit the offered portfolio?

Software can then weight the resulting scores using rules set by the business.

That way you do not get an opaque overall decision from the model, but a prioritisation that is defined in a reconstructable way, based on individual assessments.

Monitoring AI systems and routing requests

Use inside existing AI applications may be particularly interesting.

A decision model can, for example, check whether a user request is likely to contain a policy violation, whether a reply makes an unauthorised commitment, or whether a case should be passed to a more capable model.

The decision model then becomes an additional control and routing component.

It does not, however, replace a full quality review or a reliable security architecture. Such a model can also misclassify problematic content.

The real change is in the architecture

Many current AI applications follow a simple principle: a language model is given a task and is meant to do as much of it as possible itself.

It interprets information, plans next steps, formulates results, and may decide on further actions.

That is flexible, but for simple, recurring flows it can be unnecessarily expensive.

With specialised decision models, a different split becomes interesting:

The decision model classifies. The language model writes or analyses. The company's software executes defined actions.

For example, an incoming customer request can first be classified. For a standard question, the software starts a defined process. For complex cases, a capable language model is involved. For critical or unclear cases, a staff member takes over.

The actual control stays in the process, not with the AI model alone.

Such an architecture pattern is not new in principle. Language models can already be used as classifiers, or classic rules can be combined with AI.

The new APIs could make this approach simpler and more economically attractive, especially at high request volumes or in time-critical applications.

From our point of view, that is the interesting point: Not every fork in a business process needs a generative language model.

Where the limits are

However convincing the basic idea looks, it is important to distinguish a plausible decision from a reliable one.

A high probability is not a guarantee

TypeSafe markets Jev with calibrated probabilities. The claim behind that is that the reported values match the actual frequency of correct decisions.

The tests so far show, however, that these values should not be taken into your own business processes without checking.

It would be particularly problematic to set a general threshold such as 90 percent and automatically treat that as enough certainty.

Whether such a threshold makes sense depends on the concrete task, the quality of the data, and the consequences of a wrong decision.

A support request sent to the wrong team is annoying. A wrong payment approval can cause substantial damage.

Not every decision can be isolated

Jev's architecture is particularly suited to independent questions.

In complex situations, though, decisions often hang together. A model may have to consider several conditions, weigh information against each other, or resolve contradictions.

This is where simple classification methods reach their limits.

inovex's results show why this constraint has to be taken seriously: several answers that each look plausible do not automatically add up to a coherent overall decision.

Data protection and operating model still matter

For European companies there is also the question of where data are processed, and under what conditions.

According to the information published so far, Jev runs as a cloud service in the United States. TypeSafe offers contractual data-protection arrangements and says it does not use customer data for model training. A commitment not to store data is not, however, designed the same way for every usage plan.

Before production use, that requires a review of the actual data flows, contract terms, and safeguards.

Local alternatives can have advantages here, but they also have to be assessed for security, maintenance effort, and capability.

Especially in hiring, credit decisions, or other legally sensitive uses, technical probabilities alone are not enough. Depending on the case, additional requirements apply, for example from the European AI Act.

How companies can start in a useful way

Anyone who wants to test the potential should not start by picking a particular model.

It is better to look first for a process in which similar classifications happen regularly.

Suitable tasks are ones where the possible results can be described clearly, historical example data exist, and errors do not at first have serious consequences.

A realistic start could look like this:

1. Identify recurring decisions. Where are messages, cases, or documents regularly classified by hand?
2. Collect example data. 50 to 100 real cases that have already been correctly labelled can be enough for a first functional test. For robust conclusions and production thresholds, many more data are needed, depending on the task.
3. Make the decision questions precise. Instead of asking for one overall score, describe individual criteria.
4. Compare different approaches. A decision model should be tested against the existing solution, a small language model, and, where useful, classic rules.
5. Run in parallel first. Before decisions are executed automatically, hit rate, misclassifications, response times, and costs should be measured under realistic conditions.

What matters is not whether a model looks especially fast or cheap on a product page. What matters is whether it delivers reliable results on your own data, and whether that actually reduces handling work.

Conclusion: a new model class, but not a shortcut to full automation

With Jev and the OpenAI Decisions API, a previously rather technical part of AI automation is getting new attention: the fast classification of unstructured information.

That several approaches appeared within a few weeks is remarkable. It shows that the split between generative language processing and specialised AI decisions is gaining weight as a field of its own.

How large the practical advantage will be is still open.

The available tests are limited, the models differ technically, and the quality of their probabilities has to be checked in the specific application. Data protection, integration, and long-term operating costs also play a role.

For SMEs, the opportunity therefore sits less in a particular product than in a basic architectural idea: Not every step in an automated process needs the same kind of intelligence.

Some tasks need a capable language model, others a simple business rule. And for the many small classifications in between, specialised decision models could become a useful addition.

Whether you end up using Jev, OpenAI's Decisions API, or a self-hosted model is secondary at first.

The more important question is where such decisions actually occur in your own company, and when automating them produces a measurable benefit.

We help companies identify suitable processes, compare technical options, and assess the actual value against real data.

Book a call

Sources and further reading

Vendors and technical documentation

• TypeSafe AI, Jev and System One Models: product introduction, operating principle, and vendor figures.
• OpenAI, Decisions API: official documentation of the interface published in October 2026.

Tests and independent assessments

• Nicolas Werner and Ivan Herreros Alonso, inovex: TypeSafe AI Jev im Test, 29 September 2026: own experiments, comparison measurements, critique of probability scores, and an overview of open models.

Video and application examples

• Julian Ivanov: Jev, Das kann das KI-Modell wirklich (10 Use Cases), YouTube, 22 September 2026: concrete examples of possible use cases.

Editorial note: Performance and price figures refer to October 2026. Vendor figures, published practical tests, and the application recommendations we derive from them are distinguished accordingly in this article.