What Is Jev? TypeSafe AI's System One Model, and Why It Refuses to Talk

On September 15, a startup called TypeSafe AI came out of two years of stealth with a model that will not talk to you. It does not write emails, it does not explain itself, and it cannot produce a single sentence. Three days later, according to TechCrunch, demand was high enough that the company briefly ran out of API capacity. The model is called Jev, and it is the most interesting thing to happen to the "LLM in production" problem since DeepSeek repriced inference.

Here is the short version. Jev is a transformer that skips autoregression. Instead of generating text one token at a time, you hand it the state of your program and a list of typed questions, and it answers all of them in one parallel pass with calibrated probabilities. TypeSafe calls this class of model a System One Model, after Daniel Kahneman's fast, intuitive System 1, and pitches it as 40 to 200 times faster and far cheaper than a frontier LLM for the decisions most software actually needs. I have spent the past few days reading everything published about it, and most of the coverage gets the important part wrong: Jev is not a smaller, dumber LLM. It is a different output contract, and that contract is the whole story.

What Jev Actually Is

TypeSafe AI was founded in 2024 by Diogo Almeida, a former OpenAI researcher and co-author of the InstructGPT paper, which is the work that turned GPT-3 into ChatGPT. Per heise, the company announced $40 million in seed funding when it launched. Almeida's stated frustration is the one every engineer who has wired an LLM into a pipeline has felt: models optimized for pleasing humans in a chat window are a poor fit for software that needs a decision. "Computers speak a different language," as he put it to TechCrunch.

The API, documented at docs.typesafe.ai, is a single endpoint. You send a state, which is the thing to evaluate (a plain string or a structured object), plus a map of questions. Every question is one of three primitives:

• Noul: a yes/no question. Returns the probability, from 0 to 1, that the statement is true.
• Choice: pick one option from a set you define, up to 255 options. Returns the chosen option, the full probability distribution, and a confidence score.
• Score: rate the state against 2 to 10 ordered levels you describe. Returns a probability-weighted value across the levels, plus the distribution and confidence.

A request looks like this:

json
POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>

{
  "model": "jev-latest",
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and support hasn't replied. We go live Monday.",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    },
    "category": {
      "type": "choice",
      "options": ["billing", "integration", "bug", "sales", "other"]
    },
    "tone": {
      "type": "score",
      "levels": ["calm", "frustrated", "furious"]
    }
  }
}

And the response is exactly the shape you declared, nothing more:

json
{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": { "type": "noul", "noul": 0.999 },
    "category": {
      "type": "choice",
      "choice": "integration",
      "probabilities": { "integration": 0.88, "billing": 0.07, "bug": 0.03, "sales": 0.01, "other": 0.01 },
      "confidence": 0.81
    },
    "tone": {
      "type": "score",
      "score": 1.05,
      "probabilities": { "calm": 0.12, "frustrated": 0.71, "furious": 0.17 },
      "confidence": 0.64
    }
  },
  "usage": { "input_tokens": 296, "output_tokens": 20 }
}

Every question in the request is evaluated in parallel against the same state, so asking twelve questions costs about the same as asking one. TypeSafe's design guidance is "atomic questions, composed in code": decompose the judgment into small typed queries, then combine them with ordinary if statements. There are official Python and JavaScript SDKs, and LangChain already ships a TypeSafeClassifier integration that plugs Jev in as routing and tool-gating middleware.

That is the entire surface. No completions, no chat, no streaming, no strings.

How It Differs From the Models You Have Been Using

Here is the side-by-side that matters, using TypeSafe's published figures where numbers appear:

	Autoregressive LLM (GPT, Claude, Gemini)	Jev
Output	Tokens, generated one at a time	A fixed set of typed answers, produced in one pass
Shape of the answer	Free text (or JSON) you must parse and validate	Probabilities over options you declared
Training objective	RLHF or RLVR: text humans prefer, or verifiable outputs	RLCD: probabilities that match observed accuracy
Typical latency	Seconds, to minutes with reasoning enabled	70 to 500 ms (TypeSafe's measurement)
Pricing	Input and output metered; output about 5x input	$0.042 per million input tokens; output free
Can explain itself	Yes	No
Can produce malformed output	Yes, even with structured-output modes	No, by construction
Reads images	Most frontier models do	Not yet

Three of those rows are the real differences. The rest follow from them.

It does not decode, so it does not pay the decoding tax

If you have read my honest accounting of local models versus frontier APIs, you know the physics: autoregressive generation is memory-bandwidth bound. Every output token requires reading every active weight from memory once, and a 500-token answer means 500 sequential trips. Prefill, where the model ingests the prompt, is the compute-bound, highly parallel part. Jev is, roughly speaking, all prefill. The state goes in, one forward pass produces the logits for every question at once, and there is nothing to decode. TypeSafe describes this as "a parallel sampler that generates all outputs in a single query," and it is why the latency numbers are in milliseconds rather than seconds. It is also why output tokens are free: there are barely any.

This is the same reason a chain-of-thought LLM gets slower and more expensive the harder you ask it to think. Jev cannot think out loud at all, which is a limitation and a feature in the same breath.

It was trained for calibration, not for approval

InstructGPT introduced the world to RLHF: train a reward model on human preferences, then optimize the language model against it. Almeida helped build that, and TypeSafe's launch post is blunt about the side effects, listing "mode dropping, overconfidence, and lack of reliability." A model trained to produce text people rate highly learns to sound sure.

Jev uses what TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD). The reward is not "did a human like this" or "did the program pass the test," but whether the model's stated probability matched how often it was actually right. The goal is that a 0.9 means 90%, across the population of decisions. Almeida told TechCrunch the training data is entirely synthetic: "We made an early bet that we will be making all of our data, and that has been one of the best bets I've ever made."

