The Next Big AI Model Can't Write a Single Sentence

I build Indraft, a content pipeline tool. When I look at where the AI calls in a pipeline like that actually go, a surprising number of them aren't writing anything.

They're deciding. Is this idea on topic? Which content bucket does it belong in? Is this draft ready, or does it go back for another pass?

For each of those small calls, the usual approach is to send the input to a full chat model, ask it nicely to reply in JSON, parse the answer, and hope it stuck to the format. It works. It's also slow, expensive, and a little silly when all you needed was one word.

That's the gap Jev is built for.

TL;DR

• Jev is the first model from TypeSafe AI. It doesn't generate text. It returns typed decisions with probabilities.
• Think of it as an if statement that understands meaning.
• It answers every question in a request in parallel, in roughly 70 to 500 ms, for $0.042 per million input tokens. Output is free.
• "Can't hallucinate" means it can't answer outside the options you define. It can still be wrong.
• Use it for routing, triage, scoring and guardrails. Keep a regular LLM for anything that needs words or real reasoning.

What Jev actually is

Jev comes from TypeSafe AI, a San Francisco lab founded by Diogo Almeida, a former OpenAI researcher and co-author of the InstructGPT paper that led to ChatGPT. The company came out of stealth on September 15, 2026 with $40M in seed funding, and Jev is its first public model.

TypeSafe calls it a System One model, a nod to Daniel Kahneman's Thinking, Fast and Slow. System 1 is quick, intuitive judgment. System 2 is slow, deliberate reasoning. Most frontier models are pushing deeper into System 2 with longer and longer reasoning chains. Jev goes the other way on purpose.

You give it two things:

• State: the input you want judged. A support ticket, an email, a form submission, a paragraph, a JSON object.
• Questions: what you want to know about it, along with the answers you'll accept.

It gives back one typed answer per question, with probabilities. No prose. No "Certainly! Here's your classification."

There are three question types:

(Yes, the yes/no type is really called "Noul".)

The if statement that understands meaning

This is the mental model that made it click for me.

Normal code branches on things it can compute, like if (order.total > 100). It falls apart the moment the condition is a judgment call.

Take the classic support rule:

if (message.toLowerCase().includes('refund')) {
  routeTo('billing')
}

It catches "I want a refund." It misses "I got billed again after cancelling," "can I get my money back," and "why is there a second charge on my card?" If you've run a SaaS, you know how this ends: you keep adding keywords until the rule is a mess nobody wants to touch.

Jev reads the whole message, answers the question you actually care about, and tells you how sure it is. Your code still makes the final decision.

What a call looks like

Here's a small support triage using the JavaScript SDK (npm install @typesafe-ai/sdk, Node 20+, server-side only):

import { choice, noul, score, TypeSafeClient } from '@typesafe-ai/sdk'

const client = new TypeSafeClient() // reads TYPESAFE_API_KEY from env

const message =
  "Got billed again even though I cancelled last week. Kinda annoyed, can someone sort this out?"

const { answers } = await client.systemOne({
  state: { message },
  questions: {
    team: choice('Which team should handle `message`?', {
      billing: 'Charges, invoices, refunds, cancellations',
      technical: 'Bugs, errors, login or integration problems',
      sales: 'Pricing questions, upgrades, new accounts',
      other: null,
    }),
    unwanted_charge: noul('Does `message` complain about a charge the customer did not expect?'),
    frustration: score('How frustrated is the author of `message`?', [
      'Calm, just reporting something',
      'Annoyed but polite',
      'Angry or threatening to cancel',
    ]),
  },
})

A few things worth noticing:

• answers.team.choice can only ever be one of the four labels you defined. In TypeScript, it's typed that way too, so autocomplete works and typos fail at compile time.
• All three questions run in a single call.
• The question text matters. Jev reads it literally, so I asked about an unexpected charge rather than "does this ask for a refund," because the customer never actually asked for one.

Then your code does the boring, predictable part:

const { team, unwanted_charge, frustration } = answers

if (team.confidence < 0.6) {
  return sendToHuman(message) // not sure, let a person look
}

if (team.choice === 'billing' && unwanted_charge.noul > 0.8) {
  return openBillingCase(message, {
    priority: frustration.score > 1.5 ? 'high' : 'normal',
  })
}

return routeTo(team.choice, message)

The model supplies the judgment. The rules, thresholds and consequences stay in code you can read and change.

Confidence is the real feature

Every answer comes with a probability, and TypeSafe trained Jev with a method it calls Reinforcement Learning for Calibrated Decisions (RLCD). The goal is that when Jev says 90%, it's right about 90% of the time across many predictions. A number a chat model writes in its reply doesn't come with that promise.

