JEV: How TypeSafe AI Is Rethinking AI Automation with “System One Models”

The triumph of language models brought a new assumption to light: the bigger and smarter an LLM, the more can be automated with it. A new AI lab is calling exactly that into question. With Jev, TypeSafe AI is launching the first model of a new class: not another chatbot, but a “System One Model” that writes no texts and instead delivers calibrated decisions that software can process directly. What is behind this approach, how does it differ from classic language models, and what do the numbers really say?

Introduction

Since the success of ChatGPT, a simple equation has held: the bigger and smarter the language model, the more tasks it can automate. The American AI lab TypeSafe AI is now questioning this assumption. On September 15, 2026, the company presented Jev, its first model of a new model class it calls System One Models, built not for dialogues with humans but for fast, structured decisions inside software. The following article explains what Jev is, how it works and what it is meant for, based on TypeSafe AI’s official announcement.

Further below, as a small extra, there is even a practical test with a local AI on a laptop, in other words Jev-style AI on your own hardware. For this, an open-source model was used that came onto the market shortly after the launch of Jev.

The starting question: why is so little automated despite superintelligent chat models?

Diogo Almeida, founder of TypeSafe and previously involved in the development of ChatGPT at OpenAI, describes exactly this observation in his announcement: language models have been impressively capable in chat for years, yet the broad breakthrough in automating business processes has not happened. His thesis: large language models (LLMs) are optimized for dialogues with humans, not for use as a building block inside software.

Classic LLMs generate their answers as text, token by token, each depending on the previous token. This makes them enormously flexible: they can write prose, generate code or answer questions. For use in software, however, this principle brings three problems:

• The output is a string that must first be parsed and validated before programs can use it.
• There is always a risk that the model “goes off track”, for example through hallucinations or unexpected formats.
• Sequential generation takes time: with leading models, the response time typically ranges from a few seconds to several minutes. That is acceptable for a conversation with a human, but as a building block in a software chain with latency requirements it quickly becomes a bottleneck.

This is exactly where TypeSafe comes in.

What is a “System One Model”?

The name is a deliberate nod to Daniel Kahneman’s book Thinking, Fast and Slow. Kahneman distinguishes between “System 1”, fast, intuitive thinking, and “System 2”, slow, deliberate reasoning. TypeSafe transfers this metaphor to AI models:

While today’s LLMs with their long chains of thought resemble the deliberate “System 2”, System One Models are meant to take over the fast, intuitive decisions that constantly arise in software. This is comparable to countless small “if-then” switches that so far had to be either hard-coded or laboriously made by slow LLMs.

The distinction between input and output is important here:

• Input: As with LLMs, unstructured data such as text, but with System One Models the focus is on structured program state rather than on ongoing chat messages.
• Output: No freely generated strings, but type-safe, structured values whose possible forms are defined in advance. Every answer is additionally delivered with a calibrated probability or confidence value.

TypeSafe boils the concept down to a formula: Jev is essentially a “function call with frontier intelligence”: unstructured state goes in, a typed, probabilistic decision comes out.

The technical basis: new architecture, parallel sampling, new training

To reach this goal, TypeSafe says it has developed a completely new technical foundation, consisting of three components:

1. A new model architecture designed from the ground up for structured decisions instead of text generation.

2. A parallel sampler. While classic LLMs generate their output token by token, Jev computes all possible answers in parallel in a single request. This is considerably more hardware-efficient and one of the main reasons for the enormous speed advantage.

3. A new training method called “Reinforcement Learning for Calibrated Decisions” (RLCD). Classic LLMs are mostly trained with RLHF (reinforcement learning from human feedback) or RLVR (reinforcement learning with verifiable rewards), which means they are optimized to produce answers that humans prefer or that can be verified automatically. RLCD instead optimizes directly for calibrated decisions: the model should not only give the right answer but also honestly assess how sure it is about it.

This calibration is a central selling point for TypeSafe. The idea behind it: a model that solves a task correctly 95 percent of the time but does not signal when it belongs to the remaining 5 percent is hard to automate reliably, because you never know when to trust the result. Jev is supposed to deliver with every output how certain the answer is, and to be genuinely consistent in doing so: a higher stated confidence should actually correspond to higher accuracy.

Jev compared directly with classic LLMs

In its announcement, TypeSafe presents a detailed comparison table between “existing LLMs” and “System One + Jev”. The key points in summary:

Caution is advised with the cost figures: these are prices that TypeSafe sets itself and that, as the company itself admits, may be (still) subsidized. Whether the pricing model is sustainable in the long run can naturally only be judged over time.

