Jev and System One Models: Fast Decisions Instead of Generated Text

Nish · September 22, 2026

NLP Techniques

38 min read

TL;DR
What a call to Jev looks like
Why TypeSafe calls it a System One model
Where the speed comes from
RLCD, or training for honest probabilities
Confidence is a statistic, not a second opinion
What the numbers say so far
Is this just a classifier with good marketing?
Where it fits in a stack, and where it does not
What I would check before trusting it
Sources & further reading

On September 15, 2026, a company called TypeSafe AI came out of two years of stealth with a \$40 million seed round and a model called Jev. Jev takes text in, like any language model, but it never writes text back. You hand it a piece of state and a set of typed questions, and it returns a probability distribution for each question, in well under a second, at a price of a few cents per million input tokens. TypeSafe calls this a System One model, borrowing Kahneman’s name for fast, intuitive judgement. It drew a large Hacker News discussion and open-source clones within a week, and the debate that followed can be caricatured as two camps: the missing piece for agents, or a classifier with a marketing budget. Both have a point. This post goes through what Jev actually is, what the training claim behind it means, what the first week’s independent evaluations suggest, and where a model that only decides fits in a stack that still needs a model that writes.

TL;DR

Jev is a hosted model that answers three kinds of question about an input: choice (pick one option from up to 255), score (rate against up to 10 ordered levels), and noul (a yes-or-no probability). Every question is answered in parallel against the same state, and the output is typed values, not a string your code has to parse.
The speed and price follow from the shape of the call. There is no autoregressive output loop, so latency does not grow with the length of the answer, and TypeSafe charges only for input tokens: \$0.042 per million, with output free. On TypeSafe’s own workflow evaluation, Jev had similar agreement with the model-generated answer key to Terra and Sonnet, at roughly 1/76 and 1/294 of their respective costs per case, using the rounded published values.
The technical bet is not the architecture, which TypeSafe has not published, but the training objective. Reinforcement Learning for Calibrated Decisions (RLCD) is described as training the model for probabilities that communicate uncertainty accurately, instead of for text a person prefers. Everything TypeSafe wants you to do with the model, from routing on confidence to skipping the human, depends on that calibration holding.
Independent evidence is early and mixed in an instructive way. Jev shows about 90% agreement with the tested LLM judges on rubric grading, at about 1/206 of Fable 5.1’s estimated cost, and it beat a zero-shot encoder baseline on two small benchmark slices. Its calibration varies with prompt wording, it is unreliable at arithmetic, dates, and multi-hop instructions, and it has no automatic abstention outside the supplied answer space, so you add an explicit review option and fallback logic. Asked one broad question it can lose badly to a small LLM; given narrow signals and a fitted combiner it can match one.
The right mental model is a general-purpose decision API that can replace some classification calls to LLMs, provided it meets your task’s accuracy and calibration requirements, sitting next to your LLM rather than replacing it. Use it for routing, gating, scoring, reranking, and judging. Keep generation, reasoning, and arithmetic elsewhere. Measure calibration on your own data before you let it act unsupervised.

Scope and sourcing. Jev is proprietary, and I found no public technical description sufficient to reproduce it. What follows is drawn from TypeSafe’s launch post, its documentation, its founder’s public statements, and the independent evaluations that appeared in the week after launch, all linked in Sources. Numbers are quoted as their sources report them, and the two small computations in the post come from the code in the foldable block near the end. Where I infer something the sources do not state, I say so.

What a call to Jev looks like

The best way to understand Jev is to look at one request. The API has one decision endpoint, and a request has three parts: a state, which is the content to be judged (a string, a JSON object, or a list of messages), a model name, and a map of questions. Here is the routing example from TypeSafe’s own documentation, rendered as JSON.¹

{
  "state": "My running shoes arrived in the wrong size. Can I swap them for a size 10?",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "returns": "Exchanges, wrong or damaged items",
        "shipping": "Delivery status, delays, lost packages",
        "billing": "Charges, invoices, payment problems"
      }
    }
  }
}

The API returns a structured JSON response containing the decisions and their probabilities. The model does not generate that JSON token by token; the service packages the values, and the SDK exposes them as typed fields.

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 1.0,
      "probabilities": { "shipping": 0.0, "returns": 1.0, "billing": 0.0 }
    }
  },
  "usage": { "input_tokens": 328, "output_tokens": 34 }
}

Three different numbers appear in responses like this, and it helps to separate them now. A probability is the model’s stated chance that an option is the answer. Confidence is a separate statistic that summarises how concentrated the distribution is, and it is not a probability of being right. And accuracy or agreement is what you measure afterwards by comparing decisions against an answer key. The rest of the post keeps the three apart.

Three question types cover everything the model can do.²

A choice picks one option from a set you define, up to 255 of them, and returns the winning key, a probability for every option, and a confidence number.
A score rates the state against an ordered list of two to ten described levels. It returns a probability per level and a score that is the expected level: each level number multiplied by its probability, added up, which need not land on one of the levels. The docs’ bug-severity example puts probabilities of 0.00, 0.57, and 0.43 on levels 0, 1, and 2, which gives a score of $0 \times 0.00 + 1 \times 0.57 + 2 \times 0.43 = 1.43$ and a confidence of 0.35.
A noul answers a yes-or-no proposition with a single probability that the answer is yes. The docs’ example returns 0.99 for “Is the customer asking for a human agent?” on the message “I have asked three times now. Can I please just talk to a real person?”

You can mix all three in one request, and the documentation is explicit that every question is evaluated in parallel and in isolation against the same state, meaning that answers do not consume one another. The documentation says adding questions has little effect on response time. The intended pattern is decomposition: rather than one question that asks for a judgement and its rationale, you ask several atomic questions and combine the numbers in ordinary code. TypeSafe’s founder put the mapping bluntly in the launch thread: a choice maps to a match statement, a score maps to sorting, and a noul maps to an if.³

