Jev: The System One Model That Doesn't Generate Text

What If Your AI Didn’t Have to Talk?

Every time you ask an LLM a question, you’re rolling the dice.

Not on whether it knows the answer. On whether it will give you the same answer twice.

Back in December, I wrote about how GenAI is like a box of chocolates. You never know what you’re going to get. Ask GPT or Claude to classify a support ticket right now, ask again in five minutes, and you might get a different result. Different wording. Different confidence. Maybe even a different category. I ended that post with a question: “Will we see deterministic large language models in the future? Maybe.”

This is the non-determinism problem, and if you’ve built production systems on top of LLMs, you know it well. You’ve written the retry logic. You’ve built the validation layer. You’ve added the “just in case” parsing code for the 1-in-50 response where the model wrapped its JSON in a friendly paragraph.

And here’s the thing that’s been bugging me. For a huge number of use cases, we don’t actually need the model to talk. We need it to decide.

Is this email spam? Which team should handle this ticket? Is this transaction fraudulent? How urgent is this on a scale of 0 to 10?

These are yes/no, pick-one, or score-it questions. We’ve been feeding them to models designed to write poetry, and then parsing the poetry back into a boolean. Does that sound right to you?

Well, nine months later, someone built something that takes a very different approach. And the answer isn’t a “deterministic LLM.” It’s not an LLM at all.

What Is Jev?

Last week (September 15, 2026), a company called TypeSafe AI came out of stealth with a $40M seed round and a model called Jev. The founder, Diogo Almeida, was a co-inventor of ChatGPT at OpenAI. He helped build the instruction-following methods that made LLMs actually useful.

And then he went and built something that doesn’t generate text at all.

Jev takes a block of state and a set of typed questions, and it hands back typed decisions with probabilities attached. No prose. No tokens streamed one at a time. No parsing. Your software gets back data it can act on directly.

What Is a System One Model?

Jev is what TypeSafe calls a “System One Model”. The name comes from Daniel Kahneman’s Thinking, Fast and Slow. System 1 is your brain’s fast, intuitive, automatic mode. System 2 is the slow, deliberate reasoning. Every LLM on the market today, with its chain-of-thought and multi-second reasoning traces, is doing System 2 work.

Jev is built for the other half. The snap judgment. The fast call.

That’s the whole pitch in one line. We’ve spent three years building bigger and bigger System 2 engines, and most of the decisions our software actually makes are System 1 decisions. We’ve been using a sledgehammer to hang a picture frame.

How Does Jev Work?

The interface is dead simple. You send Jev two things:

1. A state (any text or JSON your code already has, like a support ticket, a log entry, an order record)
2. A set of typed questions about that state

And you get back typed answers. Not text. Not a paragraph. You get data.

There are exactly three question types:

• Noul (yes/no): Returns a probability from 0 to 1. “Is this urgent?” → 0.95
• Choice (pick one): Returns the selected option plus per-option probabilities. “Which department?” → technical (0.84)
• Score (rate it): Returns a numeric score against an ordered rubric. “Customer frustration 0-2?” → 1.04

Here’s a real example from the docs. A support ticket saying “I’ve been trying to connect my Stripe account for 3 days and it keeps failing. I’m losing sales. Please help ASAP.”