That gives you a simple pattern:

• High confidence: act automatically.
• Medium: ask the user to confirm, or flag it for review.
• Low: send it to a person or a slower, smarter system.

Where you draw those lines depends on what a wrong answer costs. Tagging a blog post wrong is cheap. Refunding the wrong customer is not. Start conservative and tune on your own data.

Ask everything at once

This one flips a habit from the LLM world. With chat models, every call is slow and costs money, so we ask one question, look at the answer, then decide what to ask next.

With Jev, every question runs in parallel against the same input, and each extra question only costs its own few tokens. So you ask everything you might need up front, even questions that only matter for some inputs, and let your code pick which answers to use. TypeSafe calls this "speculative fan-out."

Where it fits

For developers

• Routing: send each request to the right handler, or decide whether it needs the cheap model or the expensive one.
• Guardrails: before a coding agent runs a shell command, ask whether it's read-only, reversible or destructive.
• Agent loops: a fast "is this task actually done?" check.
• Log triage: noise, scheduled job, user-facing failure, or something that needs attention now.

For SaaS founders

• Ticket triage without a 10-person support team.
• Lead scoring on inbound form submissions.
• Churn signals hiding in feedback and cancellation reasons.
• Spam and abuse moderation.

For content teams

• Does this draft follow our style rules?
• Does the headline match what the post actually says?
• Which topic cluster does this idea belong to?
• Which claims in this draft need a fact check?

Notice the pattern in that last group: Jev doesn't write anything. An LLM drafts, Jev checks and sorts, and your code decides what happens next. The two work well together.

If you don't write code, CodeWithChris has a walkthrough that wires Jev into Zapier: a new support message comes in, Jev checks whether it's an access issue, and if confidence is above 70%, a Slack alert fires.

Where it breaks

I respect that TypeSafe publishes its own list of failure modes (they call it a "jaggedness" page). Here's what I'd keep in mind:

• Typed doesn't mean correct. A Choice always returns a valid option. It can still be the wrong one.
• It reads literally. It answers the question you wrote, not the one you meant. Be precise.
• No math, counting or dates. Do those in code and pass in the result.
• Noisy input hurts accuracy. Send only what the question needs, not the customer's entire history.
• Adversarial text can nudge it. Test with hostile inputs before exposing it to the public.
• Text only. No images, audio or video yet.
• It can't write. That's the point, but it means you still need an LLM for anything with words.

About those numbers

TypeSafe's headline is up to 194x faster and 445x cheaper than frontier models. Those figures come from the company's own workflow evaluations, and it says itself they sit at the high end. Its launch post describes the gain as "two orders of magnitude." I'd treat the big multiples as a ceiling, not a promise.

The pricing is easy to reason about though. Say a ticket plus your questions is about 500 tokens. 100,000 tickets is 50 million tokens, which at $0.042 per million comes to about $2.10.

The metric that actually matters is cost per correctly handled task. If the cheap path adds retries or extra human review, some of those savings disappear. Measure the whole pipeline.

Why it's called Jev

It's named after William Stanley Jevons, the 19th-century economist behind the Jevons paradox: when something becomes cheaper to use, we end up using far more of it. Cheaper steam engines didn't reduce coal use. They increased it.

TypeSafe's bet is the same for intelligence. Once a decision costs a fraction of a cent and takes 100 milliseconds, you'll start putting one in places you'd never have considered calling an LLM.

How I'd start

1. Pick one boring decision your code currently handles with a keyword rule or a regex that keeps breaking.
2. Spend an hour in the TypeSafe Playground with your own data, not the demo examples.
3. Run Jev in shadow mode: log its answers next to your current logic for a week or two without letting it change anything.
4. Label where it was right and wrong, then adjust your questions and thresholds.
5. Automate the low-risk path first. Keep a human or a bigger model for the uncertain cases.

On access: TypeSafe opened signups on September 20, then paused new ones on September 22 because of demand. Existing accounts still work, and Jev is also available through Vercel's AI Gateway as typesafe-ai/jev at the same price.

The bigger picture

For the last couple of years the question has been "who can build the model that does the most?" Jev asks a different one: what if a model did one small thing, really fast, really cheaply, and you could trust its confidence?

I don't think it replaces the models we already use. I think it takes over the dozens of tiny decisions we've been awkwardly handing to them.

So here's my question for you: what's one decision in your product that you're still solving with a keyword rule, or a full LLM call, that really just needs a yes or no?