Jev: The Model That Decides in 70ms and Can't Write

A customer writes to your support team at 11:12pm. Before a reply goes out, your product has to settle four things: sales question or technical one, urgent or not, does someone need to be paged, does the tone of the message signal a customer about to churn.

Four closed-ended questions. Four calls to a reasoning model, two seconds and a cent each. Eight seconds and four cents to reach the point where the real work starts: writing the reply.

None of these four questions asked for anything to be written. They asked for a choice from a list.

TypeSafe just shipped Jev, the first entry in a model class they call System One. Its defining trait fits in one sentence: it can't write. No text ever comes out. Instead, a typed value with a probability attached. Announced at 70 to 500 milliseconds end to end, $0.042 per million input tokens, output free.

This article looks at what that shift changes about scoping an AI product. First, what the "can't hallucinate" claim actually means, because it's narrower than it sounds. Then three places where the math flips. Finally, what you can do today, with the models you already have, to be ready for the day you plug in the other one.

Three words before we start

• system 1 and system 2: the vocabulary comes from Daniel Kahneman and Thinking, Fast and Slow. System 1 judges fast and without conscious effort: recognizing a face, sensing that a sentence sounds off. System 2 reasons slowly: working through a division, comparing two contracts. Today's language models are System 2 machines used, at scale, for System 1 tasks;
• a structured output is a response whose shape is known ahead of time: one value out of five, a boolean, a number between 0 and 100. Today you get it by asking a text-producing model for JSON, for instance with generateObject, then validating that text. The shape is hoped for, not guaranteed;
• calibration is the property that gives a confidence score its meaning. A calibrated model that claims 80% is wrong roughly two times out of ten. An uncalibrated model can claim 95% and be wrong one time in three.

That third point is the one that matters for a product. Without calibration, the score is just interface decoration. With it, it becomes a threshold, and therefore a rule for automation.

Count the decision share of your product

Take a typical user session and sort your model calls into two columns. On one side, the ones that produce text meant for a human. On the other, the ones that produce a value only your code reads: routing to the right agent, choosing a tool, classifying an attachment, deciding whether to rerun a search, scoring a reply before it's shown, extracting six fields from a document.

On the agentic products I ship, the second column is the longer one. A single loop turn holds one generation and several decisions.

The right-hand column is the point. A generation is allowed to be slow, streaming keeps the user occupied while it runs. A decision doesn't get that luxury: it sits before or after the visible moment, adding its latency with nothing to show for it. So you pay full price, in seconds and cents, exactly where the user sees no return.

What Jev gives up, and what it buys with it

The trade is blunt, and that's what makes it legible. Jev gives up producing text. Not "it does it worse", it doesn't do it at all. In exchange, it gets three things a generative model can't offer.

It computes everything at once. A language model writes token by token, each one conditioned on the ones before it. A forty-token output means forty sequential passes. Jev produces its entire output in a single parallel pass. Most of the latency gap comes from there, not from a smaller model.

Its output is typed by construction. The schema is no longer an instruction slipped into the prompt that you hope gets followed, it's the actual structure of what the model produces. Zero type errors, a mathematical guarantee rather than a statistical one. The try/catch around JSON.parse goes away.

It states its confidence, and that confidence is trained. TypeSafe built a dedicated method, RLCD for Reinforcement Learning for Calibrated Decisions, where the industry optimizes on RLHF and its verifiable variants. The goal is no longer to please a human evaluator, it's to output honest probabilities.

On their own workflow benchmark, TypeSafe claims 193.6x faster and 444.6x cheaper than GPT-6 Astra and Fable 5.1 used as references. These numbers are self-published, on workflows written by their own team, measured from west-coast laptops. They say so themselves in the post, which is already a sign of seriousness. It's still a reason not to put them in a business plan. Keep the order of magnitude, two zeros, and wait for an independent replication before trusting the decimal.

Why this name

Jev comes from William Stanley Jevons, the economist who observed in 1865 that improving the efficiency of steam engines drove coal consumption up instead of down. That's the Jevons paradox, and TypeSafe is openly betting on it.