The practical limits at launch: text only, no images or audio; a 64k-token window per request, of which the state plus the longest question can use 32k; English first, with other languages “handled but not equally well”; no fine-tuning; and direct access that initially ran through a waitlist, with rate limits that TypeSafe says are adjusting dynamically under demand.⁴ Official SDKs exist for Python and JavaScript, and LangChain shipped an integration two days after launch.⁵

Why TypeSafe calls it a System One model

The name is a deliberate contrast with the reasoning models of recent releases. Those models buy accuracy on hard problems by spending more tokens at inference, a mechanism I covered in a separate post on how test-time compute became a second scaling axis. In Kahneman’s language that is System 2: slow, deliberate, sequential. TypeSafe’s launch post says the model class name “draws on the distinction between fast, intuitive System 1 thinking and slow, deliberate System 2 reasoning”, and its documentation defines a System One model as “a class of AI models built to make fast, structured decisions that software can use directly”.⁶ The cognitive labels are an analogy for the product’s shape, not a claim about how the model computes.

The argument for why such a thing should exist is about who the consumer of a model’s output is. The founder, Diogo Almeida, previously worked at OpenAI, co-authored the InstructGPT work and contributed to ChatGPT and GPT-4, and his pitch is that the technique he helped build optimised models for a person reading the answer.⁷ A talk he gave at the AI Engineer conference in July 2026, two months before launch, laid out the case in three steps: today’s models are excellent at assistance and poor at automation; RLHF made them that way by construction, because it rewards outputs a human rater prefers; and automation needs a model whose output is a calibrated decision that a program can act on without a person in the loop.⁸ In an interview published by investor DCVC, Almeida predicted that software would account for over 99% of AI calls in a future where AGI automates most of the economy.⁹

Two things follow from that framing, and both matter for how you should read everything else. First, Jev is not trying to be a smaller or cheaper LLM. It cannot write a reply, produce code, or explain itself, and its documentation says so in almost those words. Second, the jobs it is aimed at are the ones that clog an agent pipeline: is this ticket urgent, which tool should run next, is this action safe, does this passage answer the question, how severe is this bug. Those are the calls that today get made by prompting a frontier model to emit a one-word JSON field and waiting several seconds for it.

The model is also named for an economist. William Stanley Jevons observed in 1865 that making coal use more efficient increased coal consumption rather than reducing it, and TypeSafe’s launch post says it chose the name because “every order of magnitude drop in the cost of intelligence unlocks orders of magnitude more use cases”.¹⁰

Where the speed comes from

TypeSafe reports end-to-end response times of 70 to 500 milliseconds, a measured range under its own conditions rather than a service guarantee. To see why that is plausible rather than magic, compare the two call shapes in the figure below.

Two-zone schematic. Top: a language model in the loop reads state plus a prompt, generates an unconstrained JSON string one token at a time, and hands it to a parse-and-check step with a retry on invalid output before code can use the value. Bottom: a System One model reads the state and three typed questions without an autoregressive output loop, and the SDK returns a probability distribution per question that code consumes directly. — The same routing job done two ways. With a language model generating unconstrained text (top), the answer is a string that is generated autoregressively, although serving techniques such as speculative decoding can reduce target-model passes, and it must be parsed and validated before code can branch on it, with a retry when the output is invalid. A System One model (bottom) reads the state and every question without an autoregressive output loop, and the SDK returns typed distributions that code branches on directly. The upper path illustrates unconstrained text generation. LLM APIs can also enforce supported JSON schemas with constrained decoding; Jev's distinctive tradeoff is giving up open-ended generation, not being the only route to schema-valid outputs. The team and hand-off probabilities are illustrative; the severity row is the worked example from TypeSafe's Score documentation.

In ordinary autoregressive decoding, each new output token depends on the preceding tokens. Even a short JSON answer therefore adds decoding work, although token counts depend on the tokenizer and serving techniques such as speculative decoding can reduce target-model passes. For a single request stream, each of those passes is a trip through the weights that is bounded by memory bandwidth rather than compute, which is why single-stream decoding is the expensive regime in the first place.¹¹ Then the string has to be parsed, checked against a schema, and retried when it is not valid. TypeSafe describes the outputs as parallel rather than autoregressively generated. On Hacker News, Almeida said sequential output structures are excluded so the outputs can be computed in parallel; he did not disclose the full architecture.¹² A launch-day post on X framed it as the same trade the transformer made against recurrent networks: replace sequential computation with parallel computation and accept the constraint that comes with it, which here is that the model cannot generate.¹³

This is the point where a seasoned NLP engineer says: that is just prefill plus reading the logits. And the mechanism, at least, is old. Zero-shot classification with a language model by scoring the next-token probability of each label is years old, and the open-source clones that appeared within days of launch do a version of exactly that. One serves a Jev-compatible API by prefilling a prompt on a Qwen model and taking the log-probabilities of the option labels at the first output position, without an autoregressive continuation: the server reads first-position log-probabilities and ignores the sampled token.¹⁴ Another uses a diffusion language model and reads the distribution directly from masked answer slots; its current implementation can repeat the read for uncertain slots and average the results.¹⁵ Both are fast for the same reason Jev is fast.

So the interesting claim is not that a model can answer a multiple-choice question in one pass. It is that this one answers with probabilities you can trust, across arbitrary schemas you did not train it on, at close to frontier quality. Almeida’s own position is that the architecture is not where the value lives: he has argued that data and the target task matter more than architecture, and that a model without jagged failures needs a far more diverse input distribution than an open fine-tune would see.¹⁶ That moves the whole argument to training, which is where the next section goes.

RLCD, or training for honest probabilities

TypeSafe describes Jev’s post-training as a third paradigm next to the two that produced today’s chat and reasoning models. RLHF trains a policy against a reward model fitted to human preferences. RLVR, reinforcement learning from verifiable rewards, trains against automatically checkable outcomes such as a correct final answer, and is the recipe behind the reasoning models. RLCD, Reinforcement Learning for Calibrated Decisions, is the third. TypeSafe describes RLCD as training for decisions whose probabilities communicate uncertainty accurately; it has not published enough detail to reconstruct the training objective.¹⁷

