Jev Cannot Write a Sentence. It Sorted My Inbox for Half a Cent.

A Model That Cannot Write A Sentence

On September 15, 2026, a lab called TypeSafe AI came out of two years of stealth with $40 million, a founder who co-created ChatGPT and RLHF, and a model named Jev that cannot write a single sentence.

That is not a bug report. It is the pitch. Jev does not generate text. You hand it some content and a list of questions whose possible answers you wrote in advance, and it hands back typed answers with probabilities. TypeSafe calls this a System One model: fast gut judgment, no deliberation.

The launch page says 193.6x faster than frontier LLMs, $42 per billion input tokens, output free, and zero hallucinations.

I put it into a production SvelteKit app the same week. It sorted 74 real emails for less than half a cent and junked 12 of them without a single false positive. It also read a malware email as a genuine purchase order. Both of those facts matter, so here is the whole picture.

What You Are Actually Calling

Forget chat. The request has two parts: state (the thing to judge, ideally a small JSON object) and questions (a map of typed questions). There are exactly three question types.

Type	Use it for	What comes back
choice	One option from a set you define, up to 255 options	The pick, a probability for every option, a confidence
score	A position on a scale you describe in 2 to 10 steps	A probability-weighted score, probabilities per level
noul	A yes or no condition	One number from 0 to 1

A request looks like this:

{
  "model": "jev-1.13.0",
  "state": { "subject": "...", "body": "...", "sender_is_customer": false },
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "What kind of email is this?",
      "criteria": { "order": "Wants to buy specific products", "spam": "Unsolicited bulk mail", "other": null }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "Does the email convey genuine urgency?"
    }
  }
}

And the answer is already the shape your code wants:

{
  "answers": {
    "category": { "choice": "order", "probabilities": { "order": 0.98, "spam": 0, "other": 0.02 }, "confidence": 0.95 },
    "is_urgent": { "noul": 0.07 }
  }
}

No "respond only with JSON". No parsing. No retry because the model wrapped the answer in a friendly paragraph.

The part that changes how you design things: every question in a request is answered in parallel against the same state. Seven questions take about as long as one. TypeSafe's own cookbook measured 13 questions in one request at 12 times cheaper and 10 times faster than 13 separate calls. So you stop asking one big vague question and start asking many small literal ones.

The Price Is Real

Input is $0.042 per million tokens. Output is free. A typical email with seven questions costs about $0.00006.

Here is what that looks like at volume. Say you judge 100,000 support tickets a month, each around 500 tokens with its questions. That is 50 million tokens, or about $2.10 a month. Not $2,100. Two dollars and ten cents. The same job on a small frontier LLM at the benchmark's measured $0.03 per case is $3,000.

At that price the question stops being "can we afford to classify this" and becomes "why are we not classifying everything". Whole archives of tickets, chats, and logs that nobody ever read are suddenly cheap enough to tag. One community project sorted 1,018 research papers into 24 topics for 8 cents.

Latency is the other half. The docs say around 100 ms. Through OpenRouter, including the network, I measured 0.6 to 0.9 seconds per request regardless of how many questions were in it.

194x Faster Is The Best Case. 25x Is The Fair One.

Now the benchmark, because the headline number is doing some work.

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

Read that honestly and you get this: Jev ties the smaller frontier model, at about 1/76th of the cost and 25 times the speed. It sits five to six points below the best models. The 194x figure comes from comparing against the slowest baseline. TypeSafe itself calls it "on the higher end of real world gains".

Three more caveats, and to their credit TypeSafe states all of them. The test workflows were written by TypeSafe's own team. The reference answers came from other LLMs, so the score measures agreement with those models, not human ground truth. And no independent suite has reproduced any of it yet.

25x faster and 76x cheaper at equal accuracy is still a remarkable result. It just is not the number on the banner.

"Cannot Hallucinate" Means Less Than It Sounds

TypeSafe's zero hallucination figure is, in their own words, "not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots."

Translate that. Jev can only return one of the options you gave it, so it cannot invent a legal citation or a fake product name. The shape of the answer is guaranteed. The truth of the answer is not. It can pick the wrong option with a straight face, and unlike an LLM it cannot tell you why. There is no rationale, ever. If your decisions need an audit trail with reasons, that is a real gap.

The shape guarantee is still worth a lot. In the same benchmark, one small LLM produced broken structured output in 45.5% of cases and a large one fumbled 17% of its tool calls. Jev's rate for both is 0%, by construction.

What Happened When I Put It In Production

