Jev Refuses to Write a Single Word: What TypeSafe AI's Decision Model Does, and What Nobody Has Verified Yet

Jev is the first model from TypeSafe AI that a reader is likely to meet through a cost table rather than a chat box, because there is no chat box. Launched on September 15, 2026 by Diogo Almeida — a co-author of the InstructGPT paper, the work that made ChatGPT behave like an assistant — Jev does not generate text at all. It takes a piece of state (an email, a log line, a support ticket, a JSON blob of game coordinates) plus a list of typed questions, and returns typed answers: a choice from a set you supplied, a score on a rubric, or a yes/no probability, each carrying its own confidence value. No prose, no code, no explanation. TypeSafe's pitch is that this narrowness is the product, because it buys speed and price a generative model cannot match — 20 to 200 times faster and 40 to 400 times cheaper than "comparable LLMs" on the company's own launch materials, at $0.042 per million input tokens with output billed at zero.

The most useful number published in the first 48 hours is not one of those. It comes from Every, whose head of evals ran Jev across 27 published Every articles plus 10 AI-styled counterparts, asking 21 questions of all 37 documents at once: 777 judgments in under 0.7 seconds, for roughly a quarter of a cent. A second test, run by Every's CEO, put 12 synthetic passages — six clean, six with defects deliberately planted — against four writing checks. Jev came back at a median 0.35 seconds per passage against 8.83 seconds for Claude Fable 5.1 at high effort: about 25 times faster at roughly 1/580th the cost. It caught six of the seven planted defects. Claude Fable 5.1 caught all seven. Every's verdict was "good but not perfect," and that is the honest one-line reading of Jev from the only independent test anyone has published so far — the speed and cost claims survive contact with a third party, the accuracy claim sits a notch below the frontier, and the sample is small enough that no one should be drawing a production conclusion from it.

A note on what kind of evidence this piece is working with, because the tiers are unusually far apart for a model this new. Jev is real and callable: there is a documented endpoint, a Python SDK, a model alias, and a published price. The launch is vendor-announced, not leaked, and nobody is guessing about whether it exists. But every performance claim TypeSafe leads with is TypeSafe's own, the architecture is unpublished, the weights are not out, and the benchmark dashboard behind the 20-200x headline is a set of internal workflow evaluations rather than a public leaderboard. One outside party has tested it. This article keeps vendor numbers, independent numbers and open questions visibly separate rather than averaging them into a consensus that does not exist.

What TypeSafe actually shipped

Jev is the first of what TypeSafe calls System One models — the name borrowed from Daniel Kahneman's fast, intuitive half of cognition, as opposed to the slower deliberative mode that chatbots imitate. The contrast TypeSafe draws is with the standard pattern of coercing a text generator into emitting structured output and then parsing that text back into something code can trust. Jev skips the text entirely. TypeSafe's own documentation states the case flatly: "Large language models (LLMs) are designed to produce text for humans to read. When you need a model to make a judgment that your code will consume, that creates a mismatch."

The output surface is three primitives, and there is nothing else. Every question you ask must be one of them:

• Choice — pick one option from a list you supply, returning the selected option plus a probability for each candidate and a confidence. Options are capped at 255 per field; beyond that TypeSafe documents a two-stage pattern of scoring candidates independently and then choosing.

• Score — place the state on an ordered rubric, returning the level, a probability per level, and a confidence. Churn risk on a 0-1 scale is the example in the docs.

• Noul — a portmanteau of "no" and "null" — a single yes/no claim, returning the calibrated probability that it is true.

The interesting property is not any one primitive but how they compose. All three can be mixed in a single API call, and every question is evaluated in parallel against one shared read of the same state. TypeSafe's documentation says adding questions "barely changes the response time," and the independent test backs that up in practice — 21 questions across 37 documents landed inside the same 0.7 seconds. That is what makes the price per judgment collapse: you are not paying for a longer generation, you are paying for one pass.

The practical envelope, as documented and as reported by early users: roughly a 32,000-token request budget, described in TypeSafe's docs as about 150,000 English characters; no image or audio input at launch; and a request and response shape that is not the OpenAI chat-completions convention, so calling it needs a bespoke client rather than a base-URL swap. Access is an early-access waitlist plus a browser playground, with code>jev-latest/code> as the model alias.

RLCD means calibrated, not preferred

TypeSafe trains Jev with a method it calls RLCD — Reinforcement Learning for Calibrated Decisions, per the company's own documentation. The acronym is new enough that early coverage has expanded it inconsistently, so it is worth pinning down what it actually names, because the distinction is the whole research claim.

RLHF optimises for human-preferred output. RLVR optimises for verifiable correctness, the test-case-passes kind. RLCD optimises for calibration: a model that says it is 70% confident should be right about 70% of the time. That is a different target from being right, and it is the reason every Jev answer ships with a probability distribution attached rather than just an answer. The intended failure mode is a model that knows when it does not know, so your code can decide what to do about it.