The word doing the work is calibrated. A probabilistic model is calibrated when its stated probabilities match observed frequencies: among all the decisions it returns at 0.8, about 80% should turn out right. TypeSafe’s primer says exactly this, and it is the same property that classical probability calibration tries to restore in a boosted-tree classifier after the fact.¹⁸ The difference is that TypeSafe claims to train for it directly, as the objective, rather than fitting a correction curve afterwards.

Why would that need a new objective? The launch materials and Almeida’s interviews make a specific claim about what RLHF does to a model’s probabilities. Optimising against a preference reward pushes the policy toward the outputs the reward model likes most and away from everything else, a behaviour usually called mode collapse or mode dropping. The primer’s own diagram shows a probability distribution narrowing under RLHF. In the Latent Space interview Almeida argues the collapsed model becomes “extremely conservative”, drops minority classes, and reports confidence that no longer tracks its accuracy, whereas a model trained to cover the distribution “is not overly punished about having outliers”.¹⁹ If the model’s job is to output probabilities that software will threshold, that overconfidence is not a cosmetic flaw. It is the bug.

How does one reward calibration? I could not find a public description sufficient to reconstruct it, so what follows is background on the standard ingredients rather than an account of what TypeSafe does. A strictly proper scoring rule is minimized in expectation uniquely by the true outcome distribution. Log loss and Brier loss are examples: log loss charges the negative log of the probability assigned to what happened, and the Brier score charges the squared gap between the stated probability and the 0-or-1 outcome. Such losses assess more than calibration alone, and minimizing them on training data does not guarantee calibration on new tasks. Whatever the objective, the hard part is not the loss function but the outcomes: you need a very large, very diverse supply of decisions with known answers, across every schema a customer might invent, which is presumably what “a lab that owns the subfield” of synthetic data is for.

Two more facts about the training constrain the picture. Almeida has said the model is general and needs “no training at all” per task, but is “focused on System 1 tasks (more human judgment, less math reasoning)”.²⁰ And the documentation states that Jev is not trained on customer data, which rules out the easy explanation that it is quietly fine-tuned on each tenant’s traffic. Neither statement means no prompt or criteria design is needed on your side.

Confidence is a statistic, not a second opinion

Every choice and score answer carries a confidence field, and it is the field TypeSafe most wants you to build on. It is worth being precise about what it is, because it is easy to read it as a separate judgement about whether the model is right.

It is not. Confidence is “a statistic computed from the probability distribution” that measures how concentrated the distribution is: a distribution piled on one option gives 1.0, and the more evenly it spreads, the lower the confidence.²¹ The docs do not publish the general formula, but the interactive demo approximates it for three options as $(3 p_{\max} - 1)/2$. Run that on the severity example above and you get $(3 \times 0.57 - 1)/2 = 0.355$, which gives 0.355, close to the displayed 0.35. The demo is an approximation, and the displayed probabilities may already be rounded; this does not establish the production confidence formula. The openjev-sglang rebuild uses a different concentration statistic, one minus the normalised entropy, $1 - H(p)/\ln K$ for $K$ options, which gives 0.378 on the same distribution.²² The two give different numbers for this distribution, and can rank other distributions differently, which tells you something useful: confidence is a convenience view of the distribution, and any threshold you set on it is specific to how this vendor computes it.

Where confidence earns its place is the pattern TypeSafe calls confidence-gated routing. The documentation’s illustrative example is a banking assistant that picks an action with a choice question and then gates on both the action and the confidence: below 0.6 the request goes to a human agent; checking a balance is allowed at 0.6 because the consequences of a wrong read are small; approving a transfer needs above 0.85 and otherwise asks the user to confirm. The numbers are examples, not validated operating limits.²³

if action.confidence < 0.6:
    route_to_support_agent(account_id)
elif action.choice == "check_balance":
    show_balance(account_id)
elif action.choice == "approve_transfer":
    if action.confidence > 0.85:
        approve_transfer(account_id)
    else:
        ask_user_to_confirm(account_id)

That is a sensible shape for a system, and it is also the point where the whole product rests on calibration. A confidence cutoff of 0.85 is a vendor-specific threshold, not an 85% probability of correctness. Measure the observed error rate among decisions that pass each cutoff on your own traffic, then choose a threshold appropriate to the consequences of a mistake. Armin Ronacher’s comment to TechCrunch is the right posture: “if this only comes back with 50% probability, maybe this is a coin toss”, and you have to go and find out what each band means for you.²⁴ Two further interface limits matter: there is no enforced consistency across questions, because each question is answered in isolation, so two nouls you intended as complements need not sum to one; and there is no automatic abstention outside the supplied answer space, so a question the model does not understand still gets a distribution unless you add an explicit review option and fallback logic.²⁵

What the numbers say so far

TypeSafe’s evidence at launch was a set of four workflows, security-incident triage, agent-trace review, invoice processing, and customer service, each decomposed into Jev-style questions and run through Jev and eight LLMs, each tested in workflow and prompt configurations. TypeSafe built its answer key by averaging GPT-6 Astra and Claude Fable 5.1’s responses to the workflow questions, with both models at high thinking. The plotted percentage measures agreement with that key, not how often the decisions are independently known to be correct. Each of the four workflows contributes equally to the aggregate. The figure’s left panel plots that aggregate. Jev matches TypeSafe’s model-generated answer key 67.8% of the time on this aggregate metric, in the same band as GPT-5.6 Terra at 67.9% and Sonnet 5 at 67.8%, below Opus 5 at 73.1% and GPT-5.6 Sol at 74.1%, and at a cost per case of \$0.0004 and a latency of 0.4 seconds against \$0.0304 and 10.1 seconds for Terra.²⁶

