A model that answers with a probability instead of a paragraph

Diogo Almeida helped build the methods that made language models useful at following instructions, work that became part of the research behind ChatGPT. He then spent two years in stealth on what he calls his driving question: models have been superhuman at chat for years, so where is all the automation? 1

His answer is a model called Jev, released by his company TypeSafe AI in early access on 15 September 1. Jev does not write. It takes unstructured state in and returns typed probabilistic decisions out: is this customer angry, is there a new dependency in this email, does the operational plan need to change for this 2.

TypeSafe's training method is called reinforcement learning for calibrated decisions, or RLCD, and the company poses it against the two methods that made chat models what they are. RLHF optimises for the write-ups and chat responses human raters prefer. RLVR optimises for outputs a program can verify. RLCD optimises for answers carrying honest probabilities on judgment-shaped questions 1.

The architecture follows from that. An ordinary language model samples one token at a time, each conditioned on the last. Jev samples all of its outputs in a single query, in parallel. TypeSafe reports 70 to 500 milliseconds end to end against 3 to 329 seconds for frontier models, and prices input at $0.042 per million tokens with output tokens free 1. Those are the numbers behind the claim of 193.6 times faster and 444.6 times cheaper on the company's own workflow evaluations.

They are the maker's measurements on the maker's benchmarks, and the post says so: the four workflows were written by TypeSafe's own capabilities team, and the reference answers are an average of GPT-6 Astra and Claude Fable 5.1 1. One claim cannot be fudged. The possible outputs are defined in advance, so Jev cannot return a value the caller's schema does not allow, which is what the company means when it says the model cannot produce a type error.

The clearest way into the idea is a program that is waiting for a number. A support system asks a model whether a customer sounds angry, because it wants to escalate above 0.9 and deprioritise below 0.1. A chat model replies that the customer does sound frustrated and offers to draft a warm response. The surrounding program crashes, because it was handed an essay.

Jev returns 0.9. It can also return a distribution over categories the caller defines — annoyed, irritated, offended, furious, enraged — with a probability attached to each 2. TypeSafe's own framing is a frontier-intelligence function call: a smart if-statement that can read messy human context. Its documentation recommends breaking a complex decision into small questions and recombining the answers in code 1.

That decomposition is what makes the model fit work a language model handles awkwardly. In support, a ticket can be routed and prioritised from four narrow judgments: is the customer describing a product problem, does the message show repeated failed contacts, is a commercial deadline close, and which team should handle it. In sales, the same pattern scores inbound leads. In editorial, it checks whether a draft repeats an idea without adding evidence or forces a symmetrical both-sides argument 2.

Cheap judgment changes how often a system can afford to judge. When a check adds a noticeable delay or cost, a team runs it on selected cases or at the end of a task. At a fraction of a cent and a few hundred milliseconds, the check can run on every incoming request, after every draft revision, and before an agent takes a consequential step.

That leads to the division of labour people on the episode kept converging on: a language model proposes options, Jev decides, and code executes. The generative model still writes the reply. The judgment model checks the reply against narrow criteria — does it acknowledge the repeated contacts, does it address the export problem, does it promise something the supplied information does not support 2.

There is an older category hiding inside this one. A large share of what businesses call judgment problems are classification and regression problems, and a large share of companies have been solving them with people and process rather than with technology. When language models arrived, those companies started solving them with language models, which is often the wrong tool for the job. Classical methods fit better but need labelled data, a trained model and somewhere to host it. Jev is best understood as giving the classical approach the ease of an API call.

An agent serving one person learns that person's preferences and gets a long way. An agent serving a team has to read the relationships between people's work, which produces a different set of questions: who owns this, whose work does it affect, is someone waiting on this decision, and can the current owner decide alone.

The example on the episode is a salesperson telling a customer that a requested integration should be supported before renewal. For the salesperson, that sentence is a path to the renewal. For engineering it is a possible delivery commitment over uncertain work. For product it may change roadmap priority. For customer success it is an expectation to manage. A judgment model can answer the questions that make the obligation legible: does this message imply a delivery promise, does the promise concern work outside the speaker's authority, does it conflict with the supplied roadmap, and is there evidence the responsible team agreed.

Judgment models are an incomplete category by construction. Jev cannot draft the email, explain itself in prose, or handle anything shaped like open-ended generation, so it has to sit inside a larger stack rather than replace one. What it buys is a price low enough that the check stops being a budget line and becomes part of the control flow.