What that buys you in practice is a control surface. The documented pattern is three confidence bands — act automatically at the top, flag or confirm in the middle, route to a human at the bottom — with the thresholds living in your code rather than in the model. Whether the bands are honest is an empirical question about your data, and it is one TypeSafe explicitly tells you to answer yourself, noting that confidence thresholds are use-case-specific and should be tested against your own labelled examples. That instruction is the most important sentence in the documentation, and the reason the next section exists.

The numbers, sorted by who produced them

This is where most coverage of Jev goes soft, so it is worth being explicit about provenance. Here is what comes from the vendor, what came from an independent tester, and what is simply unknown.

• Vendor-reported, unreproduced — the headline speed and cost claims. 70-500ms end-to-end latency against 3-329 seconds for frontier LLM calls; 20-200x faster and 40-400x cheaper; a single best-case workflow result advertised at 193.6x faster and 444.6x cheaper. TypeSafe acknowledges these are best-case rather than universal figures.

• Vendor-reported, and checkable on the price sheet — $0.042 per million input tokens, which is $42 per billion, with output free. The reason output is free is mechanical rather than promotional: there is no autoregressive decoding to meter, so there are no output tokens to bill. For scale, the same launch materials put typical frontier input pricing at $0.20 to $10 per million, with output often around five times the input price.

• Vendor-reported, from an internal benchmark — TypeSafe's own workflow dashboard, 711 cases across four tasks, with reference answers derived from the average judgment of GPT-6 Astra and Claude Fable 5.1 rather than ground truth. On that dashboard Jev aggregates at 67.8% against 74.1% for the best comparator. Broken out: security incidents 61.7% against 66.2% for Opus 5; agent-trace observability 71.6% against 76.6%; invoice processing 61.8% against 79.1%; customer service 76.0% against 78.3%. Jev wins the cost and latency columns on that chart and loses the accuracy column. The dashboard itself notes possible harness bias, and TypeSafe has said it deliberately skipped public leaderboards in favour of one-off evaluations tied to product updates.

• Independently measured, small sample — the Every tests described above: 777 judgments in under 0.7 seconds for about a quarter of a cent; 1,709 judgments across 11 experiments for under a cent in total; roughly 25x faster and 1/580th the cost of Claude Fable 5.1 on a 12-passage classification task, while missing one of seven planted defects that the comparator caught. Every's own conclusion was that it would want a much more thorough accuracy check before putting it into production.

• Unknown — the architecture. No paper at launch, no parameter count, no training-compute disclosure, no weights. TypeSafe has said the details are being kept "close to the chest for now" with a paper possibly later.

The pattern across those tiers is consistent, and it is not the pattern the 200x headline suggests. Every independent and vendor number agrees that Jev is dramatically cheaper and dramatically faster. No number anywhere, including TypeSafe's own, shows it being more accurate than the frontier models it is priced against. On the vendor's own dashboard it lands around the level of a good mid-tier model. The comparison that holds up is not "as smart as a frontier model for a hundredth of the price" — it is "close to a mid-tier model's judgment at a fraction of a cent per call, fast enough to run on every single turn."

What "zero hallucination" does and does not mean

TypeSafe's launch materials include a chart showing a 0% tool-call error rate for Jev against a nonzero rate for comparison models, and the phrase "hallucination-resistant" travels with the model. Both are true and both are narrower than they read.

The guarantee is structural. Every possible answer is enumerated before the model runs — you supplied the choice list, the rubric, or the true/false claim — so there is no space in which to emit a value outside the declared type. A malformed tool call is not a thing Jev can produce. That is a genuine engineering property, and for anyone who has spent a week writing retry logic around JSON parsing failures, it is worth real money.

It is not a claim about being correct. A schema-valid answer can still be wrong: Jev can confidently route a billing complaint to the technical queue, and the output will be perfectly well-formed while being useless. Almeida has said as much himself, acknowledging that it is possible to be confidently wrong. The useful way to hold both facts is that Jev eliminates the class of error that comes from output formatting, and does nothing at all about the class that comes from judgment. Which means the accuracy question is entirely a calibration question, and calibration is exactly the thing you have to measure yourself.

How to test the calibration claim on your own data

Calibration is one of the few model properties you can check properly with a few hundred examples and no ML infrastructure, and it is the only test that matters before Jev touches a production path. The procedure is short.

Take a few hundred cases you already have labels for. Ask Jev the question that matters — the routing decision, the risk score, the defect check — and bucket the answers by the confidence it reported. Then check whether the 0.9-confidence bucket is right about 90% of the time, the 0.7 bucket about 70%, and so on. A well-calibrated model traces a diagonal line. A model that is merely confident clusters everything above 0.9 and is right 70% of the time, and that is the shape that quietly breaks an automated pipeline.

