Software doesn't want prose, it wants verdicts

Every LLM API shares one contract: text in, text out. That made sense when the reader was a person. But most software calling a model isn't reading anything. It wants a label, a route, a yes or no, a number. You can force a chat model to emit JSON and parse it, but you're burning thousands of tokens of generation to deliver a single bit of information, and paying for that on every one of the thousands of calls an agent loop makes per hour.

Jev, released September 15 by TypeSafe AI, took the other path. It doesn't chat. It doesn't write. You send it text and a list of options, and it returns calibrated probabilities over those options. A few hundred milliseconds, no output tokens, $0.042 per million input tokens. TypeSafe was founded in 2024 by Diogo Almeida, who worked on ChatGPT at OpenAI, Sasha Sheng, a former Meta/FAIR research engineer, and Erik Gafni, a serial founder.

Two weeks after launch, OpenAI shipped a Decisions API and quietly confirmed that Jev inspired it. A category that didn't exist in August now has a funded leader, a big-lab response, a wave of open-source clones, and edge models measured in single-digit milliseconds. This piece covers what these models do differently, what happens when you put one in a real code path, and where people keep tripping.

What a decision model does differently

The architecture is still a Transformer. The output contract is not. A decision model runs one forward pass and returns typed values and a probability distribution. There's no autoregressive decoding, no token loop, nothing to parse. TypeSafe calls this class System One models, and the primitives are deliberately primitive:

• Choice: pick from a set of options, returns a probability per option plus an overall confidence.
• Score: rate input on an ordered scale (low, medium, high), returns a continuous score and distribution.
• Noul: answer a yes/no question, returns the probability the statement is true.

You can ask several questions against the same state in one request. Adding questions barely moves response time. In an agent loop, every decision you can batch removes a round trip, and removing round trips is how you make an agent feel fast.

The training is the part you can't see but should care about most. TypeSafe uses something it calls calibrated decision reinforcement learning, aimed specifically at making the probability estimates trustworthy. A model that says 90% should be right nine times out of ten, because downstream code will branch on that number.

The practical effect: a few hundred milliseconds per decision is fast enough to sit in a synchronous request path, not a background queue. And at $0.042 per million input tokens, the per-call price stops being something you think about.

A $870 million bet and OpenAI's two-week answer

On October 9, TypeSafe announced an $870 million Series A at a $7.5 billion valuation. a16z led, Sequoia and DCVC joined, and Martin Casado took a board seat. Coverage of the round notes the valuation grew roughly 37x in three weeks. TypeSafe says Jev generated a trillion tokens in its first three days and that about a third of the Fortune 500 uses it; a16z puts the integration number at 25%. On Vercel's AI Gateway, nearly 13% of paid teams tried Jev within 24 hours, more than double the first-day number of any previous model launch.

The velocity forced a response. OpenAI's Decisions API, in limited preview two weeks after Jev shipped and public beta on October 6, is built on GPT-6 Luna, a model that already existed. Rather than training something new, OpenAI tuned Luna to return decisions directly, answer multiple questions per call, and accept images, so you can ask whether a product photo shows visible damage and get back a damage probability the app acts on. Input pricing is $0.10 per million tokens, output free. That's still 2.4x Jev's input price, but the gap is small enough that the choice will come down to calibration quality, not price alone. OpenAI says the Decisions API is up to 10x faster than calling the same model through its Responses API.

Model	Returns	Input per 1M tokens	Output	Notes
Jev (TypeSafe)	Probabilities over options	$0.042	Free, no text	Few hundred ms, text only
OpenAI Decisions API (GPT-6 Luna)	Decision + probabilities	$0.10	Free, no text	Image input, faster than its own Responses API
Gemini Flash-Lite	Text: labels, arguments	$0.30	Standard billing	1M context, forgiving of weak prompts
Liquid d1-3B	Probabilities over options	Open weights	Self-hosted	8ms on an RTX 4090, text + image

The naming is on purpose. Jev is named after William Stanley Jevons, the economist behind the Jevons paradox: when a resource gets cheaper, total consumption can rise rather than fall. a16z dubs the effect the "Jev-ons paradox": cheap enough intelligence gets invoked everywhere. Independent data supports the premise. A preprint from researchers at the University of Bonn and Lamarr Institute ran 346,009 requests across 37 datasets for a total bill under $10. That's about three cents per thousand decisions. At that price, you automate the decisions you never would have bothered to automate before.