Left panel: scatter of agreement with an answer key built from GPT-6 Astra and Claude Fable 5.1 against cost per case on a log axis for Jev and eight LLM configurations from TypeSafe's four-workflow evaluation; Jev sits at 67.8% and 0.0004 dollars, far left of every LLM. Right panel: horizontal log-scale bars of cost per million rubric verdicts from Good Start Labs: Jev 160 dollars, DeepSeek V4.1 Flash 260, GPT-5.6 Luna 400, Gemini 3.8 Flash 1,600, GPT-6 Astra 18,700, Claude Fable 5.1 33,000. — Left: Cost per case versus agreement with an answer key built from GPT-6 Astra and Claude Fable 5.1, both at high thinking. TypeSafe averages their responses to the workflow questions to create the key, then reports an equally weighted average across four workflows. A higher percentage means closer agreement with this model-generated key, not verified real-world correctness. Right: Good Start Labs' estimated cost per million rubric verdicts, based on 6,003 checks. Jev matched Fable 5.1 on 91.5% of checks at about 1/206 of its cost. These are different evaluations; neither panel establishes correctness from model agreement alone.

Two further limits matter. TypeSafe’s capabilities team designed the workflows, and its launch article says the largest reported gains may exceed typical real-world gains. TypeSafe also acknowledges that the sustainability of its early-access pricing remains to be demonstrated.²⁷

The independent evidence is more interesting, and it points in more than one direction. Each evaluation below measures something slightly different, so each one names its target and its sample.

As a judge, it agrees with the frontier. Good Start Labs graded 1,203 financial-research answers against rubrics, 6,003 checks in total, with Jev and five LLMs given the same instructions. Jev matched Claude Fable 5.1’s verdict 91.5% of the time and agreed with each of the five models between 86% and 92% of the time; the language models agreed with each other between 88% and 95%. The right panel of the figure shows the estimated cost: \$160 per million verdicts for Jev against \$33,000 for Fable 5.1 and \$400 for GPT-5.6 Luna. In a separate July run of 10,500 game-task grading calls, the authors reported roughly half a second per call. The authors are careful to say that agreement is evidence about a judge and does not establish who is right.²⁸

It beats a zero-shot encoder baseline on two small benchmark slices. A 300-example pilot reports Jev at 0.910 on AG News against 0.700 for the zero-shot encoder classifier GLiNER2.5, and 0.870 against 0.610 on Banking77, with an unresolved result on an emotion dataset.²⁹ A separate baseline study on a 200-item CLINC150 intent sample puts Jev 7.5 points above gpt-5.4-nano, with a paired 95% interval of +3.0 to +12.5, and 4.5 points below GPT-5.6 Terra; the same study found a supervised encoder stronger on Banking77 when labelled training data was available, at 0.933 against Jev’s 0.832.³⁰ A prompt-injection benchmark of 662 messages reports 96.5% accuracy and an ROC AUC of 0.9927 with a context-informed prompt, on a public corpus whose presence in training data is unknown.³¹

Its calibration depends on how you ask. On 192 yes/no judgments over 24 Norwegian consultation documents, Lindfors reported ECE rising from 0.040 with draft prompts to 0.116 with more carefully qualified prompts. The reference labels came from Fable 5.1, so this measures calibration against another model’s labels, the same caveat as the vendor chart; the revised run was underconfident at both ends.³² The CLINC150 experiment did not establish an error-ranking advantage for either model; its paired interval included zero. This tests ranking errors, not probability calibration. A separate benchmark, JevBench, which scores 52 systems across 534 decisions on intelligence, calibration, speed, and cost, ranks Jev first overall, though its calibration sub-score of 83 out of 100 is a benchmark component rather than a calibration percentage, and is not the highest on the board.³³

Narrow signals plus a fitted classifier improve the phishing result. The most instructive single experiment I found is a phishing benchmark with public code. On 2,000 synthetic emails, asked the broad question “is this phishing?”, Jev scored 62.6% with an ECE of 0.154, catching only 43.2% of the phishing and flagging 18.0% of the legitimate mail, while Claude Haiku 4.5 scored 81.3%. Then the author split the task into five narrow signals, such as whether a link uses free hosting or whether a free-mail sender claims to be an organisation, written after reading the dataset’s URL-evasion taxonomy, asked each as a noul, and fitted a logistic regression on 1,000 emails to combine them. On the other 1,000, Jev reached 95.0% against Haiku’s 93.2%. The reported accuracy rises substantially for both models, although these figures use different evaluation populations. The five-signal setup also adds a fitted logistic regression and questions informed by the dataset’s construction, so the improvement cannot be attributed to decomposition alone.³⁴

Grouped bar chart with two evaluation populations. Broad-verdict bars on all 2,000 emails: Jev 62.6%, Claude Haiku 4.5 81.3%. Five-signal-plus-logistic-fit bars on a separate 1,000-email test split: Jev 95.0%, Haiku 93.2%. A dotted line marks 50% chance and a note states the populations differ. — Results from jev-phishing-bench on synthetic emails. The broad-verdict bars use all 2,000 emails. The five-signal bars use a separate 1,000-email test split, after a logistic regression was fitted on the other 1,000. Both models' reported results improve, but this is not a paired before/after comparison on the same test set. Jev's 95.0% versus Haiku's 93.2% on the test split is not a statistically significant accuracy difference. Signal questions were informed by how the dataset was constructed.

That experiment is the one I would put on a slide, as a system-design lesson rather than a verdict. Jev did well when each question was a single, narrow, intuitive judgement and ordinary code did the combining, which is exactly the System One framing. Its broad phishing verdict performed poorly; this experiment does not isolate whether reasoning demands, question design, or the fitted combiner explains the gap. A strong simple baseline, the regex rule, was competitive with either model’s individual signals. TypeSafe’s jaggedness page describes the same limits in its own words: the model answers “the question you wrote, not the one you meant”, is “not a calculator”, “does not count reliably”, “reads dates as text, not as ordered quantities”, degrades as irrelevant context grows, and is unreliable on double negatives and multi-hop indirection.³⁵ The recommended workarounds move work out of the model: keep arithmetic in code, extract date parts and compare them yourself, filter the state before sending it, and split compound questions.