The same test tells you what thresholds to use. If the 0.9 bucket really is 90% accurate on your data, you can automate it. If your middle band is mush, you route it to a human or hand it to a generative model and let the expensive path handle the ambiguity. That split — cheap model on the confident majority, expensive model on the uncertain remainder — is the actual architecture Jev is arguing for, and it is the reason the model is best understood as a component rather than a replacement.

What it costs, worked through

The pricing is simple enough to reason about, which is rare. Input is $0.042 per million tokens. Output is free. At the documented request budget of roughly 150,000 characters, a single maximum-size call costs well under a cent.

Two reported figures give a sense of scale. An early user ran about 5,000 requests for roughly $2. The Doom demonstration — Jev steering a bot using a text description of game state rather than raw pixels — ran at about 10 calls per second for about $7 per hour. And Every's 777 judgments across 37 documents came in at approximately a quarter of a cent, which is the number that makes the interesting use case legible: at that price, checking every single turn of an agent loop stops being a cost decision and becomes a default.

That is the real argument for Jev. A per-turn verification pass — did this tool call contradict the previous one, is this output consistent with the user's stated intent, should this raise a flag — has always been technically possible with a frontier model and economically absurd at scale. At $0.042 per million tokens with no output charge, the same pass becomes affordable on every turn. The value here is not that Jev thinks better than a frontier model, because it does not. The value is that it thinks cheaply and quickly enough to be consulted constantly.

Worth stating plainly, because it is the obvious next question: OrcaRouter does not serve Jev. TypeSafe's model is early-access, waitlisted, and speaks its own request shape, so anyone testing it goes through TypeSafe directly. Where a routing layer does fit is the other half of the workflow. The pattern Jev is designed for is two models, not one — Jev makes the typed decision, and a generative model handles the part that needs prose, code or an explanation. That generative half is the part OrcaRouter covers: 197 models across 15 providers behind one OpenAI-compatible key, at provider list price passed through with 0% markup, so a vendor price cut lands on our side the same day it ships. Both halves of a Jev-shaped workflow are testable without a second contract, and when the decision component is unproven, the failover path is what keeps a bad calibration result from becoming a production incident.

Where Jev does not fit

The limitations are unusually clearly stated by the vendor, which makes this section easy to write honestly. Jev cannot generate free text. It cannot write code. It cannot hold a conversation. It has no chat interface, no image input, and a context budget around 32,000 tokens — an order of magnitude below the long-context models it is being compared against on price. Choice fields cap at 255 options. And the "no hallucination" property, as above, is about output format rather than truth.

The net is a fairly narrow fit. Good: high-volume classification and routing, guardrail and verification passes, latency-critical decisions, scoring large document sets in parallel, anywhere the correct answer is genuinely a choice, a number on a scale, or a boolean. Poor: open-ended generation of any kind, long-context reasoning, multi-turn dialogue, or any task whose right answer is a sentence. If your problem does not reduce to a typed question, Jev is not a cheaper way to solve it — it is not a way to solve it at all.

There is also a fair criticism of the framing that is worth carrying forward. Calling Jev a frontier model borrows credibility the model has not earned: it cannot code, chat, or write a sentence, and the comparison charts lean on frontier models as the baseline while the accuracy column tells a different story. The more defensible claim, and the one the evidence actually supports, is that TypeSafe has pushed the speed-and-cost frontier for structured decisions a long way out. That is a substantial thing to have done. It is a different thing from building a model that rivals GPT-6 Astra or Claude Fable 5.1.

What would change this picture

Three things, in rough order of how much they would matter.

• A published architecture paper or open weights. Everything about how Jev achieves its speed is currently a black box, and the claim that parallel evaluation is the mechanism — the analogy Almeida draws is replacing sequential computation the way transformers replaced recurrent networks — is an assertion rather than a demonstrated result. Until the design is published, the speed is a fact and the explanation is marketing.

• A second independent evaluation with a larger sample. Every's tests are the strongest evidence available and they cover 12 passages on the decisive accuracy question. One more independent run, on a few hundred labelled cases, would settle whether missing one defect in seven was noise or the real error rate.

• A calibration audit on realistic, messy input. Everything published so far uses clean test harnesses. The open question for a model whose entire value proposition rests on trustworthy confidence scores is what those scores do on the genuinely ambiguous cases — the ones where a human reviewer would also hesitate. That is the number that determines whether Jev is safe to automate against, and nobody has published it.

Until then the reasonable posture is specific rather than general. Jev is a real, shipped, unusually cheap model with a genuine structural advantage in output reliability, an accuracy profile that sits around the mid-tier, and a calibration claim that is plausible, explicitly recommended for self-testing by its own vendor, and independently validated only on a small sample. If your workflow has a step that reduces to a typed question asked often enough that a frontier model would be wasteful, this is one of the cheapest ways to ask it — and the confidence value it returns is the part to test before you trust, not the speed.