{
  "state": "I've been trying to connect my Stripe account for 3 days...",
  "questions": {
    "department": {
      "type": "choice",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "frustration": {
      "type": "score",
      "criteria": ["Calm", "Frustrated but civil", "Very angry"]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency"
    }
  }
}

And the response:

{
  "answers": {
    "department": {
      "choice": "technical",
      "probabilities": { "billing": 0.159, "technical": 0.84, "sales": 0.001 },
      "confidence": 0.596
    },
    "frustration": { "score": 1.035, "confidence": 0.842 },
    "is_urgent": { "noul": 0.999 }
  }
}

No text to parse. No JSON wrapped in markdown. No “I’d be happy to help classify this for you!” polite bullshit. department.choice is one of the three keys you defined. is_urgent.noul is a float you can threshold. Done.

And all three questions? Answered in parallel, in a single call, in about 250 milliseconds.

Think about why that matters. With an LLM, three questions means three round trips (three times the cost, three times the latency), or you cram them into one prompt and hope the JSON comes back clean. Jev evaluates every question against the same state in one forward pass. Adding a fourth barely moves the response time. When you’re processing thousands of tickets an hour, that compounds fast.

Is Jev Deterministic? The Non-Determinism Problem

Let me get back to the thing that got me thinking about this in the first place.

When you use an LLM for classification, you’re dealing with a model that generates text one token at a time, autoregressively. The same input can produce different outputs because of sampling randomness, temperature, and the sheer complexity of generation.

You can set temperature to 0. You can use structured output modes. You can beg the model to “PLEASE only return JSON, nothing else.” And it mostly works. Mostly. But “mostly” is not what you want when you’re processing 50 million tickets, making real-time fraud calls, or gating whether a coding agent is about to run db:reset on production.

Here’s the thing. When we say “non-determinism” in AI, we’re actually conflating two different problems:

1. Structural non-determinism. The model might return clean JSON. Or JSON wrapped in a code block. Or a paragraph with no JSON at all because it “wanted to explain its reasoning first.” Your parser breaks. Your Slack channel lights up at 2 AM. You have steering files that try to prod the model in the right direction, but that does not work 100% of the time.

2. Decisional non-determinism. The model classifies the same ticket as “billing” on one call and “technical” on the next. Same input, different judgment. This one is inherent to any probabilistic system.

With LLMs you fight both at once, and you can’t tell them apart. When a pipeline fails, was it garbage formatting, or did the model genuinely change its mind? You don’t know. You just see a broken output.

Jev eliminates the first problem entirely. It never generates text. The output is constrained to the schema you defined. It literally cannot return a value outside your list of options, cannot invent a category, cannot wrap its answer in a paragraph. Structural non-determinism? Gone. By construction.

The second problem doesn’t go away. Jev is still a neural network making probabilistic judgments. It can still pick the wrong option from your list. “Can’t hallucinate” means “can’t return an invalid type,” not “always makes the right call.” Plenty of people made exactly that point in the launch-week pile-on on Hacker News, and they were right to.

But here’s what changes. With Jev, you know which problem you’re dealing with. When a decision is wrong, it’s not because your parser choked. It’s because the model picked billing when it should have picked technical. That’s a cleaner, more debuggable failure. And because every answer ships with a calibrated confidence score, you often know in advance which decisions to trust.

That’s not determinism. But it’s something almost as useful in production. It’s quantified uncertainty with structural guarantees.

Why Calibrated Confidence Scores Matter

Here’s the feature I think matters most for production systems.

Every answer from Jev comes with a calibrated confidence score. “Calibrated” means something specific: if Jev says 0.9 on a hundred inputs, roughly ninety of them will actually be correct.

LLMs are notoriously terrible at this. Ask an LLM “how confident are you?” and it’ll say 95% whether it’s right or guessing. The number is essentially meaningless.

There’s a catch, and it’s the same one I keep coming back to. A confidence score tells you whether to trust the answer, not why the model landed there. Jev gives you a number, not a rationale. I wrote a whole post about wanting AI tools to show me the receipts, and a bare probability is the opposite of receipts. For gating and routing that’s a fine trade. For anything you’ll have to defend in an audit, keep that gap in mind.

With Jev, you can build a real confidence threshold into your pipeline:

• Above 0.85? Act automatically.
• Between 0.5 and 0.85? Route to a human reviewer.
• Below 0.5? Escalate immediately.

That’s real, actionable automation. You’re automating the cases where the model knows it’s right, and escalating the ones where it’s unsure.

How Fast and Cheap Is Jev? The Numbers

Let me be honest, these are mostly vendor-reported numbers, and independent verification is still early. But here’s what’s being claimed:

One independent benchmark by AY Automate on 791 labeled decisions found Jev 2-4x faster and 5-7x cheaper than even small, cheap models, with comparable accuracy. Not 200x. But still meaningful, and notably it’s someone other than TypeSafe running the numbers.

On accuracy, Jev hits about 68% on TypeSafe’s own 4-workflow benchmark, roughly where mid-tier LLMs like GPT-5.6 Terra land. The top models (GPT-6 Astra, Fable 5.1) still score higher at 75-80%. You’re trading a few accuracy points for massive cost and speed gains. Whether that trade is worth it depends entirely on your use case.

Do the math on cost. At $0.0004 per decision, scoring every review in a 50-million-row table for sentiment and policy violation runs about $20. Try that with a frontier LLM. Your finance team will have questions, sometimes also puppies.

Can Jev Replace Your LLM?

No. And this is the part people keep getting wrong in the hype.

Jev is not replacing your LLM. It can’t write an email, generate code, explain its reasoning, hold a conversation, or produce any text of any kind. If you need a model to think through a complex, open-ended problem, you still need an LLM.

TypeSafe’s own framing is that you use Jev for the System 1 decisions (fast, high-volume, bounded) and your LLM for the System 2 work (slow, complex, open-ended). Together, they form the full stack.

What Are People Building With Jev?

Here’s what excites me about this.

Within 48 hours of launch, developers had already built:

• pi-warden: a coding agent guardrail that checks every bash, write, and edit command before execution, asking four typed questions (“is this irreversible?”, “is it off-task?”, “does it mutate anything?”, “what scope?”) in about 250ms. This is a direct mitigation for the risk I covered in Unexpected Code Execution, where an agent turns into an unintended shell. Firecrawl’s writeup reports it caught a handful of genuinely destructive commands across thousands of calls, though I couldn’t track down the repo to verify those figures first-hand.
• An MCP server wrapping Jev for agentic pipelines (Claude Code, Codex, anything that speaks MCP)
• Vercel added Jev to AI Gateway on September 16, and it became the fastest-adopted model in AI Gateway history, hitting 13% of paid teams in 24 hours
• Cloudflare Workers AI integrated it as a first-class model (@cf/typesafe/jev)
• LangChain shipped a langchain-typesafe package, and LangSmith added Jev as a judge for evaluations

The pattern is clear. Jev fits next to an LLM, at the branching points of a pipeline. The LLM generates the plan. Jev validates, routes, scores, and gates. The LLM writes the response. Jev checks it before it ships.

Think about what that means for agentic workflows. Today, every “should I proceed?” check inside an agent is either a regex (fragile), a rule (brittle), or another LLM call (slow and expensive). Jev gives you a third option. A fast, cheap, calibrated judgment call.

The Bottom Line

For years we’ve hammered every AI nail with the LLM hammer. Need a classification? LLM. Need a yes/no? LLM. And then we build a parsing layer, a validation layer, a retry layer, and a “please dear model just return the JSON” prompt layer on top.

Jev asks a simpler question. What if the model just returned the data type you actually wanted?

It’s not perfect. The accuracy trails the best LLMs. The benchmarks are mostly vendor-reported. It can’t explain why it made a decision. And it only works when you can define the answer space up front.

But for the right use cases, fast, cheap, high-volume, structured decisions, this feels like the right shape of tool. Not a better LLM. A different kind of model entirely.

And honestly? It’s about time.

I would be very interested to hear your thoughts or comments, so please feel free to ping me on Twitter or LinkedIn.