Is this just a classifier with good marketing?

The KDnuggets critique pointed out that classification and intent detection are not new, and that zero-shot classification via natural-language inference models has been a standard tool since 2019 or 2020.³⁶ The Hacker News thread had a long argument about whether a model that “cannot hallucinate” is a meaningful claim when it can still return a confidently wrong valid value. All three points are correct, and none of them settles the question.

On hallucination, TypeSafe’s own position is narrower than the marketing line. The launch post’s section on the topic says the guarantee is that outputs match the schema, a property that holds by construction rather than as an empirical finding. Almeida’s reply on Hacker News was that “type safety is not factual correctness” and that he would not say a linear classifier hallucinates in the way an LLM does.³⁷ That is fair as far as it goes. A wrong choice from a valid set is still wrong, and the honest way to say what Jev offers is: zero out-of-schema outputs, zero parse failures, zero invented tool names, and a probability on the value that TypeSafe aims to calibrate and users still need to validate, which is the thing that lets you decide how much to trust it.

On “it is just a classifier”, the useful question is what a trained classifier would cost you. A fine-tuned encoder gives you one fixed label set and needs labelled data per task, and where that data exists it can win. A zero-shot NLI classifier gives you arbitrary labels without training: in the cited pilot, Jev led GLiNER2.5 by 21 percentage points on AG News and 26 on Banking77, the emotion result was unresolved, and a separate benchmark found a supervised encoder stronger when labeled training data was available. Reading the logits of a chat model gives you arbitrary labels at good accuracy but with probabilities that inherit whatever RLHF did to the base model’s calibration, which is the problem the whole product exists to fix. Jev’s proposition is all three at once: any schema, no per-task training, and probabilities you can threshold, at a price where you can ask ten questions per event and not think about it. Whether the third leg holds is an empirical question that the early evidence answers with “often, and it depends on how you ask”, which is neither the vendor’s line nor the sceptics’.

What I would push back on is the comparison set. TypeSafe benchmarks against frontier LLMs because that is what its customers are currently paying for. But a team that already has a fine-tuned classifier for its one high-volume decision should compare against that, and the phishing result says a two-line regex is sometimes the baseline to beat. Jev’s advantage is breadth and low setup cost, subject to evaluation on your task, not supremacy on any single well-resourced problem.

Where it fits in a stack, and where it does not

Put the pieces together and a fairly specific picture emerges of where a System One model belongs.

In front of the LLM, as a router. Estimate whether a request is simple or hard, and send the simple ones to a cheap model. LangChain’s middleware does exactly this, and it is one potential source of savings, because the saving compounds across every call.
Around tool calls, as a gate. Before an agent runs a destructive action, require the estimated risk to be below a chosen cutoff and the evidence of user authorization to be above its cutoff, with review for uncertain cases. This is the pattern in TypeSafe’s confidence-routing docs and in LangChain’s auto mode.
After retrieval, as a reranker. Fetch a hundred candidates with BM25 or an embedding index, then score them in one call, within the context limits. Simon Willison’s write-up singles this out, and the parallel evaluation of questions is what makes it cheap.³⁸
In evaluation, as a judge. Rubric checks, guardrail checks, and “did the agent do what the user asked” checks, at a cost that lets you grade every trace rather than a sample. The Good Start Labs and Langfuse write-ups are both about this.
Not for anything that must produce text, explain itself, do arithmetic, compare dates, or follow a multi-step instruction. Those go to a language model, or to code.

The thing to notice is that none of these replaces the language model. They wrap it. That is the “harness” framing LangChain used, and it is also why Almeida can argue on one hand that chat models were built for the wrong consumer and on the other that TypeSafe uses GPT-6 Astra and Fable 5.1 to produce its own answer key.³⁹ A model that decides and a model that writes are complements. The interesting shift is which one sits in the hot loop. TypeSafe’s Doom demo makes this concrete: a bot that reads a text description of the game state and asks “what now?” ten times a second, at roughly \$7 an hour by TypeSafe’s report, which illustrates the value of low latency in a repeated decision loop.⁴⁰

What I would check before trusting it

If the value of the product is calibration, then the first thing to do with it is measure calibration on your own decisions, because none of the published numbers are about your data. That is a small amount of work. Log every decision with its stated probability, resolve the outcome later (a human review, a downstream signal, whatever your ground truth is), and compute the expected calibration error: bin the decisions by stated probability, take the gap between the average stated probability and the observed hit rate in each bin, and average the gaps weighted by bin size. For a noul, compare the stated probability of yes with the yes-or-no outcome; for a choice, compare the probability of the selected option with whether it was correct. Do not feed the vendor’s confidence statistic into this calculation, because it is not a probability.

\[\text{ECE} = \sum_{b=1}^{B} \frac{n_b}{N}\,\lvert \bar{p}_b - \bar{y}_b \rvert\]

The code below does it in a few lines and runs it on two synthetic logs of 5,000 decisions with stated probabilities between 0.5 and 1. In the honest log the outcome is drawn at exactly the stated rate; in the overconfident log a decision stated at $p$ is right with probability $0.2 + 0.6p$, so a 0.9 is really a 0.74. The honest log scores an ECE of 0.013 and the overconfident one 0.108, an illustration of how ECE responds to overconfidence, not a like-for-like comparison with Jev benchmarks.⁴¹ A reliability diagram of the same bins, hit rate against stated probability, will show you which band is lying, and that is the band your threshold should not live in.

Expected calibration error on a decision log, in numpy (click to expand)

Replace the two synthetic logs with your own arrays of stated top-choice probabilities and 0/1 outcomes. Ten bins is a starting point; inspect counts per bin and sensitivity to binning.

import numpy as np


