Jev and System One Models: Does Every Decision Need an LLM?

For a while now, it seems like every problem involving natural language interpretation gets solved the same way: we call an LLM, hand it a prompt and ask it to return structured JSON so we can easily handle the response. Need to classify an email? That's what we do. Prioritize an incident? Same thing. Decide which team a ticket should go to? More of the same.

I'm not saying that's wrong. In fact, today's generative models are perfectly capable of handling many of these tasks, and they come with fairly powerful structured-output mechanisms. But there's a question I think is worth asking: does it make sense to use a model designed to generate language when all we need is to make a decision among known options?

That's precisely the proposition behind Jev, the first public model from a new family that TypeSafe calls System One Models. Other posts about Jev have already been written, but in this one, besides explaining what it is and why I find it interesting from a software architecture point of view, I'm also sharing, as usual, a repository with a small PoC so you can play with Jev yourself.

What is Jev? Where does it come from and who's behind it?

On September 15, 2026, TypeSafe AI introduced Jev, the first public model in its System One Models family.

The company is led by Diogo Almeida, TypeSafe's founder and a former OpenAI researcher. The starting idea, laid out in the launch announcement, is fairly simple: generative models have reached an extraordinary level at conversing, writing, coding and reasoning, but a good part of enterprise automation needs decisions that other programs can consume, not text that a person has to interpret.
That gives rise to a different proposal: building specialized models that take a context and answer well-defined questions through typed outputs.

The name System One refers to System 1 as described by Daniel Kahneman in Thinking, Fast and Slow: a fast, intuitive way of thinking, as opposed to the more deliberate System 2. The reference helps explain TypeSafe's intent, but it doesn't mean Jev literally reproduces how human cognition works.

And why Jev? According to TypeSafe, the name is a tribute to William Stanley Jevons, known, among other things, for the paradox that bears his name: when a technology becomes more efficient, its total consumption can go up instead of down. Applied to AI, the hypothesis is that making each decision radically cheaper will let us bring intelligence into many more processes.

I think this last idea is especially interesting: it may not be only about replacing an LLM with something cheaper, but about making viable decisions we don't even consider automating today.

What are its key features?

To understand Jev, you need to shift your mindset slightly. Instead of asking it to "read this text and answer with a JSON," we define two elements:

• state: the context we want to decide on. It can contain text or a data structure.
• questions: the questions it has to resolve, with the answer type and the criteria defined beforehand.

The application sets the space of possible answers; Jev evaluates the context and returns its decisions.

Three primitives: Choice, Score and Noul

The System One interface is built around three primitives:

You can review the behavior and output fields in the official System One documentation. One important detail: Noul is not simply a boolean, but a numeric signal that we can interpret using a threshold defined by our application. Likewise, a Score can be continuous, even if the criteria are organized in levels.

Multiple decisions in a single call

Another especially useful feature is the ability to ask several questions about the same context. Imagine we receive this alert:

The payments service is down for all customers. The logs show database connection pool exhaustion and there are no signs of unauthorized access.

In a single request, we could ask for the priority (a Score from 0 to 4), the security risk (a Noul) and the responsible team (a Choice among BACKEND, PLATFORM and SECURITY). The result would look something like this (a conceptual example, not a real API response):

{
  "priority": 4,
  "security_risk": 0.03,
  "team": "BACKEND"
}

In other words, we don't need three calls or an explanatory text to get all three decisions. The code that consumes the result can determine what to do next.

Typed responses, uncertainty and efficiency

TypeSafe puts the spotlight on three other characteristics:

• A known output contract: the questions and their valid values are defined in advance. This reduces the integration problems that come from receiving responses that don't respect the contract.
• Uncertainty signals: depending on the primitive, the model provides probabilistic values, distributions or confidence. These are not guarantees of correctness and need to be validated with real data.
• Optimized for decisions: Jev doesn't write out an explanation word by word. According to its creators, this difference substantially reduces cost and response time on the tasks it's designed for.