This is the part I find most credible, because it targets the exact failure that makes LLM classifiers painful in production. Ask a chat model for a probability and you get a number that is confidently wrong in both directions. Reading the logprob on a constrained answer token is better, but post-RLHF logprobs are notoriously miscalibrated, and you are still paying LLM latency and LLM prices for a one-token answer.

The schema is the output, so there is nothing to parse

With an LLM you ask for JSON and then defend against the day it returns a paragraph, a trailing comma, or a category you never defined. With Jev the valid answers are declared in the request, and the model's output layer only ranges over those. TypeSafe reports a 0% structured-output error rate and a 0% tool-call error rate, and for once that is not a benchmark result, it is a property of the architecture. The DataCamp write-up puts it well: hallucination in the sense of "invented an option" is mathematically impossible.

Hold that thought, because it is narrower than it sounds.

What Is the Same

It is easy to over-rotate on the differences, so here is what did not change.

Jev is still a transformer reading text. The "state" is a prompt by another name, and the instructions field on a question is prompt engineering by another name. Wording matters, order matters, and the same brittleness you have learned to expect from prompts is still in there somewhere. It still bills by input tokens, and a big state costs proportionally more. It is still a black box: you get a distribution, not a reason. And it still has a training distribution. Calibration is a statement about inputs that look like the ones it was trained on. Feed it a genre of ticket it has never seen and the 0.9s stop meaning 90%, silently, which is exactly the failure mode that makes distribution shift dangerous in any classifier.

Most importantly, it can still be wrong. In that field report on the state of AI I described a support pipeline that confidently told a customer about a refund policy that has never existed. Jev could not have produced that sentence, because it cannot produce sentences. But asked "Is a refund owed?" it could still answer 0.8 when the correct answer is no. What you would get in exchange is a 0.8 that, over thousands of tickets, has been trained to track reality, and a threshold you can tune against it.

The Numbers, and Who Measured Them

TypeSafe's launch post claims 40 to 200 times faster and "444.6x cheaper" on System One shaped queries. The four-workflow comparison it published, as reported by DataCamp, looks like this:

Model	Accuracy	Cost per case	Latency
Jev	67.8%	$0.0004	0.4 s
GPT-5.6 Terra	67.9%	$0.0304	10.1 s
GPT-5.6 Sol	74.1%	$0.0836	23.3 s
Claude Opus 5	73.1%	$0.1761	37.8 s

Read that honestly. On accuracy, Jev matches the mid-tier frontier model and trails the top-tier ones by about six points. On cost and latency it is two orders of magnitude better than everything. The pitch is not "smarter"; it is "the same decision for 1% of the price in 1% of the time." Pricing is $0.042 per million input tokens, which TypeSafe frames as $42 per billion, and output is unmetered.

Now the caveats, which TypeSafe itself partly volunteers. The reference labels in that benchmark were produced by averaging other LLMs' answers, not by humans, and the company acknowledged possible design bias and described the advantage as probably near the upper end of what you would see. There is no paper, no published calibration curves, and no independent reproduction yet. Anthony Maio's skeptical read makes the strongest version of that argument: calibration is a population-level property, a perfectly calibrated model that just emits base rates contributes nothing, and reinforcement learning for calibration is not itself new.

What we do have from third parties is early and encouraging. TechCrunch reports that Vercel measured Jev at 5 to 18 times faster than OpenAI's Luna model on safety classification with better accuracy, and that Bryo AI found it 10 to 20 times cheaper than Gemini while returning real probability scores instead of made-up ones. Pat McGuinness points out that a 421-million-parameter open model called Laya already performs comparably on the same classification categories, which suggests the architecture is reproducible and that we will see open-weight versions soon.

"Cannot Hallucinate" Means Something Narrower Than It Sounds

I want to spend one section on this because the phrase is doing a lot of marketing work.

There are two ways a model can fail you. It can produce an output that is not in the set of valid outputs, or it can produce a valid output that is wrong. LLMs do both; the first is what "hallucination" usually means when someone's agent invents a function that does not exist. Jev eliminates the first category completely, and that is genuinely valuable, because the first category is what makes LLM integrations fragile: every retry loop, every regex, every "the model returned Markdown fences around the JSON again" bug lives there.