def ece(p, correct, n_bins=10):
    """Expected calibration error of stated probabilities against 0/1 outcomes.

    Bins the decisions by stated probability, and for each bin takes the gap
    between the mean stated probability and the observed hit rate, weighted
    by the share of decisions that landed in the bin.
    """
    p = np.asarray(p, dtype=float)
    correct = np.asarray(correct, dtype=float)
    edges = np.linspace(0.0, 1.0, n_bins + 1)
    total = 0.0
    for lo, hi in zip(edges[:-1], edges[1:]):
        in_bin = (p > lo) & (p <= hi) if lo > 0 else (p >= lo) & (p <= hi)
        if in_bin.any():
            gap = abs(p[in_bin].mean() - correct[in_bin].mean())
            total += in_bin.mean() * gap
    return total


def ece_demo():
    rng = np.random.default_rng(0)
    n = 5000
    p = rng.uniform(0.5, 1.0, n)                      # stated probability of the top choice
    honest = rng.random(n) < p                        # right exactly as often as stated
    overconfident = rng.random(n) < 0.2 + 0.6 * p     # right less often than stated
    print(f"honest log        ECE = {ece(p, honest):.3f}")
    print(f"overconfident log ECE = {ece(p, overconfident):.3f}")


def confidence_demo():
    """Two 'confidence' statistics for the Score docs example (0.00, 0.57, 0.43)."""
    p = np.array([0.0, 0.57, 0.43])
    k = len(p)
    demo_formula = (k * p.max() - 1) / (k - 1)          # TypeSafe's three-option demo
    nz = p[p > 0]
    entropy = -(nz * np.log(nz)).sum()
    entropy_formula = 1 - entropy / np.log(k)            # used by the open rebuilds
    score = (np.arange(k) * p).sum()
    print(f"score = expected level = {score:.2f}")
    print(f"confidence, (k*max-1)/(k-1) = {demo_formula:.3f}")
    print(f"confidence, 1 - H/ln k      = {entropy_formula:.3f}")


confidence_demo()
ece_demo()
# score = expected level = 1.43
# confidence, (k*max-1)/(k-1) = 0.355
# confidence, 1 - H/ln k      = 0.378
# honest log        ECE = 0.013
# overconfident log ECE = 0.108

Beyond that, the list of what I would want from TypeSafe before building anything unsupervised on top of Jev is short and unsurprising. A paper, or at least a technical report, on RLCD: the founder has said one is being discussed. Calibration curves per question type, published by the vendor rather than reconstructed by hobbyists. A statement on pricing beyond early access. And a version of the workflow evaluation whose answer key comes from people. None of that stops you from using it today as a router, a gate, or a judge, when the surrounding system catches uncertain or incorrect decisions and routes them to review. It just decides how far up the stakes you let it climb.

One week is not long enough to know whether “System One model” becomes a category or a brand. What the first week does show is a typed decision API that returned labels, distributions, and scores fast and cheaply, matched frontier judges often enough to be worth measuring, and failed in documented, predictable ways. My judgement is that such an API can be a useful component when its measured errors and costs fit the application, and that the measuring is not optional.

Sources & further reading

Primary material from TypeSafe:

Introducing System One Models & Jev (TypeSafe AI, September 15, 2026) — the launch post: the System One framing, the RLCD description, the side-by-side and workflow evaluations with their caveats, the pricing-sustainability acknowledgement, the Doom and Wikiracing demos, and the Jevons name.
TypeSafe documentation — the pages used here are the Quick start, the Primitives overview and the Choice, Score, and Noul pages, Confidence, Confidence-gated routing under Patterns, Models, the API reference, the AI primer, and the Jev 1.13 jaggedness page. The jaggedness page is the most useful single document for deciding whether your task fits.
Workflow evaluations (TypeSafe AI) — the four workflows, the aggregated table transcribed into the figure, and the statement that the answer key averages GPT-6 Astra and Fable 5.1 at high thinking.
Introducing System One Models and Jev, Hacker News thread — 511 comments including the founder’s answers on parallel outputs, nondisclosure of the architecture, generality, and hallucination, cited by comment link in the footnotes.
What’s Next After RLHF? — Diogo Almeida, TypeSafe AI (AI Engineer, July 31, 2026) — the argument for calibrated decision models, given before the launch.
Jev: System One models for Prod, not God (Latent Space, September 21, 2026) — the long interview: mode collapse under RLHF, the synthetic-data lab, data over architecture, and what is next.
Diogo Almeida on X (September 15, 2026) — the launch thread, including the parallel-versus-sequential analogy.

Independent evaluations:

Verification is the bottleneck (Alex Duffy, Good Start Labs, September 15, 2026) — 6,003 rubric checks graded by Jev and five LLMs, with agreement rates and estimated cost per million verdicts.
jev-phishing-bench (September 17, 2026) — the public phishing experiment behind the second figure, with its broad-verdict and five-signal results and the regex baseline.
jev-benchmarks — the 300-example pilot comparing Jev with GLiNER2.5 on AG News, Banking77, and an emotion dataset.
jev-baselines-eval — the CLINC150 and Banking77 baseline study, including the supervised encoder comparison and the error-ranking test.
jev-sec-bench — the 662-message prompt-injection benchmark.
A first look at TypeSafe’s Jev (Lindfors, September 2026) — the Norwegian consultation experiment behind the prompt-wording calibration numbers.
JevBench v1.3.0 (Benchmark Heaven, September 21, 2026) — 52 systems across 534 decisions scored on intelligence, calibration, speed, and cost; harness on GitHub.
Jev, examined (compiled by Arun Babu Neelicattu, September 2026) — a compilation of the independent runs above, useful as an index.
Using TypeSafe’s Jev for evals (Langfuse, September 18, 2026) — a practical evaluator setup and a candid list of failure modes, including forced answers.

Commentary and integrations:

