Jev Cannot Write a Word. I Ran 40 Tickets Through It and Four Models That Can. It Won.

TypeSafe's Jev answers in 370 milliseconds for two hundredths of a cent. The speed is not the interesting part.

A model came out last Tuesday that cannot write a sentence. That is not me being rude about its prose. The response contains no text anywhere in it.

I ran 40 support tickets through it and through four models that can. It was ten times faster than Claude Fable 5.1 and three hundred and twenty nine times cheaper, and it beat Fable at guessing how annoyed the customer was.

The model is Jev, from a lab called TypeSafe AI that spent two years in stealth on $40 million. The founder is Diogo Almeida, who worked on the instruction-following research that became ChatGPT and then, by his own account, spent four years asking why superhuman chat had not produced any actual automation.

His answer was to stop making models talk.

What it actually is

You hand Jev a blob of unstructured state and a set of typed questions. It hands back typed answers. That is the entire surface.

Three question types. A choice picks one of up to 255 named options. A score lands on an ordinal scale you define. A noul is the yes-or-no one, except it does not come back as yes or no, it comes back as a probability.

Here is a real call and a real response, from my terminal this morning:

{ "state": "Support ticket: my card was charged twice
             and nobody has replied in 3 days.",
  "questions": {
    "team":   { "type": "choice", "criteria": {
                  "billing": "payments and refunds",
                  "shipping": "delivery",
                  "technical": "bugs" } },
    "urgent": { "type": "noul" },
    "anger":  { "type": "score", "criteria":
                  ["calm","annoyed","angry","furious"] } } }

-> { "team":   { "choice": "billing", "confidence": 1 },
     "urgent": { "noul": 0.85 },
     "anger":  { "score": 2.07, "confidence": 0.92 } }
     403ms, $0.0000172

Note the anger score. It is 2.07, not 2. The model is telling you this customer is a hair past angry and drifting toward furious. You can sort a queue by that. You cannot sort a queue by the word "angry".

The architecture is the reason it is fast. Normal models generate one token at a time, each one conditioned on the last, which is a sequential chain you cannot escape. Jev uses a parallel sampler and produces every output in a single pass. TypeSafe points out that this is the same trick Transformers used on RNNs, which is a cheeky thing to say about your own launch and also true.

The name is a joke with a point. It is after William Stanley Jevons, whose paradox says that when you make a resource cheaper, you consume more of it, not less. Cheaper steam engines burned more coal. The bet is that decisions at $0.042 per million tokens do not save you money on the classifying you already do. They make you classify a thousand things you never bothered with.

The benchmark

I wrote 40 customer support tickets and labelled all of them myself: which of four teams should get it, does it need attention today, how angry is the person on a 0 to 4 scale. Then I sent the identical three questions to five models through OpenRouter, giving the four LLMs a strict JSON schema so nobody was handicapped by parsing.

The labels are mine, so read "accuracy" as agreement with one opinionated human in Katowice, not ground truth. I have written about why most benchmarks are worth less than they look, and I am not going to pretend 40 tickets is a lab result.

Anger error is mean absolute error on the 0 to 4 scale, so lower is better. All five models returned 40 valid structured answers out of 40. Nobody broke their schema, not once, which is worth saying because "LLMs mangle your JSON" is the usual argument for this whole model class.

One dollar buys 51,613 Jev triages. Or 2,049 Haiku ones. Or 157 from Fable.

Run the same 40 tickets ten at a time and the whole batch finishes in 2.6 seconds. That is 15 decisions a second from my kitchen table with no batching API and no infrastructure.

Two things in that table surprised me

The first is that Haiku 4.5 is the real competition, not the frontier models. It tied Jev exactly on reading anger, beat it on routing, and did it in 1.2 seconds for half a tenth of a cent. Jev is still three times faster and twenty five times cheaper, which matters at volume and does not matter at all if you are doing eleven of these a day. I moved a pile of my agent's work to Haiku last year and got better results for less money. That lesson did not expire this week. It got a new floor under it.