What is new and revolutionary?

Jev has several characteristics that caused a revolution on the market.

Jev’s inference costs, in other words its usage costs, are an order of magnitude lower than those of the other frontier models from OpenAI, Anthropic and Google. Jev also delivers a guaranteed response structure, that is, a well-defined output format.

At the same time, Jev’s response speed is in the range of milliseconds, instead of seconds as with ChatGPT & Co. This opens up entirely new possibilities, especially for AI agents.

It is important that the answer quality of Jev is perceived as just as good as that of the best AI language models currently available.

For example, classification tasks that require a very large number of AI calls can be handled extremely economically and quickly. Controlling real-time applications such as games or apps is also better possible this way.

By now, only a few days after the launch of Jev, there are open-source models with the same response behavior. One model claims to even outperform Jev in benchmarks. The speed would probably be similarly high on top-end hardware. With local AI, the costs are in any case zero once the hardware has been purchased or the flat-rate rental for the AI server has been paid. Data security is at its maximum with local AI, which cannot be said of Jev.

Answers like Jev’s would also have been possible, or still are possible, with conventional LLMs, but with the following limitations:

• The response speed is typically slower.
• The answer quality is typically somewhat worse.
• The output format is not 100% guaranteed, although it is usually correct well over 90% of the time.

Real test with local AI

On consumer hardware (AI laptop, about 3 years old), the following classification task was given to a local AI model similar to Jev:

In the program, this question looks like this:

This question was put to the local model 100 times in a row and answered 100 times. On average, each answer was available after 56 milliseconds:

The model decided: with 95.7%, the return is eligible.

So the answer was very good and available very quickly. To validate the result, the test was run again, this time again 100 times but with a different question each time. The questions were even varied so that the purchase date sometimes falls before and sometimes after the return period, and the item was sometimes unopened, sometimes damaged, and so on. The response speed was identical!

By the way, more than two answer options can also be specified. For example:

• Not eligible because returned too late.
• Not eligible because item condition is too poor.
• Not eligible because returned too late and because item condition is too poor.
• Unsure.
• Eligible.

In 100 runs with changed questions (= buyer returned the item after X days in condition Y, with X and Y varying), it also becomes clear right away that precise questions matter: is an item taken back if it is returned within the return period but damaged?

The results obtained with local AI can be seen as an excerpt (14 of 100) in the image above. The results were assessed by a frontier model. As you can see, everything is correct here, with very good response speed at the same time (on a laptop!).

The evidence presented: what TypeSafe shows and what remains open

What is remarkable about the announcement is that TypeSafe itself stresses that “extraordinary claims require extraordinary evidence” and tries to put its numbers in context instead of presenting them without comment. For this, TypeSafe introduced a learning method called Reinforcement Learning for Calibrated Decisions (RLCD).

Three categories of evidence are named:

Speed and cost per request can easily be verified yourself, according to TypeSafe, albeit with the caveat that the published measurements come from the US west coast, where the company’s own service is hosted.

No type errors are said to be mathematically guaranteed because the output format is enforced by the schema itself. A single counterexample would refute the claim, which is why TypeSafe speaks of a hard, verifiable guarantee here.

Workflow benchmarks: To measure how well a model actually works inside software, TypeSafe has developed its own evaluation approach. Instead of testing against a fixed “model solution”, it compares the predictions of different models with the average of particularly large reference models (in this case two current top models from OpenAI and Anthropic) on the same decision flows defined in advance in code. According to these tests, Jev is said to be around 193.6 times faster and 444.6 times cheaper than the reference models at comparable quality. However, TypeSafe itself points out that this is more of an upper bound of what can be expected in practice.

For the hallucination rate, TypeSafe compares its own guaranteed error-free schema adherence with figures for common LLMs collected via the OpenRouter service. Here too, the company admits possible biases, for example because more complex requests tend to be routed to more capable models.

Overall, the announcement is transparent in several places about where possible biases in its own comparison data might lie, for example through the choice of reference models or because the test scenarios were created by its own team. This is unusually open for a product announcement, but it does not change the fact that these are company-owned figures that have not yet been independently reproduced.

The three call modes of Jev in practice

Jev does not treat “one” kind of request. Instead it comes with three fixed basic forms onto which practically every automatable decision can be mapped. A look at each of the three with a concrete example makes the difference tangible.

Choice: select one option from a set