Jev introduces a new shape of LLM (Simon Willison, September 21, 2026) — the clearest short explanation of the API and the best statement of the auditability concern.
What Is Jev? A Guide to TypeSafe AI’s System One Model (Sydney Runkle and Hunter Lovell, LangChain, September 17, 2026) — the router and auto-mode middleware patterns.
What Everyone Is Getting Wrong About TypeSafe AI’s Jev (Abid Ali Awan, KDnuggets, September 21, 2026) — the sceptical case, well argued.
A new kind of AI model from a ChatGPT inventor is thrilling developers (Tim Fernholz, TechCrunch, September 18, 2026) — early-customer quotes and the synthetic-data claim.
TypeSafe AI debuts model for machines that plays Doom (Thomas Claburn, The Register, September 16, 2026) — launch coverage, including the separate side-by-side timing demonstration.
TypeSafe emerges from stealth with a new way of doing AI (DCVC, September 15, 2026) — the investor’s announcement and founder interview, with the funding details.
Jev: TypeSafe’s System One Model That Never Hallucinates (Matt Crabtree, DataCamp, September 16, 2026) and Jev explained in 7min (Caleb Writes Code, September 18, 2026) — the two recaps that, with the AI Engineer talk and the launch post, were the starting points for this post.

Open rebuilds:

openjev-sglang (Eric Zhang), openjev (razorback16), and kev (Jared Palmer) — three Jev-compatible servers on open weights, useful for exploring alternative implementations and their measured limitations.

Footnotes