The second is that GPT-6 Astra came last on both judgement questions. The most expensive model in the table, the one that thinks the hardest, was the worst at guessing whether a customer was angry and whether a ticket was urgent. It burned four hundred output tokens deliberating over a two-line complaint and got further from the answer.

That is the Kahneman point landing in a spreadsheet. Some questions are System 2 and deserve deliberation. "Is this person annoyed" is System 1, and thinking harder about it makes you worse, in models and in people. I have watched the same failure in my own setup, where Fable was so good at the work that I stopped noticing the 85 things wrong underneath it. Capability is not the same as fit.

The number that actually matters

Speed and price are the headline and they are the least interesting thing here. Every model gets faster and cheaper eventually. What you cannot get from a normal model is the second number.

TypeSafe trained this thing with something they call Reinforcement Learning for Calibrated Decisions. The claim is that the confidence it reports means something, as opposed to RLHF models, which will cheerfully tell you they are 95% sure because that is the kind of thing a helpful assistant says.

So I checked. I took Jev's 40 answers on the urgency question, bucketed them by how confident it said it was, and measured accuracy inside each bucket.

Monotonic. The number means what it says.

And the detail I keep turning over: on the routing question Jev made exactly one mistake across 40 tickets. Ticket 33 was a shipping complaint that ends "I am done, cancel everything", which I labelled shipping and it called billing. That answer came back with a confidence of 0.33, the lowest score in the entire run.

It got one wrong and it told me which one.

That is the thing a regex has never once done for me, and the thing a chat model does badly, because models are famously terrible at knowing what they do not know. Five of sixteen models I tested earlier this year named a dead man as the King of Norway, and none of them hedged.

The pattern this unlocks, and where it falls apart

Here is the obvious move. Put Jev in front of the expensive model. It answers everything, and anything it is not confident about gets escalated to a frontier model. Cheap reflex in front, slow brain behind, and you only pay for the brain when the reflex says it is out of its depth.

I ran the numbers on my batch. Gate on the routing question at 95% confidence:

• 4 of 40 tickets escalated, so you call the expensive model 10% of the time

• the 36 that Jev handled alone were 100% correct

• the batch cost $0.026 instead of $0.255, so 9.7 times cheaper, and more accurate than Jev alone

Then I ran the same gate on the urgency question and it fell apart completely. At the same threshold you escalate 38 of 40. You have built an expensive proxy for Fable with an extra network hop.

The reason is the shape of the confidence, and this is the bit I have not seen anyone write down:

Choice questions come back bimodal. Jev is either certain or visibly lost, which is exactly what you need to route on. Fuzzy judgement calls come back clustered in the middle, because "is this urgent" genuinely is a middle-of-the-road question and a well-calibrated model is right to say 0.78.

So the rule I came out with: gate on the sharp questions, and on the soft ones take the probability as the answer instead of thresholding it. A 0.78 on urgency is not the model failing to decide. It is a ranking key. Sort the queue by it and work down.

Although that took me most of a morning to see, it is the kind of thing that makes or breaks the economics, and if you are wiring cheap models into a real pipeline it is the first thing I would measure. It is the same discipline as tracking where the tokens actually go: the savings are never where the pitch deck says they are. I put the working version of this into the Agent Efficiency Kit if you want the harness rather than the write-up.

Where I would actually put this

Not in place of Fable. Nowhere near it. Jev in a chat window is useless, and that is not a criticism, it is the design.

The slot it fills is the one between a hardcoded if statement and a model call you have to budget for. That slot has been empty for years, and it is enormous. Every place I have ever written a regex and known it was wrong. Every place I skipped the check entirely because a model call was too slow or too expensive to put in that loop.

• In front of an agent. Before you spend 8,000 tokens of Fable's attention, spend 370 milliseconds deciding whether this task needs Fable at all. My agent already routes across models; this is a cheaper dispatcher than the one I have.