It does nothing about the second category except promise to tell you the truth about its own uncertainty. That is a real improvement, and it is also the thing you have to build your system around. A calibrated 0.55 on "is this a jailbreak attempt" is not a decision, it is a request for a policy. You still need thresholds, and your thresholds are now coupled to one vendor's probability distributions, which means a model version bump can shift them under you. Maio's point that systems needing appeals or debugging will need separate infrastructure is correct: there is no explanation to show a customer, and no chain of thought to inspect when a routing decision was bad.

Haven't We Had This Before?

Yes, in pieces, and the comparison clarifies what is actually new.

A fine-tuned classifier. A DeBERTa-sized model fine-tuned on your ticket taxonomy has been the right answer to "classify at volume, cheaply" for years, and I still recommend it. The catch is that it needs labeled data per task and it cannot follow instructions. Add a category and you retrain. Jev is zero-shot: the categories are in the request.

LLM logprobs on a constrained answer. You can ask a frontier model "Answer A, B, or C" and read the token probabilities. It works, and it is how a lot of teams do routing today. But the probabilities are poorly calibrated after RLHF, and you pay the full LLM latency and price for a single token.

Structured outputs and JSON mode. These solve the format problem, mostly. They do nothing for calibration, and nothing for cost, since the model still decodes the JSON token by token.

Jev is the combination: an instruction-following, zero-shot classifier with calibration as the training target, packaged behind a schema-first API with the decoding step removed. None of the three ingredients is novel. The integration is, and so is the price.

Where I Would Put It in a Production Stack

If you have read my routing heuristic before, you already know the answer: cheap model handles the 80% of traffic that is classification and extraction, expensive model handles the 20% that is genuinely hard, and a confidence check decides which is which. Jev is the best-fitting piece of hardware for that confidence check I have seen. Concretely:

1. Model routing. Before a request hits any LLM, ask Jev "does this need the capable model?" and route on the answer. LangChain's harness does exactly this as middleware.
2. Tool-call gating. An agent proposes a shell command or a database write; Jev scores "is this action destructive" and "is this within the user's stated intent" in a few hundred milliseconds before anything executes. This is the guardrail pattern most agent frameworks are bolting on right now, and it is where the zero-malformed-output guarantee matters most.
3. Triage at volume. Ticket routing, content moderation, email classification, spam and jailbreak detection. Anything where a human already wrote the taxonomy.
4. Map-reduce over big data. Run the same three questions over ten million records. At $42 per billion input tokens with free output, that is a batch job, not a budget line.
5. Real-time loops. TypeSafe's demos include a bot playing Doom and a Wikipedia-racing agent. Games, robotics, and simulations need a decision every frame, and nothing that decodes text can keep up.

The cascade in code is about ten lines:

python
import requests

def decide(state, questions):
    r = requests.post(
        "https://api.typesafe.ai/v1/systemone",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"model": "jev-latest", "state": state, "questions": questions},
        timeout=5,
    )
    r.raise_for_status()
    return r.json()["answers"]

answers = decide(ticket_text, {
    "needs_human": {"type": "noul", "instructions": "A human agent must handle this"},
    "category": {"type": "choice", "options": CATEGORIES},
})

if answers["needs_human"]["noul"] > 0.7 or answers["category"]["confidence"] < 0.6:
    escalate_to_llm_or_person(ticket_text)      # the expensive path
else:
    route(ticket_text, answers["category"]["choice"])   # the cheap path

The two thresholds in that if are the entire product decision, and they are yours to measure and tune. Which brings me to the other half.

Where It Does Not Fit

Do not reach for Jev when:

• You need text. Summaries, replies, code, explanations. Jev gives up string generation entirely.
• The answers are not enumerable. If you cannot write the list of valid outputs before the request, it is not a System One task.
• Someone can appeal the decision. Loan denials, moderation with a human review queue, anything regulated. A probability with no rationale is a liability there.
• The input is an image. TypeSafe says structured state as text only, with images marked "yet."
• Your inputs drift. New products, new languages, new attack patterns: calibration degrades quietly, and you will not know until you measure it.
• You need it to reason. TypeSafe notes lower performance on high-reasoning tasks without reasoning modes, which is a polite way of saying that the model that cannot think out loud is worse at problems that require thinking out loud.

It is also early access, from a company that briefly could not serve its own launch traffic, with pricing that several commentators have questioned as sustainable. Build the abstraction layer so the decision engine is swappable. That is good advice for any vendor; here it is essential.

What I Am Watching

Three things will tell us whether this is a category or a product. First, an independent benchmark with human-labeled ground truth and published calibration curves; until then, every number in this post is TypeSafe's. Second, open reproductions: if a 400-million-parameter model gets most of the way there, the frontier labs will ship their own decision heads within a year and the price war starts. Third, whether the calibration survives contact with real distribution shift in someone else's production logs.

My bet is that the category is real even if the company's lead is not permanent. We spent three years forcing a text generator to act like a decision function and paying for every token of the disguise. Jev is what it looks like when someone builds the decision function directly. The decisions in your system that have a known answer set were never LLM problems. They were waiting for something like this.

Sources: TypeSafe AI launch post, TypeSafe API docs, TechCrunch, heise, DataCamp, LangChain, Anthony Maio, Pat McGuinness.