When a judgement costs nothing, the scarce thing is knowing which judgements to make.

The launch did what it said on the tin, mostly

Start with the part that is genuinely impressive, because most of the reaction this month has been people trying very hard not to be impressed.

On 15 September TypeSafe AI launched Jev, which it calls the first “System One Model”. You hand it a chunk of state (a support ticket, a customer record, a game frame described as JSON) and a list of questions, and it hands back typed answers with probabilities attached: a yes/no, a choice from options you defined, or a score on a scale you wrote. It does not generate text, so it cannot return something outside the shape you asked for. As reported by TypeSafe, it answers in 70 to 500 milliseconds, charges $0.042 per million input tokens and nothing at all for output, and on the company’s own published workflows came out 193.6 times faster and 444.6 times cheaper than the language models it was compared against. The company says itself that those multiples are at the high end of what to expect.

The demo that made people sit up was Doom. Jev was fed a structured description of the game ten times a second and asked what to do next. The engineer who built it, TypeSafe reports, was worried about the bill, which came to about seven dollars an hour. The rest of the team thought that was cheap.

The launch thread on Hacker News passed 1,979 points. The name is deliberate. TypeSafe named the model after William Stanley Jevons, because it expects cheaper machine intelligence to raise total demand for it, the way more efficient steam engines raised demand for coal.

That bet is the interesting part, and it has consequences the company that made it may not enjoy.

Jevons was right about coal

In The Coal Question (1865), Jevons pointed out something that looked backwards. James Watt’s engine used far less coal per unit of work than the Newcomen engine before it, and Britain’s coal consumption went up, not down. Cheaper work per ton made steam worth using in thousands of places where it had never paid before. Efficiency did not save coal. It found coal new jobs.

Apply that to judgement. Today, a machine decision inside ordinary software is expensive enough that engineers ration it. You call a language model where a person would otherwise have to read something, you wait a few seconds, you pay for the output tokens, and you parse what comes back hoping it is the shape you asked for. So the model gets called at a few chosen points: the triage step, the summary, the chat window.

Now price the decision the way TypeSafe prices it. Seven dollars an hour at ten a second is 36,000 decisions for seven dollars, or roughly two hundredths of a cent each. A 2,000-token record costs under a hundredth of a cent to read at the listed price. At that level the rationing logic disappears. Every if statement that currently checks a keyword, a regex or a hand-tuned threshold becomes a candidate for a fuzzy one. Every event in a queue can be scored on arrival. Every form field can be checked for whether it makes sense, not just whether it parses. One commenter on the launch thread guessed that 40 to 70 per cent of the model calls in a given business pipeline could move to this shape. That is a guess, and it is the right order of magnitude to plan around.

This is the mechanism the rest of the piece depends on. When the price of a judgement falls by two orders of magnitude, the number of judgements a business can automate rises by more than that, and the constraint moves off the model and onto the humans who have to say what each judgement is, what counts as right, and what happens when it is wrong.

The moat debate, taken seriously

If you sell the model, the same arithmetic works against you. The Hacker News reaction in the week after launch is the clearest picture we have of how quickly this layer turns into a commodity.

Arcturus Labs published the sharpest version of the argument. Its author’s thesis is that Jev is most likely something close to a conventional language model whose next-token probabilities are read off at a single step and normalised over the options you supplied, and that OpenAI has been using single tokens as tiny classifiers inside tool calling for years. If that is right, a frontier lab could copy the product, and could go further by folding the capability into its main models, letting a model pause mid-reasoning to ask itself a calibrated yes/no question without leaving the GPU. The post’s own conclusion is that architecture is probably not the moat, and that if one exists it is in TypeSafe’s training data and calibration process.

The open side moved faster than any lab. Within the week there was Kev, a small family of Jev-like decision models built on Qwen3.5, which reached 460 points. There were several “OpenJev” implementations and, as one commenter noted, a pull request to vLLM heading the same way. On 22 September NobodyWho posted “Jev in 25 lines of Python”, which loads a 0.6-billion-parameter Qwen model, reads the logits for the option letters and turns them into probabilities. It is labelled a parody, and the thread tore into it for exactly that reason: several commenters pointed out that a tiny quantised model is nowhere near the quality TypeSafe claims, and that the 25 lines skip the calibration, which is the hard part. Other commenters countered that the prompt-processing cost is the same either way, so the open versions cannot be much slower by design.

Both camps are partly right, and together they settle the question for anyone buying rather than building. The interface (state in, typed probabilities out) was reproduced by strangers in a week. The quality may take longer to match. Several commenters who tried the open versions said they fell well short of Jev on real tasks, and TypeSafe’s founder has said the company thinks of itself as a data research lab. One commenter noted that TypeSafe’s own stated ordering puts “doing the right task” above data, and data above compute.