For a founder, that's the idea worth keeping from the whole post. Making a decision a hundred times cheaper won't shrink your bill, it will multiply the number of decisions you allow yourself to make. The use cases in the next section weren't waiting on a technical breakthrough, they were waiting for the price to let them through.

"Can't hallucinate": the exact promise

The phrase is already circulating outside its context, it needs boundaries.

What Jev guarantees is that its answer belongs to the schema. If you ask for a choice among urgent, normal and low, you'll get one of those three values, always. No stray text, no invented field, no truncated JSON.

What Jev doesn't guarantee is that the answer is correct. An urgent ticket classified as normal is still a mistake, one the schema lets through without flinching because it has the right shape. TypeSafe is explicit about this: the absence of hallucination is a structural guarantee, not an empirical measurement.

The distinction changes what you have to build. A model that can't be malformed spares you syntactic validation. It spares you no business-level evaluation. The test case set that the MVP playbook calls for from day one remains exactly as necessary, with the same twenty to fifty real cases.

Calibration brings something else, to my mind more useful than a truth guarantee that no system actually has: it tells you the size of the error zone, ahead of time. If the model is calibrated, you know decisions announced above 0.9 are wrong one time in ten or less. You can then decide, with full knowledge, how much volume you let through without human review.

Three places where the math flips

1. The if no if can write

Is this lead qualified? Does this expense report deserve a review? Does this message signal a customer about to churn? Fuzzy answer, closed output: the worst combination for a developer.

Today, two options. Write three hundred rules by hand, ones that age badly and that nobody dares touch after a year. Or call a model, too slow and too expensive for a step that runs a thousand times an hour.

A calibrated decision opens a third path. What it delivers sits in the threshold, more than in the accuracy of the verdict. Above 0.9, the machine decides alone. Below 0.6, a human looks. In between, you choose based on the cost of being wrong. Above all, you know ahead of time what share of volume falls into each bucket, so you know how many human hours your automation requires before you even ship it. That's the number your client asks for, and no rules engine can produce it.

2. The backlog you never got to

It exists at every company I work with: four hundred thousand support tickets, two million product listings with no clean category, ten years of sales archives. The project has been scoped for a long time and it never ships, because the quote runs several thousand euros and several days of processing.

The math with published pricing, assumptions stated: 400,000 tickets at 800 tokens each is 320 million input tokens. At $0.042 per million, the full pass costs $13.44. The same volume on a frontier model at $3 per million input costs $960, output not included. Two public price lists and one division, redo it with your real volume before you take my word for it.

What gets unlocked isn't the budget, it's the permission to be wrong. At $13 a pass, you rerun the full enrichment three times a week because your taxonomy shifted on Tuesday. At $960, you run it once and live with the result for two years.

3. The decision that fits inside the interface

Under 100 milliseconds, a decision stops being a network request and becomes an interface behavior. Reordering a list while the user types. Pre-filling a field from what was just pasted. Flagging that a form will likely be rejected, before submission. Sorting an inbox as it fills up.

The threshold has been documented since the 1990s by the Nielsen Norman Group: past roughly 100 milliseconds, a reaction no longer reads as instant. Past one second, you need a loading indicator. And a loading indicator costs more than elegance. An instant suggestion gets accepted without a second thought. The same suggestion preceded by a spinner becomes a request: the user waits for it, judges it, and often turns it down.

This is the hardest category to picture on paper. It is where the gap in perceived quality shows most. Nothing about it looks like an AI feature, the screen simply responds better. This is the ground where a polished interface and the model stop being two separate subjects.

Two others deserve a line, for teams that already run an agent in production. The judge first: scoring a model's outputs costs about as much as producing them, so everyone samples a few percent of traffic offline. With free output, the scorers from the agentic guide move inside the request and cover all of it. The router next: picking two tools out of fifty, or the right sub-agent, is still a frontier call on every loop turn, whether that's the tool catalog, the supervisor in the multi-agent architecture or agent discovery in MCP and A2A. In both cases the gain is the one described above, moved inside the loop.