In its official launch post, TypeSafe reported indicative latencies of 70 to 500 ms and a public price of USD 0.042 per million input tokens, with no charge for output tokens. These are figures published by the vendor, not a promise of performance in every environment or a contractually guaranteed rate. Check the current terms before budgeting.

One last nuance: guaranteeing that a response respects the schema doesn't mean guaranteeing the decision is correct. A classifier can perfectly well return BILLING when the category we expected was OTHER.

How is it different from a traditional LLM?

A generative LLM is designed to produce content. Jev is designed to issue bounded decisions that other software can use directly.

This doesn't mean Claude, GPT or Gemini can't return structured results. They can, through tools, function calling or output schemas. The difference lies in the model's native goal and its interaction interface, not in the impossibility of getting JSON out of an LLM.

With an LLM, the response space is potentially open, even though, as I said, you can try to constrain it. With Jev, the response space is already defined by the questions themselves. Also, something we need to keep in mind is that Jev won't generate an explanation of its reasoning. An LLM can tell you what led it to that answer, and even point to the supporting quotes.

The main idea to keep in mind is that Jev doesn't have to compete head-on with LLMs or replace them. In a real architecture, the two can be perfectly complementary.

For example, an LLM can design a solution, draft a response or synthesize a document, while Jev can decide which flow to run, which category something belongs to, or whether an operation should be escalated to human review.

This echoes a fairly classic architecture principle: use each component for what it does best, and avoid adding capabilities the problem doesn't need. Heads-up: whenever we can use deterministic mechanisms, we should always go with them. They're simpler to implement, debug, test and deploy.

For which use cases can it be a good alternative to an LLM?

I think where it really has potential is in scenarios that meet conditions like these:

• They have lots of events or inputs
• They need repeatable decisions
• They have a known response space
• The goal is to reduce cost or latency.

Within those constraints we find cases like:

• Classification and routing: for example, determining whether an email is about billing, support or sales; sending tickets to the right team; classifying requests; or deciding which generative model to use for each task.
• Scoring and prioritization: for example, rating how mature a sales opportunity is, ranking incidents by impact and urgency, or identifying requests that deserve priority review.
• Semantic guardrails: for example, detecting whether an instruction seems to be trying to bypass an approval or break a rule expressed in natural language. The detection would be an additional signal; it doesn't replace deterministic security controls.
• Content verification and agent flows: for example, assessing whether a response meets certain criteria or should be escalated to a human; adding bounded decision points within broader flows.
• Multiple decisions on the same event: for example, when an incident comes in, determining priority, security risk and responsible team all at once.

From my architect's point of view, it's essentially a semantic decision component/service that lives alongside business rules, APIs, events and generative models. It's needed in scenarios where a conventional if/else falls short but a full LLM feels like overkill.

That said, it doesn't replace deterministic rules when we can fully express and verify the decision in code.

When might it not be a good fit?

Sometimes, when we analyze a new technology, we focus so much on its advantages that we stop looking at the other side. In this case, I think it pays to be especially careful. For example:

• Content generation
• Explainability requirements
• Sovereignty and control

Let's look at these scenarios in more detail.

Content generation

We need to be clear that Jev is not a generative model. So if we need to write a report, develop an architecture, explain technical alternatives, write code, summarize a document or hold a conversation, Jev is not the right model to produce that artifact.

It could take part in decisions within the flow, but generation would still be up to an LLM or another specialized system.

Explainability is a must

Jev doesn't provide an explanation of why it chose a category or assigned a score. We can get signals associated with the decision, but not a verifiable description of its internal reasoning.

Think of an email that Jev classifies as BILLING when an analyst would consider it OTHER. We can see what it returned and compare it with the expected label. What we can't do is ask it to spell out its internal reasons for picking that option.

Explainability in AI is a very important requirement in certain contexts, so it's a point to weigh carefully.

An alternative: Jev decides and an LLM explains

We can set up a hybrid architecture:

