System One Models: When AI Needs to Make Decisions, Not Write Text
The launch of Jev has drawn considerable attention to a category TypeSafe AI calls “System One Models”. Behind the new label is a familiar idea: AI models designed to classify, score and make constrained decisions rather than generate text. The significance is therefore less about inventing an entirely new type of model and more about what becomes possible when classifiers are flexible, fast and general enough to serve as a dedicated intelligence layer in modern software.
On September 15, TypeSafe AI launched Jev and introduced the term System One Models. While a traditional LLM such as GPT or Claude generates sequences of tokens, Jev is designed to take a state and a set of predefined questions and return typed decisions with probabilities and confidence scores.
TypeSafe describes Jev as a model built for “decisions inside software” rather than communication with humans. Instead of generating text, it can choose between predefined categories, assign scores on a scale or estimate the probability of a binary outcome.
So are System One Models essentially just classifiers?
The short answer is that the comparison is technically reasonable, but it does not tell the whole story.
Classification is not new
Machine learning models were classifying text, images and other data long before the current wave of generative AI.
If an organisation needs to determine whether an incoming email relates to billing, support or sales, that is a classic classification problem. The same applies to questions such as:
- Which team should handle this case?
- Does this document contain a particular type of risk?
- Is this transaction suspicious?
- Should this AI agent continue, retry or escalate?
- Which of five possible actions should the system take?
Historically, you would often train or fine-tune a classifier specifically for the task. This can produce extremely fast and inexpensive models, but usually requires labelled data and a relatively fixed definition of the problem.
LLMs changed that trade-off. Suddenly, a new classification task could be described in natural language and handled reasonably well without training a new model.
The downside is that we have also started using very large generative models for tasks where generation is not actually required.
We might send a support ticket through a frontier LLM with billions of parameters simply to receive:
billing
It works. Architecturally, however, it is often excessive.
System One Models sit between traditional classifiers and LLMs
This is where models such as Jev become useful.
Jev combines some of the strengths of traditional classifiers with some of the flexibility we have come to expect from LLMs.
Instead of generating a JSON object token by token, the developer defines the allowed output types in advance. Jev supports, among other things, categorical choices, ordinal scoring and yes/no probabilities. Multiple questions can also be evaluated against the same state in parallel. [1]
In practical terms, the model behaves more like a probabilistic function:
state + questions → decisions + probabilities
That is a materially different interface from:
prompt → generated text
TypeSafe lists a price of $0.042 per million input tokens and end-to-end latency of roughly 70-500 ms. The company also publishes its own benchmarks showing Jev to be up to 193.6 times faster and 444.6 times cheaper than the LLM-based alternatives included in its tests for selected System One workflows. TypeSafe itself notes that these figures are likely to represent the upper end of what users should expect in practice. [1]
That qualification matters. The category is still very new, and much of the available evidence currently comes from the vendor itself. There is not yet enough independent benchmarking to treat the most striking performance claims as general properties of System One Models.
“Zero hallucinations” needs a precise definition
TypeSafe also describes Jev using the phrase “zero hallucinations”.
That makes sense in a specific technical sense: if a model is only allowed to return a value from a predefined output space, it cannot suddenly invent a new JSON property, return an invalid enum or start writing an explanation in the middle of an API response.
The schema can be guaranteed.
Correctness cannot.
A classifier can still choose the wrong category. A probability estimate can be poorly calibrated. And a model can be highly confident in an incorrect decision.
The more useful property is therefore not that the model cannot be wrong. It is that the types of error become easier to constrain and probabilities can be incorporated directly into application logic.
A system could, for example, automate decisions above a given confidence threshold while sending uncertain cases to a larger LLM or a human reviewer.
“The schema can be guaranteed. Correctness cannot.”
For enterprise software, that is often considerably more valuable than a broad promise of “no hallucinations”.
Laya makes the architecture easier to inspect
Open-source alternatives have already started to appear. One of the more interesting examples is Laya from ConvAI Innovations.
Laya is released under the Apache 2.0 licence and makes the underlying architecture considerably more transparent. Its English-language model combines a ModernBERT-large encoder of approximately 395 million parameters with a decision head, bringing the total model size to roughly 421 million parameters. [2]
Each possible decision is scored directly and returned as a probability distribution. There is no autoregressive text generation.
This is a useful reminder that a frontier LLM is not necessarily required for this class of problem.
Laya can also run locally. The project's own benchmarks report roughly 33-40 ms for a single decision on a Tesla T4, with higher throughput when batching requests. These are local model measurements and are therefore not directly comparable with Jev's hosted API latency, but they illustrate what relatively small non-autoregressive models can achieve. [3]
For many organisations, however, another property of Laya may prove more important than raw latency: it can be fine-tuned.
Domain-specific System One Models may be more valuable than general-purpose ones
Laya's own results provide a useful illustration of both the potential and the limitations of this approach.
The project documents relatively weak zero-shot performance from its general base checkpoints on its typed-decisions benchmark. Performance improves significantly after fine-tuning on the relevant training distribution.
Its developers therefore position Laya as a foundation that should be specialised rather than as a strong general-purpose zero-shot decision engine. [3]
For enterprises, this may matter more than which model tops a particular benchmark.
In many organisations, the real question is not:
“Which general-purpose AI model knows the most about the world?”
The real question is rather:
“Can the model make this specific type of decision consistently inside our business process?”
Consider a model specialised for an institutional investor's investment processes, an insurer's claims workflow, a bank's compliance processes or a public authority's document categories.
In these settings, a relatively small local model with organisation-specific evals, calibration and domain-specific fine-tuning may be more useful than a much larger general-purpose model.
It can also support on-premise deployment, tighter control over model versions and a different approach to data sovereignty than relying exclusively on an external API.
Laya's current benchmarks should, however, be interpreted with the same caution as Jev's. Comparisons between the two have not been conducted in a shared, controlled benchmark setup, and the Laya project itself notes differences in prompts, sample sizes and measurement methodology. There is therefore no solid basis for concluding that Laya is generally “better than Jev”. [3]
The broader shift is in the architecture around the models
The wider implication of the System One category is a move away from one assumption in particular.
It is the assumption that one large LLM should act as the intelligence layer for an entire application.
A more mature AI architecture may instead combine several types of components:
- Deterministic software handles rules that can be specified precisely.
- Decision models handle fast probabilistic tasks such as routing, classification, scoring and guardrails.
- Generative and reasoning models are used when a task requires analysis, synthesis, planning or the creation of new content.
- Humans handle cases where the cost of an error is high or model confidence is insufficient.
This is less spectacular than the idea of a fully autonomous AI agent.
It is also much closer to how robust enterprise software is actually built.
AI agents need a low-cost decision layer
This architecture becomes particularly relevant as AI agents gain access to more tools and are given greater autonomy.
An agent has to make a constant stream of small decisions:
Should I call this tool? Is the result good enough? Which model should handle the next task? Is this output safe? Does the result match the user's intent? Should I retry? Should a human be involved?
In many agentic systems today, each of these decisions triggers another LLM call.
When every decision requires relatively expensive inference and adds seconds of latency, the cost compounds quickly across a workflow.
A smaller decision model can potentially act as a control layer around larger models.
That changes the economics of the system.
The smaller model does not have to replace the frontier model. It allows the frontier model to be reserved for the problems that genuinely require its broader capabilities.
The relevant question is not whether Jev is “just” a classifier
From a technical perspective, describing Jev as a classifier is not unreasonable.
“System One Model” is currently TypeSafe's term for the category rather than an established scientific standard. Classification, probability estimation, model calibration and non-autoregressive encoders all predate Jev by many years.
Technology, however, does not only become important when someone invents a fundamentally new mathematical technique.
Sometimes the shift happens when existing techniques are combined in a way that changes what can be built in practice.
Modern chat models are themselves, to a large extent, an example of that dynamic.
What is worth following with Jev, Laya and the models that come after them is therefore not the name System One.
It is whether they establish a useful new intelligence primitive between deterministic code and generative LLMs: models that are inexpensive enough to call continuously, fast enough to sit directly in the application flow and reliable enough for their probability estimates to become a meaningful part of the software architecture.
If that happens, it could matter more to many enterprise AI systems than another incremental improvement in the next frontier LLM.
For businesses, the broader implication is straightforward: better AI systems will not necessarily come from using larger models everywhere.
They will increasingly come from using the right model for the right part of the problem.
About the author
Mikkel Hempel is Co-founder at Capacit and works at the intersection of emerging AI capabilities, technology architecture and their practical application in businesses and large organisations.