TypeSafe released Jev on 17 September, the first public model in what they call System One: small, fast models that answer a structured question with a probability attached, so that code can act on the answer instead of parsing prose. We had early access, put it inside our own tooling straight away, liked the idea enough to rebuild it, and this week published quorum, a local version that speaks the same request contract on our own hardware. This post covers what Jev is, why we built a local one, and, with numbers, where each is better.

What Jev is, in TypeSafe's words

TypeSafe describes System One models as "a new class of frontier models built to make fast, structured decisions that software can use directly". The shape is "unstructured state in, typed probabilistic decisions out". Jev is trained with what they call Reinforcement Learning for Calibrated Decisions, which optimises for "epistemically honest probabilities". They quote 70 to 500 ms per call, two orders of magnitude faster and cheaper than asking a general model, and price input at $0.042 per million tokens with output free. Those are their figures; we checked the speed and calibration ourselves below.

The API is one blob of state and any number of questions. Each question is one of three types. A yes or no question comes back as a probability. A choice comes back as a probability per option. A score comes back as a level on a scale you define. Give it a support message and ask three things at once: is this urgent, which team owns it, how annoyed is the writer. Three typed answers, one call, each with a number your code can branch on.

That is the right idea. The scarce thing in an automated pipeline is not generation, it is a decision you can trust enough to act on. We wrote about exactly that in July, from the other direction.

We ran it. Three walls.

Jev sat inside our coding agents as a set of gates: every incoming task triaged for risk, every file change reviewed before it was written, every final reply checked for claims it could not back. We also put it on a public benchmark, jev-trace-classifier, asking it to tell agent-written wiki pages from human ones across 4,579 pages. Neither Jev nor a local open-weight model beat the 77.6% majority baseline. The honest reading is that the text carries no signal for that question, not that either model is weak. The repo says so.

Three things stopped it being a permanent fixture.

Cost per call. The gates fire on every prompt, every diff and every completion, thousands of small calls a week. Per-call pricing turns a guardrail into a meter.

Privacy. What we were asking it to judge was unreleased code, client names and draft emails. That should not transit an API to be graded.

No knob on the model. The thing we most wanted was to retrain on our own labelled judgments, and a hosted model does not offer that.

quorum: same contract, our hardware

quorum keeps the wire contract and swaps the brain. Same request shape, same three question types, served by a local model through llama.cpp. The probabilities come from constrained decoding: the model is forced to emit one of the allowed answers and we read the token probability of each, so a number falls out of the decode rather than being parsed out of a sentence. There is an opt-in chain-of-thought mode where the model writes one short sentence of reasoning before it commits, which turned out to matter a great deal for classification and very little for yes or no. Every call is logged. Nothing leaves the machine and there is no per-call bill. Apache-2.0.

The gap is stated in the README and we will state it here. quorum is not a trained System One model. Its probabilities are good for ranking, this diff is riskier than that one, and they are not certified calibrated numbers. A calibration step narrows that gap. It does not erase it.

It runs on the judgment model from July

quorum's default brain is the model from We fine-tuned our own engineering judgment into a 4B model, on a desk-side AMD box: Qwen3-4B, a LoRA trained with Unsloth on 156 reviewed correction pairs, under four minutes a run on an AMD Strix Halo, weights on Hugging Face under Apache-2.0.

The argument in that post was that the corpus is the product and the weights are its current compiled form. quorum is the plumbing that grows the corpus. Judgments get logged as they happen, a person labels the ones that mattered, a calibration pass improves the numbers today, and a fine-tune improves the base model later. The corpus has kept growing since July. That loop is the knob a hosted model cannot give you, and it is the reason quorum exists as a local project rather than a wrapper.

The honest numbers

We ran 322 items with real human labels through three backends: the local model answering directly, the local model with chain-of-thought, and Jev. The items came from public datasets (SST-2 sentiment, SMS spam, tweet_eval offensive and irony, banking77 intent, SST-5 graded sentiment) plus 40 hand-labelled task risk tiers, the question our own gates ask most.

	local, direct	local, chain-of-thought	Jev
yes or no, 206 items	53%	61%	89%
classification, 72 items	64%	90%	100%
graded score, mean error, 40 items	1.02	0.74	0.51
calibration error, lower is better	0.20	0.28	0.05
median latency	0.4 s	1.6 s	0.7 s

Credit where it is due. On the thing TypeSafe trained for, calibrated judgment on messy real text, the trained model wins by a wide margin. Jev's probabilities mean what they say, with a calibration error of 0.05 against our 0.28. It is also faster than our chain-of-thought mode. On sarcasm it scored 86% to our 48%. On offensive language, 74% to our 50%.

Where the local model holds its own is classification and routing, 90% against 100%, and that is most of what a gate actually does: which tier is this task, which team owns this message, which path should this document take. Chain-of-thought lifted classification from 64% to 90%. It lifted yes or no by eight points and made the calibration worse, because it swapped one bias for another. We are saying that plainly because a gate that is confidently wrong is worse than no gate.

What we use each one for

Local for routing and classification, everywhere, including on client data. Ninety percent, free, private.

Jev for yes or no judgments where the data is already public or already leaves the building. Not for client documents, not for code that has not shipped.

Neither one commits anything on its own. A judgment orders the queue a person reviews. A person, or a deterministic check, does the posting.

The path to closing the yes or no gap on our own hardware is the same loop as July: label, calibrate, fine-tune. We optimise models rather than install them, and this is what that looks like in practice.

If you are working out whether a judgment like this belongs in your pipeline, and whether it can stay on your own hardware, the offer is the usual one. Thirty minutes, no slides, no obligation.