Jev and System 1 models: when AI stops writing and starts deciding

By Kike Gandia · AI & Security · 14 min read

There's an uncomfortable question worth asking before you read anything about Jev: how many of the calls your company makes to a language model today end in a one-word answer? Urgent or not urgent. Spam or legitimate. Critical, high, medium or low. Allow or block.

If the answer is "a lot", you're paying for text generation to get a classification. You're waiting seconds to receive a single token. And you're accepting that the token arrives with no reliable measure of how much confidence it deserves.

That's exactly what Jev goes after. And because the approach makes sense, an open alternative (Laya) has quickly appeared that you can deploy on your own infrastructure. Both are worth a careful look, and so are the numbers they advertise, under a magnifying glass.

What exactly Jev is

Jev is the first of what TypeSafe AI calls "System One models", a reference to the fast, intuitive thinking described by Daniel Kahneman. It launched on September 15, 2026 after roughly two years of development in stealth. The company was founded in 2024 by Diogo Almeida, who previously spent about four years at OpenAI working on RLHF, InstructGPT, ChatGPT and GPT-4.

The fundamental difference is that Jev doesn't generate text. It takes a described situation and a list of allowed options, and returns a typed answer along with probabilities and a confidence value. Its output is meant to be consumed by software, not by a person.

The three primitives

Classify Choice

Pick one option from a closed set of up to 255 options. Returns the chosen option, the probability of each one and a confidence value.

Rank Score

Score against ordered levels. Returns the score and the probability of each level.

Verify Noul

Assess whether a statement is true. Returns a probability between 0 and 1.

Everything Jev does is expressed through these three forms. There is no fourth one that returns prose.

The other difference is architectural: it isn't autoregressive. A language model produces its answer token by token, and each token depends on the previous one. Jev uses a parallel sampler that produces the whole output in a single pass. That's where its advertised latencies of 70 to 500 milliseconds end to end come from.

The piece that really matters: calibration

Fast and cheap make for headlines. What makes Jev interesting to anyone working in security is something else, and it's the training method: Reinforcement Learning for Calibrated Decisions (RLCD).

The contrast is worth understanding. RLHF (the method used to fine-tune conversational models) optimizes for a human rater liking the answer. RLCD optimizes for something quite different: that the probability matches reality.

What it means for a model to be calibrated. If the model says 0.9 across a hundred cases, roughly ninety of them should turn out true. Not eighty, not a hundred. A model that is right a lot but whose confidence means nothing is useless for automation: you can't set a threshold.

This is exactly the problem anyone who has tried to automate triage with an LLM runs into. The model tells you "high confidence" and you have no way of knowing what that means. With a calibrated model you can write the rule everyone wants to write: above 0.95 it's resolved automatically, below that it goes to a person.

"Zero hallucinations": the fine print

It's the most widely repeated claim and the most poorly understood. It's worth stating precisely, because the difference matters.

What it does guarantee Schema conformance

• The answer is always one of the options you asked for.
• It never invents a category that isn't on the list.
• It never returns malformed JSON or text where you expected an enum.
• No retries for formatting and no parsing of prose.

What it does NOT guarantee Accuracy

• The chosen option can be the wrong one.
• The 0% hallucination figure is not an empirical accuracy figure.
• It still needs evaluating on your own data.
• A typed error is still an error.

The documentation itself acknowledges it: "zero hallucinations" means guaranteed schema conformance, and the 0% figure is not empirical.

That said, it's no small thing. Anyone who has built a structured-output pipeline on top of an LLM knows the dance of retries, validators and last-resort regular expressions. Removing that entire layer has real value, as long as it isn't confused with "the model doesn't make mistakes".

The numbers, and why to scrutinize them

TypeSafe publishes comparisons against frontier models with eye-catching numbers: between 20 and 200 times faster, between 40 and 400 times cheaper. The maximum it reports is 193.6 times faster and 444.6 times cheaper, against GPT-5.6 Terra: 0.114 seconds versus 8.566.

70–500 ms

End-to-end latency (Versus seconds for an LLM)

$0.042

Per million input tokens (Output tokens are not billed)

255

Maximum options in a choice

$40M

Seed round led by DCVC ($200M valuation, according to Forbes)

Two caveats before you put these numbers in a slide deck. First: they are self-reported. TypeSafe itself admits the reported gains "are at the high end of real-world results", and the publication TechStock² has specifically questioned the 445x figure for being self-assessed. Second: TypeSafe has published neither the architecture, nor the weights, nor a technical paper. We know it's a transformer trained exclusively on synthetic data, and little else. Some outside observers suggest it could be built on top of an open-weights LLM.

This doesn't invalidate the product, but it does shape how it gets adopted. It's a proprietary API from a two-year-old company. If the decision it's going to make sits on your business's critical path, that dependency is part of the risk analysis, not a footnote.

Laya: the alternative you can self-host

This is where the story gets interesting. Laya, from Convai Innovations, is a multilingual, non-autoregressive System 1 decision model released under the Apache 2.0 license. In other words: downloadable weights, commercial use allowed and deployment on your own infrastructure.

The approach is the same (you give it a state, such as a text, an email, a ticket or a JSON object, plus typed questions, and it returns typed answers with calibrated probabilities in a single pass), but this time the architecture is published.

The three variants

The decision head is trained from scratch: two transformer layers, an option scorer and a scaling head. And the training method is the same concept as Jev's, also called RLCD: the policy reports a distribution, exploration adds zero-mean Gaussian noise to the logits, and the reward uses strictly proper scoring rules (logarithmic, spherical, ranked probability score) with a GRPO-style REINFORCE update.