What this doesn't settle

You can't try it. Early access, waitlist. Everything above is reasoning built on announced numbers. I haven't run Jev.

The measurements are in-house. Workflows chosen and written by the vendor's own team, reference models chosen by them too, measurements taken from laptops. No independent replication to date.

Free output is a commercial position. "Too cheap to bill for" describes a market-entry strategy, not a cost structure. Building unit economics on that line repeats the mistake in principle four of the MVP playbook, with one more vendor.

It's one more dependency. A proprietary, closed model, from a young company, sitting at the center of your pipelines.

And most of the work is still System Two. Writing, summarizing, reasoning across multiple steps, writing code, holding a conversation. Jev doesn't replace your language model, it takes away a task the language model was oversized for.

Getting ready without waiting for the waitlist

The most useful thing to do right now doesn't depend on any early access: pull your decisions out of your prompts and give them an interface of their own.

Here's what a decision looks like in most codebases I inherit. Written inline, right where it was needed, with the provider's SDK sitting exposed in the middle of the business logic.

// Today: decision inline, provider hardcoded, shape hoped for
import { generateObject } from 'ai'
import { anthropic } from '@ai-sdk/anthropic'
import { z } from 'zod'

const { object } = await generateObject({
  model: anthropic('claude-opus-5'),
  schema: z.object({
    urgency: z.enum(['urgent', 'normal', 'low']),
  }),
  prompt: `Classify the urgency of this ticket:\n${ticket}`,
})

if (object.urgency === 'urgent') await pageOnCall(ticket)

Three problems, none of which wait on Jev to show up. The provider is hardcoded in the middle of the business logic. The decision has no name, so it has no test set. And you don't know how confident the model is, so you treat a borderline case exactly like an obvious one.

The same decision, named and isolated:

// The contract, independent of the engine
export type Decision<T> = { value: T; confidence: number }

export interface DecisionEngine {
  decide<T extends string>(
    input: string,
    choices: readonly T[],
    instruction: string,
  ): Promise<Decision<T>>
}

// The call, business side
const urgency = await engine.decide(ticket, URGENCIES, URGENCY_INSTRUCTION)

// The threshold exists right now, even if its value will move
if (urgency.confidence < 0.6) return humanReviewQueue(ticket)
if (urgency.value === 'urgent') await pageOnCall(ticket)

What you get right away, with today's models behind the interface: the decision has a name, so it gets its own evaluation set, in the spirit of the scorers that Mastra and other frameworks now ship standard. You can count how many decision calls a session makes, what they cost and what they add to latency. You have a single place to set a threshold and wire up a human review queue.

One caveat to write in plain sight in your code: the confidence you return in this interim implementation, derived from the model's logprobs or from a self-assessment, is not calibrated. Treat it as a provisional value. What matters is that the threshold exists in your code, not that its value is already the right one.

The day a calibrated engine becomes available, you swap one implementation behind an interface, rerun the same evaluation set, and compare two columns of numbers. This is the decision version of the rule this blog has applied to model choice from the start: isolate the dependency, don't lock yourself in early.

What to take away

• A meaningful share of your model calls doesn't produce text, it produces a value only your code reads. Count that share, it's bigger than you think, and it's billed at reasoning-engine rates.
• Jev gives up text generation to gain three things: a parallel pass instead of sequential decoding, output typed by construction, a probability trained to be honest.
• "Can't hallucinate" guarantees the shape, never the correctness. Your business-level evaluations remain entirely necessary.
• The published numbers, two orders of magnitude in both speed and price, are self-published and unreplicated. Order of magnitude, yes. Business plan, no.
• The effect to expect is the one Jevons described: a decision a hundred times cheaper won't shrink your bill, it will multiply the number of decisions you allow yourself to make.
• The useful action today needs no early access: name your decisions, put them behind an interface with a confidence threshold, give them an evaluation set.

This is the kind of tradeoff we settle during scoping, before half the latency budget goes into decisions nobody counted. It then gets implemented on an engagement around agents and workflows powered by language models, or inside an AI-first web product.