Quick Take: A decision model doesn't replace your chat LLM. It replaces the calls where you only needed a yes, a label, or a number. In an agent loop, that's most of the calls.

What a production router taught me about Jev

Reading about Jev is easy. Trusting it with a real job is different. When it launched, I had exactly that job waiting. At Major League Hacking we grade AI coding agents with benchspec, an open-source eval runner. A markdown spec defines checks like ".meta/index.md exists" or "the summary faithfully reflects the three key facts from the source". Each check is verified either by cheap deterministic code, a path existence test, a glob count, a regex, or by an LLM judge that reads for meaning and costs money on every run.

A router reads each check and picks a checker, or defers to the judge. The two errors are not symmetric. Sending something to the judge that code could have handled costs a few cents. Sending something to code that code can't actually verify produces a false green: the check reports success, the agent gets graded pass, and someone ships on the strength of it. Cents come back. Trust doesn't. So the router's rule is: when in doubt, defer.

I swapped Jev into that slot and ran real checks through it. On eight representative checks, Jev made three dangerous calls. Two checks needed content read for meaning, but Jev sent them to regex, which can confirm a line exists but can't tell you whether it names the right move. A third, "no .DS_Store anywhere", is a whole-tree check, and Jev picked a checker that looks at a single path. Flash-Lite, the model I actually run there, made zero false positives and over-deferred twice. Over-deferral costs cents. False positives cost trust.

The fix was one sentence, and it wasn't "be careful". It was: "Imagine this checker passed. Could the check still be false?" That's a procedure Jev can run once per option. For a regex check: a source line exists, but could it name the wrong move? Yes. Out. For the whole-tree check: one path is clean, but could a subfolder still hide a .DS_Store? Yes. Out. Jev went from 35 false positive runs to zero on a fresh batch of checks it had never seen. Flash-Lite barely moved.

Worked examples made Jev worse. I folded real examples into the prompt and the dangerous calls doubled. Examples teach pattern matching, and Jev matches patterns. The useful way to think about it: Jev fails with blind spots, which are systematic and fixable with a better criterion. Flash-Lite fails with flips, which are sampling noise you measure for. Jev obeys a precise criterion literally, so a better criterion fixes it. Flash-Lite forgives a sloppy prompt but never fully obeys a precise one.

That difference is why I ended up running both. Jev decides, and when the answer needs arguments written, Flash-Lite writes them. The second call only fires when there's something to write, on fewer than four in ten checks in our set, and its prompt is about a seventh the size, because Jev already made the routing call. Measured per 1,000 checks, Flash-Lite alone ran $0.52. Jev plus Flash-Lite ran $0.10. Jev by itself costs about three cents. You pay for the pair with one extra round trip, about a quarter of a second on average.

The same pattern showed up on public data. On a slice of the Berkeley Function Calling Leaderboard, Jev's top label called a function on about one in thirteen items where nothing fit; Flash-Lite, about one in twenty-five. But Jev has a knob. Raise its confidence bar to 0.8 and false positives drop to about 1%, at the price of deferring twice as often. Flash-Lite has no knob, but it writes the arguments and gets them fully right over nine times in ten. The pair gets Jev's false-positive rate and Flash-Lite's arguments for less than half the one-call price.

One more thing from that experiment. Flash-Lite kept calling functions on items the answer key said had none. After failing the same way five times, I read the items. "Who won the World Series in 2020?" with one candidate function, get_champion(event, year). The function answers the question. The key said it didn't. Seven items in our sample had wrong keys. A cheap model with a real job found a bug in a public benchmark.

Finding the why without inventing it

I hit a similar wall in a different project. I maintain an AI-assisted changelog generator. Extracting what changed from a PR is easy for an LLM. Extracting why the change was made is where models invent plausible reasons that were never written, and a changelog full of invented whys is a liability.

The reframe that worked: WHY extraction is a selection problem, not a generation problem. The pipeline runs deterministically first, pulling candidate sentences from the PR body by looking for signal words: because, motivation, rationale, so that. Then Jev evaluates each candidate with two questions, each returning a probability: does this candidate explicitly state why this change was made? And, does it state a reason that applies to this specific change? Both have to clear thresholds, tuned by sweeping values from 0.4 to 0.9 over a 50-case benchmark and comparing precision, recall, and F1. "0.8 feels safe" is not a measurement.