Laya versus Jev, by Laya's numbers

Laya's model card publishes a head-to-head comparison against Jev 1.13.0. It should be read knowing where it comes from (it's published by Laya's makers, just as Jev's are published by TypeSafe), but it's one of the few public comparisons out there.

An honest reading of that table has two parts, and the second is the one that matters when you're deciding.

Laya wins on speed, on calibration and on small label spaces. On a Tesla T4 (a modest GPU) it handles between 103 and 332 questions per second in batch, with 32.8 ms of latency for a single question. And its calibration error is three times lower.

But it falls apart when there are many labels. On Banking77, with 77 categories, it reaches 0.425 against Jev's 0.870. If your problem is classifying into a large catalog (routing a ticket to one of sixty queues, mapping a vulnerability to one of eighty CWE categories), that number rules it out.

What Laya's own model card admits. The base checkpoints perform close to chance on zero-shot typed-decisions (0.362). It's weak on ordinal scoring questions. And it ships overconfident, so it needs temperature rescaling. The line its authors use is the one to remember: "Laya is a fast base for specialization, not a zero-shot decision engine". Of the 51 languages it supports, 45 perform above chance by a factor of three.

How to choose between them

Jev Proprietary API

• Better on large label catalogs.
• Works well without any fine-tuning.
• Per-token pricing, no infrastructure to maintain.
• Architecture and weights not published.
• Your data leaves your perimeter.
• Dependence on a two-year-old vendor.

Laya Apache 2.0, self-hostable

• Much faster and better calibrated.
• Zero inference cost: runs on a T4.
• Your data never leaves your infrastructure.
• Weights, architecture and method published.
• Needs to be specialized on your data.
• Weak beyond twenty labels.

It's not a contest with a winner: they solve the same problem with opposite trade-offs.

If the data you're going to classify is sensitive (customer emails, tickets containing personal information, audit findings), the conversation changes tone. Sending that to a third-party API isn't a technical decision, it's a compliance decision: it has to be documented in the record of processing activities, and the international transfer has to be assessed. A 421-million-parameter model that runs on a modest GPU and never leaves your network makes that whole conversation unnecessary.

What this means for security

In cybersecurity, almost all high-volume work is classification under uncertainty. That's literally the problem these models solve.

1. SOC — Alert triage
   A SOC manually discards thousands of alerts that don't apply. With a calibrated decision per alert in 33 ms, the filter runs inline and the analyst only gets what clears the threshold.
2. Vuln management — Vulnerability prioritization
   Deciding whether a finding applies to the environment, whether it duplicates another one and what severity it deserves are three typed questions. It's exactly the triage funnel we describe in KOMPLIANCE.
3. Agents — Agent guardrails
   An autonomous agent about to run a command needs a fast judge that says allow or block with a probability. An LLM there adds seconds and doesn't give you a number to set a threshold on.
4. Data leakage — Classifying data before it leaves
   Deciding whether a piece of text contains sensitive information before someone pastes it into a public AI. It has to be fast and local, because if checking it means sending the data out, the control is pointless.

That last case is the most elegant, and it's worth pausing on: a sensitive-data classifier that calls an external API is a contradiction in terms. To check whether the text is confidential, you send it to a third party. A self-hostable 322M-parameter model resolves the paradox.

When NOT to use a decision model

The part that doesn't make it into the announcements. There are cases where this is the wrong tool.

• When you need the explanation, not the decision. An audit report has to argue why something is critical. A probability doesn't argue.
• When the answer space is open-ended. If you can't enumerate the options, no primitive covers it.
• When multi-step reasoning is the job. Chaining inferences is precisely what a System 1 model doesn't do: that's why it's called that.
• When you have nothing to evaluate it against. A model calibrated on data that doesn't look like yours is calibrated for a different problem. Without your own evaluation set, you don't know whether 0.9 means anything.

The useful question isn't whether these models replace LLMs. It's how many of your LLM calls never needed one.

How we're looking at it

We're interested for a specific reason, not for the novelty: triage is the real bottleneck in vulnerability management. A serious scan generates thousands of findings, and most of the human effort goes into discarding what doesn't apply, grouping duplicates and ordering what's left.

Our starting position is that data doesn't leave the client's perimeter, which is also the approach behind 0data. That tips the balance toward self-hosting by default, accepting the limitation that it has to be specialized with your own data and that large label catalogs don't work well today.

And the underlying caveat, which applies to any model: automated decisions only hold up if the probability means something. Before you let a threshold close findings without anyone looking at them, you have to measure calibration on your own data. A model that is well calibrated on a public benchmark can be badly calibrated in your environment, and there the failure isn't loud: it's silent, and it looks a lot like everything is fine.

If you're considering bringing decision models into a security process (or simply want to sort out what can and can't be sent to an AI), that's precisely the part we work on at QuantumSec: secure AI use in the enterprise, with the policy, the technical controls and an audit of actual usage.

Related service

secure AI adoption in the enterprise

Topics

#Artificial-Intelligence #Jev #Laya #System-1 #Calibration #Triage #Autonomous-agents #Data-sovereignty

Keep reading

• Anatomy of 0data: dissecting a data and AI platform that never leaves your house
• RTX 5090, DGX Spark or Mac Studio: which machine to choose for running AI locally
• Can I upload this to AI? Classify the data before you paste it
• Docker Model Runner vs. Ollama
• Can emojis hack AI models?

Sources

• TypeSafe AI — official website
• Laya on Hugging Face (convaiinnovations/laya)
• Laya — GitHub repository
• MarkTechPost — TypeSafe AI releases Jev
• ModernBERT — the backbone of Laya's root model

Let's talk about your use case