That ordering is the most useful sentence to come out of the launch, and it applies to TypeSafe’s customers more than to TypeSafe.

Where the value lands instead

When a layer becomes cheap and interchangeable, the value goes to whatever sits next to it and is neither. For decision models, we can see three candidates, and none of them is for sale.

The first is the definition of the decision. Jev’s API makes this explicit in a way a chat box never did. You have to write the question, list the options, and choose a threshold at which the software acts. “Is this refund request legitimate” becomes a yes/no with a probability, and somebody has to decide whether 0.82 means approve, hold, or send to a person. That number is policy. A commenter on Simon Willison’s post made a related point well: broad questions such as “is this résumé good” will carry whatever bias the model has, whereas narrow ones (“score this candidate’s Python experience”) put the judgement about what matters back in your hands. Writing decisions that narrow is domain work, and a vendor cannot do it for you because they do not know your business.

The second is labelled outcome data. A calibrated probability is only calibrated relative to some distribution, and the distribution that matters is yours. In the Kev thread, one commenter reported building email classifiers from 50 to 100 labelled examples, trained in minutes on a CPU, that matched or beat the general decision models on basic classification. In the 25-lines thread, another pointed to a preprint which found that recalibrating a general decision model against labelled data helped enormously. Whether or not those numbers hold for you, the direction is clear. A business that has recorded how its past decisions actually turned out can test any vendor’s model, swap vendors when a cheaper one appears, recalibrate a general model to its own base rates, or train a small specialised one. A business without that record can only take a vendor’s word for it.

The third is ownership of the consequences. Several commenters pointed out that type safety only guarantees a well-formed answer, not a correct one. Jev cannot return a sixth option when you offered five. It can confidently return the wrong one of the five. At ten thousand decisions an hour, somebody has to own the error budget: who reviews the low-confidence tail, who notices drift, and who explains to a customer why their claim was held. Whoever owns that owns the relationship, and the relationship is where the money is.

What this means for models

If this plays out, the shape of model usage changes in a way the frontier labs have to answer. The current pattern is one large, clever call that does the reasoning, the formatting and the decision at once. The pattern Jev points at is many small, cheap, specialised calls, each answering one narrow question, stitched together by ordinary code. Pricing follows the shape. TypeSafe charges only for input, and one commenter observed how much easier that makes budgeting, since you can count input tokens before you send them. The natural next step is pricing per decision, and procurement that compares cost per correct decision, not cost per token.

For the frontier labs, the Arcturus argument cuts both ways. A lab can add a decision endpoint, as the post expects. Other commenters doubted it would bother, since the market is small beside frontier chat and does not lie on the path the labs care about. Either way, what the lab sells in this layer is a commodity with a brand on it. The large models keep the work that is genuinely hard to decompose. Everything that can be decomposed into a list of narrow questions drifts towards whoever is cheapest that month.

Where this argument is wrong

Two limits are worth stating. First, there is no settled independent evidence yet on how well calibrated Jev is across domains (the early community benchmarks disagree with each other), and the Arcturus author reports finding domains where its probabilities do not hold. If general decision models turn out to be mediocre outside tidy classification, the explosion in volume is smaller than the arithmetic suggests. Second, a lot of this was possible before September. Zero-shot classifiers, embeddings with a threshold and fine-tuned small models all existed. What changed is that a developer can now get a typed, fast, cheap decision with one API call and no training pipeline, and adoption follows convenience at least as often as it follows novelty. That is enough for the Jevons mechanism. It does not need the model to be a breakthrough, only the price to have fallen.

What to write down this quarter

The founder deciding whether to wait or move is asking the wrong question if the choice is between vendors. The vendor you pick in October will probably be undercut by December. The work that does not expire is the inventory.

Start with the decisions your people make by hand more than a hundred times a week. In most businesses that list is longer than anyone expects: which queue a ticket goes to, whether an invoice matches its purchase order, whether a lead is worth a call, whether a document needs a second pair of eyes. For each one, write down four things. The question, phrased narrowly enough that a stranger could answer it. The options, as a closed list. The threshold at which the software should act alone, and what happens below it. And the name of the person who answers when it goes wrong.

Then start keeping the record. For every decision on that list, log the input, the decision, and what actually happened afterwards, in a form you could hand to any model provider or to a small classifier of your own. Six months of that record is worth more than any model contract, because it is what lets you test, switch and recalibrate when the price drops again.

For the engineer who is nervous about all this, the inventory is also a job description. The code that calls a decision model is twenty-five lines, as one parody post pointed out. Deciding what the decision is, measuring whether it is right and building the path for when it is not are the parts that stay hard, and they were always the senior part of the work.

Cheap judgement will be everywhere by next year. Knowing which judgements your business should make, and being able to prove they were right, will still be rare.