• As a judge inside a loop. Did that step actually do what it claimed? An LLM judging an LLM costs about as much as the work. At two hundredths of a cent you can check every step.

• On real-world data. Sensor readings, log lines, telemetry. Nobody puts an LLM on a 10Hz stream. At 15 decisions a second and $7 an hour flat out, you can.

• Moderation and triage. The obvious one. Inbox, support queue, comment stream, alert firehose.

• Reacting to a human. Anything where a person is waiting. 370ms is under the threshold where a UI feels like it is thinking. Four seconds is not.

That last one is what I keep coming back to. Every model I have wired into something interactive has had the same problem, which is that it is too slow to sit between a person and a response. Multi-model workflows solved cost and quality and did nothing about latency. This does latency.

Go break it yourself

Reading a table about a 370ms model is a bad way to understand a 370ms model. So I built the thing instead.

wiz.jock.pl/experiments/reflex replays one real run, captured on 21 September. Three parts. The first races Jev against a frontier model on the same ticket, both clocks running at the speeds they actually hit, which is a stupid amount of fun the first time you watch one lane stop and the other keep going. The second is a stream of tickets being classified continuously so you can watch the running cost stay in fractions of a cent. The third is the gate, with a threshold slider, showing what you save and what you give up at every setting.

Recorded, not live, and the reason is the post. A public page that fires a paid API call on every click is a bill with a stranger's finger on it. I had it running live for a few hours and then did the arithmetic: one race against Fable cost $0.0178, so twenty eight clicks from one bored visitor would have emptied the day's budget.

Capturing the whole thing cost 16 cents, and the receipt is the argument in miniature. Forty nine Jev calls came to $0.00095. The fifty one calls to Gemini, Haiku and Fable came to $0.161. Same questions, same tickets, same afternoon. The cheap one is not a rounding error on the bill, it is 0.6% of it.

Every latency and every price on that page is measured. Nothing is modelled, nothing is smoothed, and the Jev answers that took three attempts to land took three attempts because TypeSafe kept falling over.

What it cannot do, plainly

No text. No summaries, no rewrites, no explanations, no code. No vision. 32k of context, which rules out the long-document work you might be tempted to throw at something this cheap. A ceiling of 255 options on a choice, above which it switches to a slower two-stage approach.

"Zero hallucinations" is true in a narrow and slightly annoying sense: it cannot produce a malformed answer because the shape is fixed in advance. It can absolutely give you the wrong answer inside that shape. It gave me eight of them on urgency.

And it is early access, which shows. Mid-testing I hit 529 system_overloaded five times in six calls before it came back. The 370ms is real when the service is up, and launch week means it is not always up. If you are considering this for anything that matters, that is the number to watch, not the benchmark.

The headline claims on the TypeSafe site, 193.6 times faster and 444.6 times cheaper, come from their own four workflow evals with reference answers averaged from GPT-6 Astra and Fable 5.1. My numbers are smaller and measured, and I would trust neither set without running your own.

What I think is going on here

For three years the industry has had one answer to every problem, which was a bigger model with a chat interface bolted to it. This is the first thing I have used that walks away from that shape on purpose, and it is quietly aggressive about it. There is no chat, no strings, no assistant persona waiting to be helpful. You call it the way you call a function.

I do not know if TypeSafe survives. Early access, one product, prices they admit might be subsidised, and every large lab could ship a competitor in a quarter if they decided the category was real. I would not rewire anything load-bearing around it yet.

But the idea survives regardless of who ships it. Most of what I want a model to do in a day is not thinking. It is judging, fast, in a loop, on data no human will ever read. Paying frontier prices and waiting four seconds for that has always been absurd, and I had stopped noticing it was absurd because there was no alternative.

There is one now. It cannot write a word, and I have not enjoyed using a model this much in a year.

If you build things where a model sits in a loop rather than in a chat window, this is the corner of the field I am going to keep digging in. I write one of these a week, usually with the numbers attached and the failures left in. Subscribe and you will get the next one.