1. Jev makes the decision based on the available context.
2. The application returns that decision to the consumer.
3. An event is published or a task is queued, identified by the decision ID.
4. A low-cost generative model, such as Claude Haiku, receives the context, the decision and the available signals, and writes a justification based on the evidence in the text.
5. The explanation is stored alongside the decision for later consultation.

This hybrid model only works if the explanation isn't needed to move forward, since we can generate it asynchronously and keep the second model's latency off the critical path. In this case, we don't eliminate the explanation's latency, we decouple it from the decision's latency. On the other hand, we take on extra cost, an additional dependency and the need to manage queues, retries and errors.

Heads-up, there's an even more important limitation: the justification written by the LLM (e.g., Haiku) would be a post-hoc explanation, not Jev's internal reasoning. It can be useful for interpreting the evidence and making review easier, but it could also construct an argument that isn't faithful to the real reason behind the prediction.

That's why, in regulated or critical processes that demand an explanation validated before acting, we can't simply push it to the background and consider the requirement met.

When we need absolute control over deployment or data sovereignty

As I mentioned earlier, as of this writing, if we need to run the model without external connectivity, inside our own infrastructure or in a specific contractual location that TypeSafe can't offer, Jev may not meet the requirements, no matter how well it classifies.

Let's talk maturity: is it ready for production?

Jev is a very recent product: its public launch happened in September 2026. Obviously, we're not talking about a technology with years of widespread adoption, but about a proposal that's evolving fast.

That doesn't mean it can't be used in production. TypeSafe has already published the Jack & Jill case, a hiring platform that, by its own account, replaced a Gemini model with Jev in a candidate matching stage. The case reports 88% lower cost and shorter processing time while maintaining comparable quality on that task. It's a customer case published by the vendor: interesting as a reference, but it isn't an independent certification, and it doesn't mean those savings carry over to other systems.

TypeSafe keeps releasing versions and features. For example, in the Jev 1.14 announcement, it distinguishes the capabilities it considers sufficiently proven from experimental ones, such as certain multimodal or extended-context options.

But does it come with enterprise support?

There's a nuance here that I think deserves its own section, especially if we're thinking about bringing Jev into a large and/or very traditional company.

We can't say that TypeSafe has no enterprise support, since it has a dedicated enterprise page with a sales contact, the ability to request higher usage limits, and references to options like zero data retention. However, having a sales channel is not the same as having all the enterprise guarantees confirmed that we'd demand before a critical adoption:

• Contractual SLA
• 24×7 support
• Incident response times
• Private deployment
• Specific compliance
• Portability
• Continuity commitments

It's true that TypeSafe is moving in this direction. In the announcement of its funding round on October 9, 2026, TypeSafe explicitly says it will add more enterprise features. That's a positive sign of investment and product direction, but it also indicates that the offering is still evolving and that they know there's some maturity missing for an enterprise product.

In my opinion, right now, in an enterprise context, I'd use Jev without too many reservations in a controlled PoC, but I'd make the move to critical production conditional on a commercial, legal, security and operations review. It's not enough for the model to be fast and to get our dataset right.

If the service goes down on a Saturday night, who do we call? What recovery time are we guaranteed? What do we do if the API terms change? What data can they process, and in which region? Those answers need to be in writing, not inferred from a marketing page.

My take is that Jev deserves to be evaluated for production in bounded cases, but it requires special attention to its operational maturity and contractual guarantees. Before adopting it for a critical function, I'd review at least the following:

• Quality on our domain: a representative dataset, reviewed labels, and tests with ambiguous and out-of-distribution inputs.
• Versioning: pin versions when stability matters and rerun evaluations before migrating.
• Failure behavior: timeouts, rate limits, circuit breakers and fallbacks.
• Security and privacy: classification of the data we send, residency, retention and data processing agreements.
• Observability: latency, costs, technical errors, decision errors and trends over time.
• Business control: thresholds, human approvals and deterministic rules before risky actions.
• Vendor guarantees: SLA, support, limits and service continuity.