Choice is used whenever exactly one of several clearly named options is to be selected, for example when asking which team should handle an incoming support ticket:

Choice(
    instructions="Which team should handle this?",
    criteria={
        "billing": "Payment or subscription problems",
        "technical": "Bugs or integration problems",
        "sales": "Questions about prices or terms",
    },
)

Jev returns not only the chosen option but its own probability for each of the up to 255 possible options, in the example about 72% for “billing”, 21% for “technical” and 7% for “sales”. The actual selection follows from this, including a confidence value for the entire decision.

Score: place a position on a scale

Not every decision is a choice between discrete categories, as some things lie on a spectrum. For this case there is Score, with two to ten named levels as anchor points:

Score(
    instructions="How angry does the customer seem?",
    criteria=[
        "Friendly and justified",
        "Calm, just states the facts",
        "Friendly, but incorrect",
        "Frustrated, but factual",
        "Very angry, strong wording",
    ],
)

What is special: the returned value does not have to land exactly on one of the levels. A result such as 1.74 is perfectly normal and means “between frustrated and very angry, but closer to the former”, a finer resolution than the named levels alone would offer.

Noul: yes or no as a pure probability

The third mode is the simplest: Noul answers a single yes/no question, but not as a hard “true” or “false”, rather as a number between 0 and 1:

Noul(instructions="Does the message seem urgent or time-critical?")

An output of 0.87 means “probably yes, with high confidence”, with no separate confidence field, because the probability itself already carries the certainty of the assessment. For simple pre-checks or filter rules in existing software, this is often exactly the granularity that is needed, no more and no less.

Typical use cases for Jev

Four main fields of use can be derived from the announcement, for which Jev was designed:

• AI-powered workflows (“intelligent if-then rules”): Structured decisions can be built directly into existing software to classify, route, score or branch, wherever classically programmed rules would be too rigid.
• Processing large amounts of data (map-reduce): Large amounts of data are meant to be turned efficiently into features and insights.
• Real-time applications: According to TypeSafe, response times in the range of 100 milliseconds allow AI decisions where user experience and speed are decisive.
• Safeguarding other AI systems: Jev is meant to be suitable for evaluating or checking prompts, reasoning chains or outputs of other LLMs, or for use as a protective layer against jailbreak attempts.

To illustrate this, TypeSafe has published two playful demos: an AI-controlled bot that plays the classic first-person shooter Doom in real time, as a demonstration of how quickly the model can react to changing game states, and a “wikiracing” experiment in which an AI has to navigate from a start page to a given target page purely by clicking Wikipedia links. Both demos are mainly meant to show how speed and the avoidance of hallucinations reinforce each other across many consecutive decisions.

Where does the name “Jev” come from?

TypeSafe also explains this in its FAQ: the name goes back to the British economist William Stanley Jevons, known for the “Jevons paradox” named after him. It states that using a resource more efficiently, historically coal after the improvement of the steam engine, can paradoxically lead not to less but to more total consumption, because the increased efficiency makes new applications economical in the first place. TypeSafe expects machine intelligence to develop similarly: every order of magnitude by which the cost of AI decisions falls is meant to open up new use cases that were previously uneconomical.

Assessment: what does this mean for the AI landscape?

The idea behind System One Models hits a sore spot in the current AI debate: the leap from impressive chat answers to reliable, everyday automation has indeed been smaller so far than the sheer size of the models would suggest. Instead of trying to turn language models into reliable decision systems through prompt engineering and ever more elaborate agent architectures, TypeSafe takes the opposite route: a specialized model built from the start for exactly this purpose, at the expense of the ability to generate free text.

Whether this approach will prevail is open from today’s perspective. A final verdict requires independent tests and experience from productive use that go beyond TypeSafe’s in-house benchmarks, however unusually transparently commented. In any case, the basic idea remains remarkable: not every AI problem needs the largest possible, general-purpose language model. For many of the small, frequent decisions that arise millions of times a day in software, a fast, calibrated, specialized model like Jev could be the more pragmatic path.

Conclusion: Jev is not another chat model but an attempt to embed AI decisions in software the way you call a function today: fast, type-safe and with an honest assessment of its own uncertainty. Whether this approach actually becomes a new, independent model class, as TypeSafe hopes, will become clear in the coming months, when the first developers outside the company gain their own experience with Jev.

Above all, open-source models that work exactly like Jev will certainly be brought to market, with the subtle difference that no data has to be sent anywhere. Incidentally, companies with relevant use cases can already build such models for themselves today (or have been able to for years) (pre-training).