What shipped
At 03:21 UTC this morning TypeSafe AI published "Introducing System One Models and Jev", and it held the top of Hacker News for the rest of the day. Jev is the company's first public "System One Model": a model that never returns text. You give it a state and a set of typed questions, and it returns a choice, a score, or a boolean, each with a probability distribution and a confidence figure attached. In the company's own words, "Possible outputs and structure are defined in advance. The model never makes type errors."
The numbers in the launch post are aggressive. TypeSafe claims 70ms to 500ms end-to-end response times, which it describes as 40x to 200x faster than LLMs on the same class of tasks, and prices input at $0.042 per million tokens with output free. The model is trained with a method the company calls Reinforcement Learning for Calibrated Decisions and served by a parallel sampler rather than autoregressive token generation. It is in early access behind a waitlist and a console.
The company itself came out of stealth yesterday with $40M in seed funding led by DCVC. The founders are Diogo Almeida (CEO), Erik Gafni (CTO) and Sasha Sheng (COO), and the model is named after Jevons Paradox, the observation that making a resource cheaper tends to increase total consumption of it. The team page states that Almeida "co-invented RLHF and InstructGPT, the methods that lead to ChatGPT and GPT4" and previously worked at Google Brain, which is a large part of why the launch travelled as far as it did.
I want to set the product review aside, because I have not had access to the console. What is worth your attention today is the pattern, because you are almost certainly already implementing it badly.
The step you are already faking
Look at any agent pipeline in production and you will find System One steps everywhere. Route this ticket to billing, technical or abuse. Decide which of five tools to call next. Judge whether this draft answer contains a policy violation. Score this retrieved passage for relevance from one to five. None of these steps needs a paragraph of prose. Every one of them is a decision over a fixed set of options.
The standard way to build that step today is a frontier LLM with JSON mode, a system prompt that begs for a single word, temperature zero, and a regex or a Pydantic parse on the other side. It looks roughly like this:
resp = llm.chat(
model="frontier-model",
temperature=0,
response_format={"type": "json_object"},
messages=[
{"role": "system", "content":
"Classify the ticket. Reply with JSON: "
'{"category": one of ["billing","technical","abuse","other"]}'},
{"role": "user", "content": ticket_text},
],
)
try:
category = json.loads(resp.text)["category"]
assert category in {"billing", "technical", "abuse", "other"}
except (KeyError, ValueError, AssertionError):
category = "other" # the silent failure branch
Everything wrong with this is familiar. The model can return a label that is not in the set. It can wrap the JSON in a Markdown fence. It generates tokens one at a time, so a five-way classification costs the same latency floor as a haiku. And the thing you actually want, a sense of how sure the model is, does not exist. You can ask it to emit a confidence number, but a number an autoregressive model writes into a JSON field is a piece of text, not a calibrated probability, and it behaves like one.
TypeSafe's Choice primitive is the same step with the fake parts removed. The documentation describes a request as a state plus a map of typed questions, evaluated in parallel through client.system_one(...) in the Python or JavaScript SDK, or a POST to https://api.typesafe.ai/v1/systemone. Choice returns choice, probabilities and confidence; Score returns score, probabilities and confidence; a third primitive, Noul, returns a 0 to 1 boolean confidence. In sketch form, with field names as the docs describe them:
result = client.system_one(
state={"ticket": ticket_text, "customer_tier": tier},
questions={
"category": Choice(["billing", "technical", "abuse", "other"]),
"urgency": Score(1, 5),
"needs_human": Noul(),
},
)
category = result["category"]
print(category.choice) # "technical"
print(category.probabilities) # {"billing": 0.04, "technical": 0.91, ...}
print(category.confidence) # 0.91
Three questions, one request, evaluated in parallel, and no parsing step because there is nothing to parse. That last part is what "never makes type errors" actually means, and we will come back to how much it does and does not mean.
What calibrated probabilities buy you
The interesting output in that sketch is not choice. It is probabilities. A distribution over the option set changes what you can build downstream in three specific ways.
First, thresholds become tunable. With an LLM label you have a binary: the model said "abuse" or it did not. With a distribution you can route to the abuse queue at 0.6 in one market and 0.8 in another, and you can move the threshold without touching a prompt. If the calibration claim holds, a 0.7 should mean roughly seven in ten of those tickets really are abuse, which is what lets you reason about the false-positive rate you are accepting.
Second, you get an honest abstain branch. The category = "other" fallback in the LLM version fires on parse failures, not on genuine uncertainty. With a confidence figure you can send anything below your floor to a human or to a slower, more expensive model, and you know exactly how often that happens because it is a number you chose.
Third, the economics of map-reduce change. When a decision costs tens of milliseconds and fractions of a cent, you stop sampling and start scoring everything. Every's Head of Evals Mike Taylor gave the clearest early demonstration of this: he ran 777 judgments across 37 documents in 0.7 seconds for roughly $0.0025, reporting a median of 0.35 seconds per passage against 8.83 seconds for Fable 5.1 and about 580x lower cost. Jev caught six of seven planted defects where Fable caught all seven. That miss matters, and I will not pretend it does not, but the shape of the workload is the point. You do not run a frontier judge over every passage of every document you have ever written. At this price you might.
What the sceptics got right
The Hacker News thread, at 1,178 points and 342 comments when I read it, is worth your time, and its two strongest objections hold.
The first is that "cannot hallucinate" conflates type safety with correctness. Jev cannot emit a value outside your schema. It can absolutely pick the wrong one, confidently. The claim is real but narrow, and the marketing leans on the broad reading. Treat it as "will not break my parser", not "will not be wrong". The Every result is a small live example: one planted defect, valid output, wrong answer.
The second is that the speed comparison is structured prediction against autoregressive text generation, which is not a fair fight. A model that emits a distribution over 255 options in one shot will beat a model that has to write the answer out one token at a time, whatever either of them knows. Critics pointed out that open-weight encoder classifiers already do zero-shot classification without generating text, and GLiClass was named specifically. The question TypeSafe has not answered in public is how much better Jev is than those, because there is no paper and there are no third-party evals. Almeida, posting as CompleteSkeptic, replied that the architecture is being kept "close to the chest" pending a paper and that "data is probably far most interesting than architecture". A co-founder confirmed a 32k context window and structured JSON input.
The launch post is also candid about the limits, which I appreciate. Jev generates no strings at all. A single choice supports at most 255 options, so higher-cardinality problems need two-stage scoring. It accepts structured program state and text but not images. The company's workflow evals compare it against GPT-5.6 Terra, GPT-6 Astra and Fable 5.1, which is the right comparison set, but they are the company's own evals. The manifesto puts the thesis plainly: "the bottleneck isn't raw intelligence. It's that today's intelligence is hard to build on." and "We're building prod, not God." That is a reasonable thesis. It is not yet a demonstrated one.
What to do this week
You do not need a waitlist slot to act on this. Open your pipeline and mark every call to a language model whose output you immediately reduce to a label, a number or a yes-or-no. Routing, tool selection, relevance scoring, safety checks, retry-or-escalate decisions. Count them. Multiply by your per-call latency and cost. That is the bill you are paying for text you throw away.
For each one, ask three questions. Is the option set fixed and small? Would a probability distribution let you add a threshold or an abstain branch you currently lack? Do you run this step over enough items that 40x cheaper would change what you do, not just what you spend? If the answer to all three is yes, that step is a System One step and it does not belong on a frontier model.
Then pick your replacement honestly. Jev is one option, in early access, with a strong team behind it and no external evidence yet. An open encoder classifier is another, and it runs on your own hardware. A small fine-tuned model behind a proper softmax is a third. What all of them share, and what the LLM-plus-regex version lacks, is a real distribution over a real schema. Build the abstain branch first, measure how often it fires, and only then decide whether the confidence figures you are getting are calibrated enough to trust. If TypeSafe publishes the paper and someone outside the company reproduces the Every numbers, the decision gets easier. Until then, the pattern is the thing to adopt. The vendor can wait.
Comments (0)
No comments yet. Start the conversation.