It's worth remembering that a probabilistic decision should never automatically become an authorization. If Jev says an action looks safe, our system is still responsible for checking permissions, policies and constraints.

Another important point: is it available as a native model from the big providers?

As of this writing, I haven't found official documentation confirming Jev as a selectable, natively managed model on Amazon, Google or Azure… So I wouldn't present it as a capability available on those platforms.

If an organization wants to use it from one of those clouds, the scenario backed by public documentation is consuming the TypeSafe API from the application. Any specific private deployment or third-party distribution agreement needs to be confirmed with the vendor.

Can it run locally?

I haven't found that it can run locally either. This limitation matters for organizations with strict isolation, data sovereignty or fully on-premises deployment requirements.

In short: we can develop and deploy our software wherever we want, but Jev's inference, according to the documented public offering, depends on TypeSafe's service.

What if we didn't really need Jev?

Text classification, scoring and anomaly detection existed long before ChatGPT. So depending on the context, we may need neither Jev nor an LLM. Take the email classification case. A classic alternative would be training a supervised model on labeled messages. We can start with TF-IDF and logistic regression, move on to an SVM, combine embeddings with a classifier, or fine-tune an encoder model like ModernBERT. They don't all require the same amount of data, hardware or operational effort.

Another option is managed solutions: Amazon Comprehend Custom Classification lets you train classifiers with your own categories, and Google Cloud Document AI Custom Classifier offers document classification options, from pretrained models to custom training. In the open source world, approaches like SetFit let you fine-tune classifiers with relatively few examples and embedding models.

So the comparison shouldn't be limited to Jev versus an LLM:

There's no universal winner. If we have millions of well-labeled historical emails and the classes barely change, a specialized classifier deployed on our own infrastructure could be an excellent option. If, on the other hand, we're exploring a new process, have few labels and need to change the criteria often, Jev can greatly reduce the initial friction.

It also wouldn't be right to claim that traditional ML is necessarily slower to develop or more expensive to run in every scenario. AutoML tools, pretrained models and few-shot approaches have lowered that barrier a lot. And there are supervised models that let you inspect which variables influenced a prediction, although that alone doesn't guarantee a causal explanation either.

As I said earlier, we should always remember the architecture principle of using each component for what it does best. In this era of big, fast-moving change, architecture work when designing solutions matters more than ever: what do we really need? A traditional classifier trained on our data, an LLM with structured output, or a decisions API like Jev or Decisions API?

The answer will depend on quality, cost, latency, explainability, privacy, maturity and deployment options.

Is the industry reacting?

The industry is moving toward increasingly structured outputs, smaller models and specialized services, although not everyone is taking the same path.

Laya, the open source competitor

Another project worth knowing about is Laya, driven by Convai Innovations. Its approach is very similar to Jev's: making semantic decisions about a context through bounded questions, instead of generating free text. In fact, it uses the same primitives: Choice, Score and Noul, and it can resolve several questions in a single evaluation.

The most interesting difference is the distribution model. Laya is an open source project, with publicly available code and weights and an Apache 2.0 license declared in its repository. That means you can download the model and run it locally, inside a Docker container or on your own infrastructure, rather than necessarily depending on an external inference service.

From an enterprise, control and sovereignty standpoint, this can matter quite a bit, since we can control where data is processed, which version we run and how we integrate the model. Picture an insurer that needs to classify documents or prioritize incidents and can't send certain data to a third-party API. Laya opens up the possibility of deploying that component within its own network boundaries.

But this isn't "free," because open source doesn't equal an enterprise-ready production solution. Like any other deployment, we have to account for and analyze the costs of infrastructure, energy, staff and so on; manage capacity, scaling and monitoring; and maintain the model and any new versions of it. Operational responsibility and support fall on the company itself, and since it's an open source project, we have no enterprise support and no guarantee that it will be maintained over time (though it could be interesting to take part as contributors).

We also shouldn't forget decision quality. We'd need to test its results against our own dataset, including ambiguous texts, different languages, category distributions and cases where escalating to human review makes sense. Accuracy, calibration and error behavior matter more than whether it's open or proprietary.