The first job was inbox triage for a B2B app. Every five minutes, new emails get one Jev request each: a 10-way category choice plus six yes or no questions (spam, phishing, is this an order, is this a prospect, needs a reply, urgent). The state holds the cleaned body plus facts that code already knows: is the sender a registered customer, have we ever written to them, did sender authentication fail.

Results on 74 real emails: 12 moved to Junk, zero false positives, genuine orders tagged correctly (most of them in Estonian, which the docs do not promise), total cost $0.0047.

It was not magic on the first pass. Four things went wrong, and each one taught me how this model thinks.

Confidence lied about spam. Jev split obvious junk between "spam" at 0.58 and "sales pitch" at 0.42, which produced a confidence of 0.53. It was certain the email was junk. It was unsure which flavor. Gating on confidence would have kept all of it in the inbox. The fix was to add up the probability of every category that leads to the same action.

It answers the question you wrote, not the one you meant. "Does the sender want to purchase?" fired at 0.96 on a simple quote request. Fair enough: someone asking for a quote does want to purchase. Rewriting it as "placing a concrete order, and asking for a quote is not an order" fixed it. Plan on one tightening pass like this per question.

It has blind spots that look like trust. A generic "Purchase Order attached" malware email was read as a real order. Phishing dressed up as a system notification scored 0.88 to 0.90, just under my threshold. Lowering the threshold is the wrong fix. A narrow extra question for that exact pattern, plus code signals (unknown sender, no product named, archive attachment), is the right one.

The delete path needs a guard the model cannot override. Moving mail to Junk requires spam or phishing at 0.92 or higher, junk-like categories summing to 0.9 or higher, and a sender who is neither a customer nor anyone we have ever emailed. That last check is plain code. It is the reason I was willing to switch auto-delete on at all.

The second job was reading 139 stored chatbot conversations nobody had time to read. One request each: topic, language, buying intent, was a question left unanswered, did they ask for a human. The useful tag turned out to be "missed lead": high buying intent from Jev, combined with a fact from code that no quote or contact request was ever submitted. Neither side could produce that alone. The whole archive ran in under a minute for well under a cent.

The third job I did not build with Jev at all. "Mark stale orders as shipped" sounded like an AI feature. But stale means a status, an age over five days, and a paid flag. That is a SQL query. If a rule decides it exactly, use the rule.

Where It Will Let You Down

• Anything generative. Replies, summaries, translations, explanations. It cannot do them.
• Math, counting, comparing dates or numbers. Do these in code and pass the result in as a fact.
• Multi-step reasoning. One hop of judgment only.
• Images, PDFs, audio. Text and JSON only. Convert first.
• Big messy state. The limit is 64k tokens, but accuracy drops long before that. I strip signatures and quoted threads and cap bodies at 6,000 characters.
• Hostile input. It has no special defense against text that argues for its own classification. Keep hard guards in code.
• Bit-exact repeatability. Identical requests drift by 0.01 to 0.03, so an item sitting on a threshold can flip. Pin jev-1.13.0 instead of jev-latest once your thresholds are tuned.

One more, and it is not technical. You are sending your customers' emails to a third party, or two if you go through OpenRouter. TypeSafe says requests are not used for training, and zero data retention is an enterprise option. Check that against what you promised your own users before you wire it in.

Use It Or Skip It

• You have an LLM call whose prompt says "answer only with one of these": replace it. This is the exact job Jev was built for, at roughly 1/76th of the price with nothing to parse.
• You have keyword lists or regex chains classifying free text: keep them as the fast path and send the misses to Jev.
• You run a chatbot or agent: put Jev in front as a router (intent, topic, wants a human, abuse) and behind as a checker. Most requests never need the expensive model.
• You have a review queue where most items are obvious: let Jev clear the confident majority and show humans only the uncertain tail.
• You need prose, reasons, arithmetic, or a chain of thought: this is the wrong tool. Use an LLM or plain code.
• A wrong answer is catastrophic and nobody reviews it: do not use any model, including this one.

The test I ended up using: could a knowledgeable person answer this in about a second, with everything they need on one screen? If yes, it is a Jev question. If they would have to think, calculate, or go look something up, it is code, a reasoning model, or a human.

Try It On Fifty Real Items First

Jev is in early access through console.typesafe.ai, and it is also reachable through OpenRouter's alpha decisions endpoint, so if you already have an OpenRouter key you can try it today.

Do not start with a demo. Pull 50 to 200 real historical items, write five narrow questions, and run them in a dry-run mode that logs decisions without acting on them. Then read the wrong ones. For each mistake decide what failed: missing state, a vague instruction, overlapping options, or your threshold. Fix that layer and nothing else.

My entire evaluation cost less than a cent. The expensive part was admitting how many of my "AI features" were really an if statement that needed to read English.