Jev and System One Models: An AI Model That Doesn't Write a Single Word

On 15 September 2026 an AI model called Jev was released, and its headline feature is that it doesn't write a single word.

That isn't a shortcoming. It's the design. You give it a situation, and it hands you back a decision from a list you defined in advance, along with a probability for each option. In about 0.4 seconds. They call this kind of model a System One Model, and it's a whole new category. It's not a smaller or faster LLM; it's something else entirely.

The idea is borrowed from a book, and that's the best thing about it

If you've read Daniel Kahneman's Thinking, Fast and Slow, you already know the idea.

You're driving, and suddenly a ball bounces into the road in front of you. You don't sit there measuring the distance, weighing your options and writing a list of pros and cons. Your foot hits the brake before your brain has even worked out what happened.

That's System 1: fast, automatic, no explanation.

Later that same day you sit down and work out your income tax on paper. That's System 2: slow, deliberate, step by step.

And here's the crux of it: every AI model you've worked with until today is a System 2. ChatGPT, Claude, Gemini: they all think out loud, write word after word, and take their time. That's great when you want an article, code or an analysis.

But 90% of the decisions your software makes every day aren't like that. "Which team does this bug report belong to?" isn't a philosophical question. It's hitting the brake.

Why are LLMs slow in the first place?

It's not because "the model is big". The reason is architectural, and it's called Autoregression.

An LLM generates one token at a time, and every token has to wait for the one before it to start. So if the answer is 200 tokens long, the model ran 200 sequential steps. You can't speed that up by parallelising, because step 50 literally needs the result of step 49.

Jev breaks that constraint: it generates all the answers in a single parallel pass. No chain, so no waiting.

OK, so what exactly does it return?

You define the questions before you send anything, and there are only three types:

Let's see it on an example you know well: a bug report has just landed, and you need to triage it.

import { choice, noul, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const report = `Login button does nothing on Safari 17.
Happens every time. Console: Uncaught TypeError: undefined is not a function.
Started right after yesterday's release.`;

const result = await client.systemOne({
  state: { bugReport: report },
  questions: {
    area: choice("Which team owns this bug?", {
      frontend: "UI, rendering, browser-specific behaviour",
      backend: "API, database, server errors",
      infra: "Deploy, environment, CI",
    }),
    regression: noul("This looks like a regression from a recent release"),
  },
});

result.answers.area.choice;      // "frontend"
result.answers.area.confidence;  // 0.94
result.answers.regression.noul;  // 0.88

Notice something: there's no JSON.parse, and no check for whether the model forgot a bracket.

This is the most important point in the whole thing, and it's easy to skim past. When you ask an LLM to "return JSON", you're hoping the text comes out in the right shape. With Jev the types are defined before you send, so a structural error is impossible. Not rare. Impossible.

The numbers

Here's the comparison TypeSafe published across four decision tasks:

Read the first and second rows together: almost the same accuracy, at 1/76 of the cost, and 25 times faster.

And even clearer: classifying 50 million rows costs you about $20 instead of thousands.

The fun part: Jev plays Doom

The best demo they showed wasn't a table. They got the model to play Doom.

It takes the game state as input and makes a decision ten times a second, at a cost of about $7 an hour. Try doing that with an LLM that takes 10 seconds to respond: you'd die 30 times before the first answer came back. 🎮

And that's where the idea clicks: in live decision-making, speed isn't a luxury. It's a precondition for existing at all.

Where does it help you as a QA engineer?

This is where it gets practical. Any task you do by the hundreds or thousands, whose answer comes from a list known in advance, is a candidate:

1. Triaging bug reports. You got 300 reports this week: which team, what severity, and is it a duplicate? That's exactly the shape of the problem.
2. Classifying test failures. CI produced 40 failures. Which ones are flaky and which ones are a real regression? You're making that call by hand every morning.
3. Prioritising the regression suite. Before you run 2,000 tests, which hundred of them are most related to the change that just went in?
4. A Confidence Gate. This is the smartest use: let decisions above 0.9 go through on their own, and send anything below that back to a human or to a slower, smarter LLM. The probability isn't decoration. It's a routing tool.

Hold on: what doesn't it do?

Before you get too excited, here are the limits, and they're real:

• It doesn't write text. Ever. No code, no emails, no summaries, no explanations. If the output you need is a sentence, this isn't the model.
• It doesn't give you a reason. It gives you a number. You know it classified the report as frontend with probability 0.94, but why? There's no answer. That's a real pain when debugging, and even more painful in regulated domains that require every decision to be justified.
• The options have to be known up front. If you can't write the list, you can't use it.
• It doesn't count or do date arithmetic. That's a job for code; the model isn't the place for it.

The simple rule: if code can calculate it exactly, leave it to code. If it needs a repeated human judgement from a closed list, that's where System One comes in. If it needs writing or open-ended thinking, go back to the LLM.

And the question every test engineer should be asking

Now pay attention, because this is the crux of it for us.

How do you test a model that doesn't return text?

Everything you've learned about comparing text is suddenly meaningless. There's no string to compare. The answer is a number and a probability.

The right metric here is called Calibration: when the model says "0.8", it should be right 80% of the time. Not 95%, and not 60%. A model with 70% accuracy and honest calibration is more useful than a model with 85% accuracy that says 0.99 about everything, because you can build a confidence gate on the first one, while the second one lies to you with confidence.

And this isn't just Jev's problem. This is the skill that separates a QA engineer who tests software from a QA engineer who can test AI. And it's a skill you can learn.

If you want to get into it seriously, from the idea of LLM as a judge, to metrics like Faithfulness and Task Completion, to building your own metrics, that's exactly what the course Evaluating AI Applications with DeepEval covers.

Models will keep changing every month. What doesn't change is your ability to ask: OK, how do we know it's working correctly? If you have that ability, every new model becomes a tool in your hands, not a wave you have to chase. 🔍