The output is the author's original sentence, untouched. If no candidate passes, the changelog gets no WHY, which is the correct answer far more often than generative models admit. Jev decides. The PR author still provides the sentence.

What the community is saying

Reading the threads around these models, I keep seeing the same architecture converge. People building with Jev-class models for eval grading, claim verification, and ticket routing all land on the same split: a calibrated decision model makes the call, deterministic code validates where possible, and a small cheap generative model writes up the findings or the arguments. One LocalLLaMA thread asked what people actually do with local decision models, admitting it feels like a solution in search of a problem. The answers came back concrete: deep eval testing, intent classification, routing.

The false-positive asymmetry comes up constantly, usually phrased as some version of "when in doubt, say you can't tell." One developer I know checks whether a README's claims match its code by labeling each line with a decision model, letting deterministic verifiers decide what's true, and using a cheap writer to explain the findings. They described their worst failure as a false "Contradicted" verdict, which is the same false green I was fighting, and their escape hatch is identical. The most useful observation I saw formalized what I'd learned the hard way: examples help open-ended generative tasks, but they hurt constrained precise ones, because the model starts pattern-matching instead of checking what a tool can actually verify.

The open-source and edge wave

The category got cloned within weeks, at both ends of the size spectrum. A community project called Laya was positioned as the first open-source Jev-style decision model. Its follow-up, Vega, runs 800 million parameters with 73k token context and image support, using what the author describes as an engine and adapter test-time-training architecture. The mechanics are fanciful, outcomes as valleys, a ball dropped and allowed to settle under friction into the best one. The size is the serious part: 800M parameters runs on a laptop, and 73k context is enough to hold a long document or a page of UI state.

Liquid AI shipped open d1 models at the same frontier. d1-3B, built on the LFM2.5-VL-3B vision-language backbone, handles text and images. d1-omni-600M adds audio. The latency numbers are the story: d1-3B answers a single question in 16ms on a Jetson AGX Thor, 26ms on a Jetson AGX Orin, 50ms on an Orin Nano, and 8ms on an RTX 4090. A 16ms answer is faster than one frame at 60 frames per second, so the decision disappears into the request path. Three questions take only 1.3x the time of one. On the Decision Index 0.2.1, d1-3B scores 48.57, the best mark under 10B parameters, ahead of the 35B-A3B mixture of experts at 47.11.

Benchmark	d1-omni-600M	d1-3B	Decider 2B	Decider 4B
SQuAD 2.0	74.0	83.3	67.7	76.0
Civil Comments	95.8	93.3	93.6	92.8
MASSIVE intent	86.1	86.9	81.1	88.3
PubMedQA	61.3	68.3	65.7	63.3
BoolQ	77.7	86.3	87.3	89.0
XNLI	74.7	85.6	85.0	88.6
PAWS-X	79.5	76.4	59.5	69.8
Mean	78.4	82.9	77.1	81.1

The 600M model beats Decider 2B's mean with a quarter of the parameters. Both run in a few tens of milliseconds on hardware you can buy off the shelf. Whatever you think of specific benchmark tables, the direction is clear: the decision model class went from zero to open edge weights in about a month.

Common pitfalls

1. Treating the probability as the decision. A calibrated 0.5 is not a universal action threshold. The Bonn study found a fixed 0.5 threshold underperforms on some binary tasks, and tuning it per task helped. On the BFCL slice, raising Jev's bar to 0.8 cut false positives from about 1 in 13 calls to 1%, at the cost of deferring twice as often. The right bar depends on your cost asymmetry, so measure it on your own data.

2. Prompting a decision model like a chat model. Worked examples doubled Jev's dangerous calls in my router tests. These models match patterns literally. Ask about the tool's blind spot ("could this checker pass while the check is still false?") rather than describing the check's shape.

3. Letting false greens ship. A deferral you didn't need costs cents. A check reported pass when it shouldn't be sends broken output downstream and burns user trust. The asymmetry has to shape the threshold and the routing logic: when in doubt, defer.

4. Assuming a bigger model erases prompt problems. Gemini 3.8 Flash and Opus