TypeSafe's Jev returns typed decisions with probabilities instead of text, in a few hundred milliseconds, for a fraction of a cent. The product may or may not last. The split it exposes will: models are starting to specialise by the shape of what they return, and a judgement that costs 100 ms can sit inside a hot path the way a regex does.
On 15 September a company called TypeSafe AI launched Jev, which it calls the first “System One Model”, and the Hacker News thread went to nearly two thousand points. Jev takes text or a JSON blob of program state, plus a set of questions you define in advance, and returns answers of three kinds: a yes/no probability (which TypeSafe calls a “Noul”, short for Bernoulli), a choice across up to 255 options, or a score along an ordered scale. It does not generate text at all. TypeSafe reports response times of 70 to 500 milliseconds, input at $0.042 per million tokens, and output that is free because there are no output tokens to speak of. The name is a nod to William Stanley Jevons: the bet is that cheaper judgement makes people use a great deal more of it.
The thread’s sceptics were quick and mostly correct. One commenter’s entire review was “So… a classifier model?” Others pointed out that constrained decoding has given us schema-valid output from ordinary LLMs for years, that the headline benchmark was built by TypeSafe’s own team and scored against an average of two other vendors’ models, and that “can’t hallucinate” is a claim about types, not truth. Within a week there was a parody post implementing “Jev in 25 lines of Python”, an open family of clones called Kev built on Qwen, and an essay arguing OpenAI could fold the whole thing into its own models in short order.
We agree with nearly all of that, and we still think Jev is the most interesting model release of the month. The reason sits somewhere other than Jev’s accuracy.
For three years “the model” has meant one kind of thing: a system that produces strings, one token at a time, for a person to read or for a harness to parse. Everything else (tool calls, JSON, a yes or a no) was a string wearing a costume. We sized models by parameters and picked them by price per million tokens, but the interface never changed.
Jev is a clean example of the interface changing. When the output space is fixed in advance, you no
longer need to generate it. All the answers can be computed in one pass, so a call with forty
questions costs roughly what a call with one costs, and the latency is set by reading the input rather
than by writing an essay. TypeSafe’s CEO put it in programmer’s terms in the launch thread: a choice
maps to a match statement, a score maps to sorting, and a Noul maps to an if. His stated hope was
to let people use AI “much more in the inner loop of software”.
That is the mechanism, and it is bigger than one company. A model whose output is a string is priced and timed for a person waiting at the other end. A model whose output is a typed value with a probability attached is priced and timed for a program waiting at the other end. Those are different products with different economics, and the second one competes with regular expressions, lookup tables and hand-written rules, not with chat.
The history of computing is full of this kind of split. We did not get one bigger CPU; we got GPUs, DSPs and network cards, each shaped by what it had to emit. We expect the same with models. The frontier will keep pushing System 2 models towards longer reasoning and more autonomy. Next to it, a second frontier will push decision models towards lower latency, better calibration and more options per call, and that frontier is measured in milliseconds and fractions of a cent.
When a judgement takes ten seconds and costs a cent, it is a feature: a button a person presses, a summary they wait for. When it takes a tenth of a second and costs a small fraction of a cent, it is a branch. You can put it in a request handler, run it on every row in a table, or call it ten times a second in a game loop. TypeSafe’s Doom demo did exactly that, at a reported cost of about $7 an hour for ten queries a second, working from a text description of game state rather than pixels (the thread was right to point that out).
The early experiments people reported are telling for how ordinary they are. Simon Willison used it to rerank a hundred BM25 search results for relevance. A commenter in the launch thread drove a browser agent by having Jev pick one of ten to forty clickable elements per step, leaving a small language model to type text when Jev chose “type”. Another turned it into a chess opponent by feeding it only the legal moves. None of that needed a string. All of it needed a decision fast enough to sit inside code.
That last pattern is the one to notice: the decision model and the string model working together. The LLM writes, plans and explains. The decision model routes, scores, gates and verifies, cheaply enough to check every step the LLM takes.
Mechanically, yes, and TypeSafe’s CEO agreed with a commenter who called it a zero-shot classifier. Another commenter reported 95 per cent accuracy on email with an embeddings-plus-logistic-regression model trained on 50 to 100 examples, under a megabyte and under 100 ms. Another asked why they would use a general model for fraud when a quick XGBoost model trained on their own data would be more accurate, and concluded that they need an accurate fraud model, not a general one. Both are right. If you have labelled data and one narrow, high-volume task, train the specific model. The case for a decision model is the long tail: the forty small judgements in a codebase that each happen too rarely to justify a labelling project and a training pipeline, and that are currently either a brittle hand-written rule or a slow LLM call. The founder’s phrase for it, quoted into the thread from X, “zero-shot + general == programmable”, is marketing, but it is also the actual point.
It does, and one commenter noted that the big providers already compile a JSON schema into a grammar behind the scenes. You can also read the logprobs of “yes” and “no” off any open model, which is what the 25-lines post does. Two things differ. First, cost and time: a constrained LLM still pays for sequential generation and reasoning, where a fixed output space can be computed in parallel. Second, TypeSafe’s CEO argued in the thread that masking invalid tokens makes models worse, because if the model wanted to put probability on an invalid token it was already confused, and you would be better off with an error. That is a claim, not a finding, but it is the right question to test on your own data.
Correct, and TypeSafe says so. Its workflow evals were built by members of its own team and score every model against the average of GPT-6 Astra and Fable 5.1, not against ground truth. A commenter summed up the result as measuring “how much of a Fable am I getting”, and noted that on the first plot Jev sat below Sonnet 5 on accuracy. The 193.6x faster and 444.6x cheaper figures come from those evals, and TypeSafe itself expects them to be at the high end of real-world gains. The preview terms also carried a no-benchmarking clause, which the JevBench thread reported was left over from the limited preview. The one independent test in our reading, a single developer’s run over 770 Reddit posts, found Jev second of seven setups, slightly behind Sonnet 5, with a median call 6.3 times faster: fast, and far from 200 times. Calibration took knocks too. Alex Molas argued that calibration is a property of your data, not only of the model, and recommended fitting a Platt scaling on a few hundred of your own labelled examples. A commenter’s coin and die tests got a 0.92 probability for heads on a fair coin.
Possibly. Clones appeared within days, and the Arcturus Labs essay makes a plausible case that a frontier lab could train the same behaviour into its own models. Commenters who tried the open clones reported them doing much worse than Jev on linguistic tasks, which suggests the value is in the training data and the RLCD recipe rather than the architecture. One outside reading of RLCD describes it as reward modelling promoted to the product: “the reward model becomes the model”. None of this bears on our claim. The best reply in the Arcturus thread asked whether Jev got the interface right, and waved away the talk of moats “when there’s no castle”. If OpenAI ships a decision endpoint next quarter, the split by output shape has been confirmed, not refuted. The Monday question for a CTO is which of their calls are decisions, and that question does not depend on which vendor wins.
Here is how we would redesign a support-ticket router around a typed decision call. It is a composite of the triage systems we see, not a client, and the arithmetic uses TypeSafe’s reported price.
The usual current version sends each ticket to a frontier LLM with a long prompt: read this, decide the queue, decide the urgency, return JSON. It takes several seconds, needs a parser and a retry path for malformed output, and gives no honest sense of when it is guessing. So everything goes through a human check anyway, and the model saves less time than the demo promised.
The redesign splits the one big judgement into small ones, following a suggestion from one of the Hacker News threads: ask several specific, objective yes/no questions rather than one vague “how urgent is this?”, because narrow questions are more stable across models and easier to audit.
The single call asks four Nouls (does this mention a charge? is the account locked? is there a legal or regulatory threat? is the customer asking to cancel?), one Choice across eight queues, and one Score for how much of the customer’s work is blocked. The answers come back together, and ordinary code does the rest: a legal threat above 0.8 goes straight to the escalation queue whatever the Choice says; a queue choice with high confidence routes automatically; anything in the uncertain middle goes to a person with the probabilities attached. The LLM still drafts replies, where strings are the point.
The cost changes category. At 20,000 tickets a day and roughly 800 tokens each, that is 16 million input tokens, or about 67 cents a day at the reported price. The more important number is the latency: under half a second means routing can happen inside the request that created the ticket, before the customer has closed the tab, so the confirmation page can already say which team has it.
Two pieces of discipline make it safe. First, recalibrate on your own tickets: label a few hundred, fit the scaling, and set your thresholds against measured precision, not the model’s own numbers. Second, log every probability. When routing goes wrong, you have six numbers to look at instead of one paragraph of model reasoning, and the fix is usually a threshold or a better-worded question.
Decision models can be wrong with great confidence, and “can’t hallucinate” should be read as “can’t return a type you did not define”. There is no “none of the above” unless you add one. Willison’s worry about black boxes is fair: a floating-point number tells you even less about its reasons than a chatty LLM does, which makes a decision model a poor choice for anything that needs to justify itself to the person affected, such as ranking job applicants. Some teams will do better with a small model trained on their own data, and some calls that look like decisions actually need reasoning. And Jev may not survive; the category can win while the first company in it loses.
Grep your codebase for LLM calls and sort them into two piles. Strings for a person: summaries, drafts, explanations. Decisions dressed as strings: anything whose output you parse into a boolean, an enum or a number before your code acts on it. The second pile is usually larger than people expect.
For each decision, write down how many times a day it runs and how long its caller waits. The ones with high volume and a waiting caller are where a typed decision call pays for itself. Take one, break it into narrow questions, label a few hundred real examples, and compare a decision model, a constrained LLM and a small trained classifier on accuracy, calibration, latency and cost. That experiment costs a few dollars. It tells you more than any launch thread.
The model that writes your emails will keep getting smarter. The one that matters more to your systems may be the one that answers yes or no in a tenth of a second.
Support automation, AI phone agents, n8n back-office work, and the engineering loop itself — always behind a gate you control.