In my opinion, Laya makes a lot of sense as a candidate for PoCs and for scenarios where local execution is a requirement, but for critical production I'd demand the same rigor as with Jev: representative testing, continuity guarantees, security controls and a clear support model.

OpenAI's Decisions API and GPT-6 Luna

According to OpenAI's official changelog, the Decisions API launched in beta on October 6, 2026, with the gpt-6-luna model. Decisions API is a dedicated interface for evaluating inputs and returning typed decisions, with bounded questions. Its approach is much closer to TypeSafe's System One.

The correspondence between concepts is striking, and the way you call it is similar to System One: you specify the model, the inputs and the questions/instructions. Both offerings let you work with bounded decisions and multiple questions about a context. OpenAI's documentation also describes decisions over text and images, and probability or confidence signals for certain types of answers.

OpenAI claims this API can be roughly ten times faster than using its Responses API for this kind of task. It's important to read that number correctly: it's a comparison published by OpenAI against another of its own APIs, not an independent measurement against Jev. Nor can we conclude from it that Luna is more accurate, faster or cheaper than Jev in our specific scenario.

Hands-on: Jev Decision Lab

As usual in my posts, I try not to leave things at the purely theoretical level, and I always try to back them up with something "practical."

In this case, I've put together the Jev Decision Lab repository. It's a PoC that compares Jev with Claude Haiku and Claude Sonnet on a set of situations where we can measure results. I've also included Laya so you can run it locally.

It's not meant to be a universal benchmark or to prove that Jev always wins. Its goal is to let you play with it and see when a bounded decision can be handled without a general-purpose generative model, and what happens to quality, cost and response time.

To make the PoC more guided and easy to use, I've included a series of use cases where the comparison makes sense:

The PoC also has two modes of use:

• Playground, where we can enter our own text, select providers and compare a single run.
• Test Scenarios, where we can run repeated batches against a reference dataset. The version of the project I use includes 30 scenarios per use case (210 in total), lets you select providers, repeat the tests and upload your own JSON dataset, which is validated before the process starts.

The repository has a README with the full instructions, a description of the use cases and implementation details.

Important: the dataset labels are examples prepared for the PoC, not an independently reviewed set. A 95% match with these labels doesn't equal "95% accuracy in production." Costs are estimates, and performance also depends on the network and on external services.

Conclusions

After reviewing TypeSafe's proposal and building the PoC, I'm left with a few takeaways.

• Generation isn't always required: as tends to happen with hype, we've normalized using LLMs for any natural language input, but some problems have a result that is simply a decision among known options. It's worth telling the two scenarios apart.
• Latency and cost are potential advantages, but you need to review the whole scenario: the figures published by TypeSafe are eye-catching and justify giving it a try, but the architecture decision has to rest on the scenario's requirements, on the dataset we actually handle, on latencies and on our required quality criteria.
• Explainability is a key factor in the decision: we can ask another model to write a justification, even asynchronously, but that doesn't turn the explanation into Jev's verifiable reasoning. In certain contexts, this difference is the "go" or "no-go" for Jev.
• Maturity, support and deployment model (and sovereignty) count in an enterprise environment: it's true that there are already real production cases with Jev, but it's a recent tool that depends on TypeSafe's offering. For organizations with strict sovereignty, operations or continuity requirements, the analysis doesn't end at model accuracy or the features listed by the vendor on its website. It also takes solid enterprise-grade capabilities.
• Let's not forget other alternatives like traditional ML: a good supervised classifier, or even conventional rules, may be the most reasonable solution. Before adding another API, we should measure those options too.

So instead of making our first question when designing a solution "which LLM do we use to solve this problem?", we should start by asking "what kind of intelligence does this problem really need?". If we need to generate, explain or design, an LLM makes a lot of sense. If we need to classify, prioritize or decide within defined limits, proposals like Jev open up an alternative worth exploring. And if the set is predictable and very well defined, let's go with deterministic solutions.