The request and response follow the Choice page of TypeSafe’s documentation, including the reported token usage; the request there is given as an SDK example, and this is its JSON form. The model name jev-latest resolved to jev-1.13.0 at the time of writing. ↩
The 255-option and 10-level limits, the expected-value definition of score, and the advice to phrase nouls so that a high value means yes all come from the Primitives section of the documentation. “Noul” is TypeSafe’s coinage; the founder described it on Hacker News as “short for bernoulli”. ↩
Diogo Almeida, posting as CompleteSkeptic on the Hacker News launch thread, comment 49718407: “CEO here… text or structured state… decisions out (e.g. choice maps to match statement, score maps to sorting, noul short for bernoulli maps to if-statements)”. At the time of writing the thread stood at over 1,900 points and 511 comments. ↩
All from the Models page of the documentation, which also lists the price of \$0.042 per million input tokens with output free, and states that the model is not trained on customer data. These are vendor statements, not audited guarantees. Langfuse’s write-up notes that Jev is also reachable through OpenRouter and Vercel’s gateway. ↩
LangChain’s langchain-typesafe package wraps Jev as a TypeSafeClassifier and ships two middleware patterns: a router that uses Jev to estimate request complexity before choosing which LLM to call, and an “auto mode” gate that has Jev classify the risk of a tool call before it runs. Sydney Runkle and Hunter Lovell, September 17, 2026. ↩
The launch post, “Introducing System One Models & Jev”, September 15, 2026. The same post makes the headline claim that Jev “achieves similar levels of intelligence on System One tasks compared to existing LLMs, while being two orders of magnitude faster and more efficient”. ↩
TypeSafe was founded in 2024 by Almeida with Erik Gafni and Sasha Sheng; the \$40 million seed was led by DCVC and announced with the launch. Almeida appears on the InstructGPT author list and in the GPT-4 report and ChatGPT announcement credits. ↩
“What’s Next After RLHF?”, Diogo Almeida at AI Engineer, published July 31, 2026. It is the first of the two videos that prompted this post and is worth watching: it is the argument for the product, made before the product existed publicly. ↩
DCVC’s announcement and interview, “TypeSafe emerges from stealth with a new way of doing AI”, September 15, 2026. The 99% figure is the founder’s conditional prediction in that Q&A, not a present-day statistic. ↩
Jev-Mem, submitted on September 21, 2026, is a separate agent-memory system that uses TypeSafe’s Jev for structured memory decisions. It cites TypeSafe explicitly; it is an application of Jev, not a technical report describing Jev’s training. ↩
The KV cache post and the Scaling LLMs post cover why decoding one token for one request leaves the accelerator’s arithmetic units mostly idle, and why prefill, which processes the whole input at once, does not. Batched serving changes the arithmetic, so this is a description of the single-stream case rather than every deployment. ↩
Hacker News comments by CompleteSkeptic: 49718437 (“it is a structured data model, but technically not a language model (it doesn’t generate language)”), 49719122 (“strings (and all sequential data structures) are not allowed at all - this is how we make sure all outputs can be computed in parallel (thus no output token cost)”), and 49718824 (“architecture is close to the chest for now, but we have talked about writing a paper… data is probably far most interesting than architecture”). Other commenters in the thread speculated about a single forward pass and the absence of a decoder; those are not founder statements. ↩
Diogo Almeida on X, launch thread, September 15, 2026: “The gains aren’t free: Jev can’t generate text… Fun fact: replacing sequential computation with parallel is the same way Transformers leapfrogged RNNs”. ↩
openjev-sglang by Eric Zhang runs Qwen3.6-35B-A3B on SGLang with one first-token call per question plus a cache-warming call, renormalises the label log-probabilities with a softmax, and states plainly that its probabilities “are not calibrated estimates of correctness”. ↩
openjev by razorback16 runs on DiffusionGemma 26B-A4B under Apache-2.0 and reports about 94 ms per request at concurrency 1 on an RTX PRO 6000, its own measurement. A third project, Jared Palmer’s kev, fine-tunes Qwen3.5 models of 0.8B, 4B, and 9B parameters with a small pointer head over the option tokens and a fitted temperature; on its development set its 9B model scores 0.822 against Jev’s 0.857, with no matched test-set result for Jev. ↩
Hacker News comment 49718824 and the discussion around the 20-minute mark of the Latent Space interview. TechCrunch’s coverage adds that TypeSafe trains exclusively on synthetic data and quotes Almeida describing half the company as “a lab that basically owns this entire subfield”. ↩
The documentation’s AI primer describes RLCD as the method that “trains TypeSafe to return decisions and calibrated probabilities instead of generated text” and contrasts it with RLHF and RLVR in a diagram of three training paths from one pre-trained base. Latent Space’s introduction to its interview summarises it as optimising for “epistemically honest probabilities on System One tasks”; that phrasing is the podcast’s. ↩
The evaluation metrics post covers why calibration matters whenever a probability feeds a decision, and why a model can rank perfectly and still be badly calibrated. ↩
“Jev: System One models for Prod, not God”, Latent Space podcast with Diogo Almeida, September 21, 2026. The mode-collapse argument is the podcast’s; the narrower empirical observation that post-training reduced calibration on an MMLU subset is Figure 8 of the GPT-4 technical report, which does not show that every RLHF recipe damages every calibration metric. ↩
Hacker News comment 49719245, answering a three-part question about whether the model is general, whether it needs per-task training, and what it is focused on. ↩
The Confidence page of the documentation. It recommends three bands, act automatically, proceed with caution, and do not act, and says the thresholds “depend on your domain and the performance of the model for your use case”. Its demo code computes (count * peak - 1) / (count - 1) and calls it an approximation. ↩
Both numbers come from confidence_demo() in the foldable code block at the end of the post. The entropy form is documented in the openjev-sglang README. For a ranking reversal, compare the distributions (0.6, 0.2, 0.2) and (0.55, 0.45, 0): the peak-based statistic gives 0.400 and 0.325, the entropy-based one 0.135 and 0.374. ↩
The Confidence-gated routing page under Patterns in the documentation, quoted with its example thresholds. The separate Confidence page uses different illustrative values. ↩
Armin Ronacher, quoted in TechCrunch’s September 18, 2026 coverage, alongside Vercel’s Pranit Sharma, who reported replacing an OpenAI model in a safety-review step with results “five to 18 times more quickly and with greater accuracy”. ↩
Isolation between questions is documented on the Primitives page; the Choice page recommends adding an other or none of the above option. The forced-answer criticism is made in Langfuse’s write-up of using Jev as an evaluator. ↩
All numbers from the aggregated table at evals.typesafe.ai, “workflow” rows. TypeSafe attributes its headline 193.6x speed and 444.6x cost claims to the workflow evaluations, not to the separate side-by-side demonstration. Those headline ratios should not be reconstructed from the rounded aggregate values plotted here. ↩
Both caveats are in the launch post. TypeSafe acknowledges that it cannot yet demonstrate whether pricing is subsidized and says sustainability must be established over time. ↩
Alex Duffy, “Verification is the bottleneck”, Good Start Labs, September 15, 2026. Jev’s July verdicts were compared with September reruns of the LLM judges, and the run needed retries for a small number of failed calls, most of them from Fable 5.1. ↩
jev-benchmarks, a pilot with 100 examples per dataset; the Banking77 configuration exposes 72 hypotheses. These and the following runs are collected in “Jev, examined”, a compilation by Arun Babu Neelicattu, which is where I first found them. ↩
jev-baselines-eval, which also runs the error-ranking test discussed next. ↩
jev-sec-bench: 10 false positives and 13 false negatives on 662 messages, ECE 0.059, with a context-free prompt at 89.7%. ↩
“A first look at TypeSafe’s Jev”, September 2026. ↩
JevBench v1.3.0, run on September 21, 2026 by Benchmark Heaven, a self-described one-person hobby project with no TypeSafe affiliation; its harness and public tasks are MIT licensed. Jev 1.13.0 scored 74.4 overall with rounded sub-scores of 86 for intelligence, 83 for calibration, 83 for speed, and 52 for cost, at \$0.040 per thousand decisions. The two closest systems were an open rebuild on Qwen3.5-4B at 73.1 and a DiffusionGemma rebuild at 73.0. Not every entrant covers every tier, and v1.3.0 is a scoring revision rather than a simultaneous rerun of all systems. ↩
jev-phishing-bench, published September 17, 2026, on the PhishNChips v5.2 dataset, whose labels come from URL reputation feeds rather than a person reading each email. On the 1,000-email test split, the regex rule scored 91.8%, above Jev’s best single signal at 89.4% but below Haiku’s at 94.2%. The fitted five-signal models scored 95.0% for Jev and 93.2% for Haiku; their accuracy difference was not statistically significant (McNemar p = 0.063), and Haiku’s AUROC was higher at 0.991 against 0.982. ↩
Quotations from the “Jev 1.13 jaggedness” page. Langfuse’s evaluator write-up independently reports the same weaknesses on literal reading, arithmetic, and dates, and adds “context rot” as the state grows. ↩
Abid Ali Awan, “What Everyone Is Getting Wrong About TypeSafe AI’s Jev”, KDnuggets, September 21, 2026. ↩
Hacker News comments 49719080 and 49718767, both by CompleteSkeptic. ↩
Simon Willison, “Jev introduces a new shape of LLM”, September 21, 2026. He also ran a small experiment scoring Bay Area cities on “Good city?” and got Cupertino at the top and East Palo Alto at the bottom, which he uses to make the point that a model returning only a number is harder to audit for bias than one that shows its reasoning: “evals and structured experiments are even more important than they are for regular LLM projects”. ↩
Hacker News comment 49719816: “we actually use astra (and fable) in this way for our evals”. ↩
From the “Fun Demos” section of the launch post, which also describes a Wikiracing bot that navigates by choosing among the links on each page and so cannot pick a link that does not exist. ↩
Printed by ece_demo() in the block below. The 0.013 is not zero because it reflects sampling variation in this particular simulated log, not a universal noise floor. ECE also depends on the binning, the sample, and the target, which is why the published Jev figures above are not directly comparable with each other either. ↩

Citation Information

If you find this content useful, please cite this work as:

Bhana, Nish. "Jev and System One Models: Fast Decisions Instead of Generated Text". Nish Blog (September 2026). https://www.nishbhana.com/Jev-System-One-Models/

Or use the BibTeX citation:

@article{bhana2026jevsystem,
  title   = {Jev and System One Models: Fast Decisions Instead of Generated Text},
  author  = {Bhana, Nish},
  journal = {nishbhana.com},
  year    = {2026},
  month   = {September},
  url     = {https://www.nishbhana.com/Jev-System-One-Models/}
}

Share: x.com, Facebook