Jev's receipts, itemized

On September 15, 2026, TypeSafe AI's founder Diogo Almeida — who worked on the instruction-following research at OpenAI that became ChatGPT — published a launch post for a new model class, "System One Models," and its first member, Jev. The pitch: a model that takes unstructured state in and returns typed, probabilistic decisions out — no string generation, no parsing, "two orders of magnitude faster and more efficient" than an LLM doing the same job, priced at $0.042 per million input tokens with output free, and, per the model card, unable to hallucinate. The post's own framing sets the bar: "Extraordinary claims require extraordinary evidence so see below for the receipts. 💅"

I went and read the receipts — all of them. That means the launch post itself (including the parts collapsed into an FAQ accordion that don't show up in a casual read), the entire documentation site at docs.typesafe.ai (crawled via its own llms-full.txt, not just the one cookbook that gets linked around), the community reproductions tracker that's sprung up around it, a third-party architecture writeup, and — most useful of all — openjev, an independent, 706-row benchmark built specifically to check what open models can and can't match. This piece is about the product and the claims: pricing, speed, the intelligence claim, RLCD, and what's actually been independently verified. A companion piece, Parallel constrained decoding, covers the mechanism — why reading option logits instead of generating text gets you sub-second latency, and what training a calibrated version of that trick actually looks like in code. One paragraph on that here, then straight to the receipts.

What Jev actually is, in one paragraph

An ordinary LLM call for a decision — "which queue does this ticket go to" — samples a token, appends it, samples the next one, and repeats until it's spelled out a JSON object your code then has to parse. Jev skips the generation loop entirely: you send a state (a string, or a JSON object/array) plus a map of typed questions — Choice (pick one of up to 255 labeled options), Score (rate against an ordered rubric), or Noul (a yes/no that returns a probability, not a boolean) — and the model reads option logits directly off one forward pass, returning a full probability distribution per question in a single parallel call. Nothing is decoded token-by-token; nothing is parsed back out of prose. That architectural move — read the answer instead of writing it — is most of why the latency numbers below are real. Whether the probabilities that fall out of that architecture are trustworthy (the calibration claim, RLCD) is a separate question, and it's most of what this piece is about. The mechanism itself, and what training data you'd need to make those probabilities actually mean something, is the companion article's job, not this one.

// docs.typesafe.ai/api — a Noul question, verbatim
{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": { "type": "noul", "instructions": "Does this convey urgency?" }
  }
}
// response
{
  "model": "jev-latest",
  "answers": { "is_urgent": { "type": "noul", "noul": 0.92 } },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}

Hold onto that output_tokens: 48 — the model didn't write anything, and it still shows up on the bill's line item (which happens to be free). That's coming back later.

The claims, at a glance

Everything below is argued in full further down. This is the summary a skeptical reader can scan first.

The pricing: is "free output" a discount, or a definition?

The launch post's cost row is stark: existing LLMs run "$0.20 to $10 / MTok" input with output "~5x more expensive than input"; Jev runs $0.042 / MTok input ($42 per billion tokens), output "FREE (too cheap to meter)." The models page confirms it isn't a launch-week teaser rate: jev-1.13.0, $42/Btok, and — separately — real rate limits (250,000 tokens/second, 1,200 requests/minute, explicitly "adjusting dynamically" while TypeSafe scales GPU capacity).

Here's the arithmetic the post doesn't run. Jev's entire output space, for any single question, is a fixed enum: up to 255 labeled options for a Choice, an ordered rubric for a Score, one probability for a Noul. There is no string to generate. Whatever the model is internally doing to produce output_tokens: 48 in the example above — and neither the launch post nor the docs explain what that number represents, given that a third-party architecture analysis argues the field "is merely a billing figure, not evidence of text generation" — it costs TypeSafe nothing to hand you, because there's no marginal decode step scaling with an answer's length. "Free output tokens" is close to a definitional consequence of never generating an output, not a discount TypeSafe is choosing to extend. That doesn't make the underlying economics fake — a model that reads logits instead of writing prose really is cheaper to serve on the output side — but it's a different claim than "we cut our margins," and the post doesn't distinguish them.

What the $0.042/MTok input figure is worth, concretely: take the one real request/response pair from the docs above — 312 input tokens, 48 output tokens, for a single Noul question. Price that same call as a comparably-sized LLM call, using a real price from TypeSafe's own docs cookbook (claude-haiku-4-5, $1.00/$5.00 per MTok): $0.000312 + $0.00024 = $0.000552. Jev, input-only: 312 × $0.042 / 1e6 = $0.0000131. That's ~42x cheaper for this one exchange — and it's not a cherry-picked number: it lands in the same range as the measured 76x (claude-haiku-4-5 vs. Jev on a real 8-question rubric, see the interactive below), because both are the same underlying comparison — a large-input, tiny-output classification call against a per-token LLM price. The arithmetic is internally consistent. It just isn't the "40x-400x" the launch post's headline implies for every task shape; it's specifically what you get when the task is "mostly input, negligible output," which is exactly the shape a Choice/Score/Noul call always has by construction.

The latency: 70ms-500ms vs. 3-329 seconds

329 seconds is an extraordinary upper bound for "frontier models," and the post never names the task it came from. Read literally, the table implies Jev is somewhere between 6x and 4,700x faster than a frontier LLM doing "the same" job — a range wide enough to be nearly unfalsifiable, since almost any real number you measure will fall inside it. TypeSafe's own docs cookbooks run a fairer version of this comparison, and the chart above is built from their actual output: the same 8-question moderation rubric or 14-question insurance rubric, sent to Jev and to four LLMs forced into the identical JSON answer shape via TypeSafe's own System One LLM wrapper. Jev's own round trip: 111-114ms. The non-reasoning LLMs (gpt-5.4-mini, claude-haiku-4-5): 1.4-3.9 seconds. The reasoning models (gpt-5.5, claude-opus-4-8): 10.4-13.9 seconds — genuinely in the neighborhood of the post's 329-second upper bound's order of magnitude, but not close to it, and TypeSafe's own caption on this exact table adds a caveat the launch post skips: "Costs below use the historical price assumptions in Setup... They are not verified jev-latest prices or current billing amounts."

openjev's own systems benchmark measures the mechanism more directly, holding the model completely fixed. Same frozen Qwen/Qwen3.5-4B, same state, same 21 binary criteria, one RTX 3090: direct option-logit readout took a median 1.023 seconds and generated zero output tokens; asking the same model to autoregressively generate a compact ordered JSON array of yes/no values took a median 5.332 seconds — a 5.21x ratio, not the 47x-4,700x the launch post's raw seconds imply. That's the honest size of the architectural win, isolated from every other confound (a different model, a different task, a different hardware fleet, a different serving stack) that's baked into the "3-329 seconds" framing. The trick is real. The specific numbers in the launch post's table aren't measuring the trick alone.

"Frontier-level intelligence on System One tasks"

expand

This is the launch post's most-repeated chart, and it's worth being precise about what it measures. TypeSafe built a new evaluation type for it: rather than scoring against a fixed ground-truth label, they "assume there is a correct compute graph (a workflow represented in code)" and use "the predictions of the largest, smartest, and most expensive external models as reference probabilities" — specifically, the average of gpt-6-astra and fable-5.1. Every model, including the LLMs, is scored against how closely it matches that average, not against an independently verified answer. TypeSafe's own nuance section names two of the resulting biases directly: the reference "biases answers towards OpenAI and Anthropic's models," and "we likely underestimate the relative performance of our model and DeepSeek's models." The chart's headline claim — "Jev is off the charts, owning the Pareto frontier for almost 2 orders of magnitude" — is real within this self-designed evaluation, scored by TypeSafe, against a reference TypeSafe chose, on workflows TypeSafe's own capability team wrote (their words: "made by individuals on our model capabilities team, so some bias could exist").

TypeSafe is explicit, in the FAQ, that this is a deliberate choice, not an oversight:

That's a defensible epistemic position (public benchmarks do get gamed), and it's stated plainly rather than hidden — credit due. It also means "frontier-level intelligence" has, as of this writing, no independently-checkable number behind it except wherever outsiders manage to build their own. Two outsiders have tried.

openjev ran the most rigorous version. It froze Qwen/Qwen3.5-4B — a small, untrained, off-the-shelf open model, read via the same direct-option-logit trick, no fine-tuning at all — and evaluated it against 706 rows: 144 project-authored cases, 256 from the WANLI natural-language-inference dataset, 204 from a public "Every" lab's judgment/retrieval artifacts, and — the part that matters here — 102 rows drawn from TypeSafe's own publicly released evaluation cases (evals.typesafe.ai), aligned across 20 available comparison cases. On that 102-row TypeSafe subset, direct logits from the untrained 4B model reached 84.5% modal agreement with the reference distribution, against 88.3% for Jev's own published value on those same rows — a gap of 3.8 percentage points. On total-variation distance (a stricter measure of how close the full probability distribution is, not just the top pick): Jev scores 0.127, the untrained 4B model scores 0.177, the reranker scores 0.444. openjev's own read of that gap, stated carefully: "That is interesting, but it does not establish near-Jev capability: the sample is small and selected, Jev was not run by us, agreement is only one metric." Fair caveats — and the gap is still small enough that "an off-the-shelf 4B model with zero training gets within 4 points of Jev on Jev's own published evals" is a genuinely uncomfortable sentence for a model marketed as achieving "frontier levels of intelligence."

The reproductions tracker's second independent attempt, jev-on-a-laptop, reports a rougher version of the same story from the other direction: a 7B open model reaching 73.8% agreement against Jev's 86.6% on its own benchmark — a wider gap than openjev's, consistent with a smaller/less-tuned setup, but the same shape: real, but well short of Jev, on tasks nobody but TypeSafe designed.

expand

That diagram is worth sitting with, because it's the clearest picture TypeSafe publishes of what "System One task" actually means in practice, and it undercuts the "off the charts" framing in a different way: most of the intelligence in that pipeline is the human-written decision tree (Triage → Disposition → Containment → Playbook), and the AI's job is a series of narrow, typed reads at each node (is this unauthorized? which of eleven states is the incident in? which named action applies?). That's a legitimate, valuable use of a fast classifier — and it's a much smaller ask than "frontier-level intelligence" suggests, because the actual reasoning is in the code TypeSafe's engineers wrote, not in the model choosing what to do next.

"Can't hallucinate" — precisely

expand

The claim is real and narrower than the headline. Jev's output is drawn from a schema fixed at request time — a Choice answer can only be one of the options you supplied, a Score answer only a value on your rubric, a Noul only a probability on [0,1]. There is no code path that lets the model emit "shippign" instead of "shipping", or invent an option you never offered. TypeSafe's own words on the evidence bar: "No type errors: this would be an easy thing to falsify with just a single counter-example, but it is mathematically impossible." That's correct, and it's the strongest, best-supported claim in the whole post — it's a property of the decoding constraint, not a measured empirical result, and TypeSafe says so themselves in the same breath: "Our number is not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots."

Two things the framing elides. First, the comparison bars — the LLMs' 0.58% to 45.5% structured-output error rates — carry a disclosed caveat of their own: "The numbers for LLMs are from OpenRouter i.e., there almost certainly is bias here: more complex queries might be routed to better models." So the chart's right side is a real measurement with an acknowledged routing bias; the chart's left bar (Jev's 0%) is a logical guarantee with no measurement behind it at all. Both facts are true and disclosed; the chart visually treats them as the same kind of bar.

Second, and this is the part worth being exact about: "can't hallucinate" and "can't be wrong" are different claims, and only the first one is true. A schema violation and an incorrect answer are not the same failure mode — Jev genuinely cannot emit malformed output, and it can absolutely emit a confidently wrong, perfectly well-typed one. TypeSafe's own documentation says this directly, in the one sentence on the whole site that most precisely scopes every other claim: "System One models are trained for calibrated decisions: their probabilities are optimized against outcomes to reflect uncertainty. Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct." That's the real guarantee: type-safety by construction, plus a claim (not yet an independently-checked fact — see RLCD, below) about calibration in aggregate. It is not a correctness guarantee on any single answer, and the launch post's chart placement — right under a section titled "Hallucination and Type-safety," treating both as one bar chart — invites reading it as one.

Two more disclosures worth surfacing, both from the failure-modes page, both stated by TypeSafe about their own model: "State is data, and jev-1.13 does not treat it as hostile by default. Content written to adversarially steer the model... can move the answer." That's a prompt-injection risk, named by the vendor, not found by a critic. And: "jev-1.13 is not trained to generate text. While you can force it to by chaining choices, this will not work well and will be very slow." — a plain admission that "gives up string generation" is a hard architectural boundary, not a soft preference.

RLCD: what's actually disclosed

The training method behind every calibration claim in this piece is named exactly once with any specificity, in the launch post: "a training method we call Reinforcement Learning for Calibrated Decisions (RLCD)." The FAQ adds one paragraph of motivation and nothing about the mechanism:

That's a critique of RLHF and RLVR, not a description of RLCD. I crawled every page on docs.typesafe.ai — the primitives, the patterns, the SDK references, every cookbook — looking for a calibration curve, an ECE (expected calibration error) number, a Brier score, or a reliability diagram: TypeSafe's own docs contain zero of any of them. The closest thing to a specific claim is a "Calibrated confidence" feature card that reads, in full: "RLCD communicates uncertainty through calibrated probabilities instead of tending toward overconfidence," linking to an "AI primer" page that explains the motivation for training on calibration, not a method, a dataset, or a number. Calibration is measurable — ECE and reliability diagrams are the standard tools for exactly this — and TypeSafe doesn't publish either.

The third-party architecture writeup is the most sympathetic independent treatment RLCD has gotten, and it says the same thing from a different angle: after reverse-engineering the inference path through roughly 10,000 API calls, its author writes that TypeSafe calls its method "Reinforcement Learning for Calibrated Decisions" and describes it as "a post-training path from pretrained language models," but concedes plainly that "the exact recipe is unpublished." That writeup does contribute one real, independently-measured number: on a 1,200-item MMLU sample, it reports a ten-bin expected calibration error of 0.0313, with 990 of 1,200 predictions landing in the 0.9-1.0 confidence bin at 96.3% observed accuracy against 98.7% predicted. That's a genuinely low ECE for a black-box behavioral probe — but it's exactly that: one outsider's own measurement of Jev's outputs, with no TypeSafe-published curve to check it against, on a model whose training TypeSafe has never described. It tells you Jev's probabilities are reasonably well-calibrated on MMLU, as measured from outside. It tells you nothing about how RLCD produced that, or whether it holds up outside MMLU-shaped tasks — openjev's own perturbation tests (below) suggest it doesn't hold up under adversarial pressure the way a training-time calibration claim would want.

openjev's own accounting is the most direct. Its results doc lists, under "not reproduced or established": "RLCD training, because neither the training data nor a sufficient algorithmic specification is public" and "calibrated probabilities suitable for operational thresholds." Its own 36-case perturbation suite — reversing option order, wrapping the criterion in meaning-preserving phrasing, adding irrelevant context, all while holding the semantic question fixed — found argmax flips on 4 to 10 of the 36 cases per perturbation type on its own (untrained, non-RLCD) direct-logit baseline. That's not a Jev measurement; it's a baseline showing exactly the fragility RLCD would need to fix, and no test of whether Jev actually fixes it, because nobody outside TypeSafe can run one.

That gap between the name and the paper is exactly what shows up in the one HF repo publicly announced as training an open RLCD model. harshatheg/Qwen-2.5-1B-RLCD was posted with the line "Happy to open source Qwen-2.5-1B-RLCD." The repository contains zero weight files — usedStorage: 0, 26 files, all Python and config. Its own README is titled "Parallel Constrained Decoding for Apple Silicon" and runs stock mlx-community/Qwen2.5-1.5B-Instruct-4bit unmodified. It declares base_model: Qwen/Qwen2.5-1.5B-Instruct while the repo itself is named "1B." And the author's own post says it plainly: "No new training required." To be fair to the author, the README is the accurate document here — it correctly describes a parallel-constrained-decoding wrapper, not a trained model, and says so in its own words. The repo name is what claims RLCD; the README that lives inside it doesn't. That mismatch, one keystroke wide, is the entire current state of open RLCD: the architecture trick (parallel constrained decoding) is genuinely reproduced, same-day, on stock weights; the training method that would make the resulting probabilities mean something is, as of this writing, not.

Two years in stealth, and a Saturday afternoon

The launch post frames RLCD and the parallel sampler as the product of "two years in stealth, countless technical challenges, and research breakthroughs." The reproductions tracker — a community-run board with no TypeSafe affiliation, tracking every public attempt to reproduce any part of Jev — makes it easy to see which part of that sentence held up, because it separates "decoding" reproductions (the inference interface, on existing models) from "trained" ones (an actual attempt at the learning objective) as different categories. As of this writing it lists 36 artifacts:

• 14 "decoding" entries — architecture reproductions on stock, untrained models. openjev (WebGPU browser demo, 21 decisions in 1.02s), openjev-sglang (a drop-in /v1/systemone endpoint, 64 tasks in under a second), PocketJev (running locally on an iPhone via MLX), jevmlx, jev-on-a-laptop (the 73.8%-vs-86.6% benchmark above), jevfire (a claimed 10x speedup over vLLM), and eight more, most shipped within days of the launch post.
• 11 "trained" entries — genuine attempts at the learning objective, which is the harder and slower half. decider-2b (a full fine-tune of Qwen3.5-2B-Base on 942,000 examples), rlcd-modernbert-151m (a 151M ModernBERT encoder, sub-35ms, with a WebGPU playground), open-jev from pngwn (a Qwen3.5-4B LoRA with temperature scaling), and several more — real training runs, none yet benchmarked against Jev with numbers anyone has published.
• One entry, "Archer Hume's open-weight Jev," is listed with the status PROMISED — announced, training in progress, nothing released. That's the same person who wrote the architecture teardown cited throughout this piece; even the most technically invested outside observer hasn't shipped a trained reproduction.

expand

The fair reading holds two things at once, and the launch post's own phrasing blurs them. The architecture — parallel constrained decoding, read logits instead of generate text — is not what took two years, because outsiders rebuilt the interface pattern on stock models within hours to days of the announcement, using nothing more exotic than a forward hook and a softmax. What plausibly did take two years is a trained, calibrated model that's actually good at a wide range of decisions and knows when it doesn't know — and that part is exactly the part nobody, including the most motivated independent researchers on the tracker, has reproduced or been able to check. The launch post's dare — "extraordinary claims require extraordinary evidence" — turns out to apply unevenly to its own two central claims. The speed claim mostly clears that bar once you go looking. The calibration claim doesn't have a bar to clear yet, because there's no published evidence to hold it against.

What it's actually good for: two real deployments

Browser automation. browser-use/jev-ultrafast points Jev at a browser agent's decision loop — at every step, "pick an operation (CLICK, TYPE_TEXT, SELECT, SCROLL, WAIT, DONE) and pick a target element" — using TypeSafe's own "speculative fan-out" pattern to fold both decisions into one request instead of two sequential LLM calls. Its measured numbers, on a Zürich→London Google Flights search: 7.073 seconds end-to-end including every model call, browser action, and page-load wait; a median improvement from 9.450s to 7.092s (a 25% reduction) and a drop from 1,092 to 101 browser protocol calls across six runs, by replacing per-step screenshot-and-caption LLM reasoning with one typed decision per step. The repository is candid about scope: this is "three repeats of one task on one browser profile, not a general reliability benchmark," and a DONE choice "still requires independent outcome verification" — Jev picks the action, it doesn't confirm the action worked. It also discloses no dollar cost anywhere in the README. TypeSafe's own $0.042/MTok input pricing, applied to a task this input-heavy (a DOM snapshot is mostly text), would plausibly land in the low-cents range per full flight search — but that's my back-of-envelope estimate from the published price, not a number the repository states, and I'd rather say that plainly than borrow an unstated figure as if it were measured.

Confidence-gated fraud triage. A pattern that's circulated informally since launch, and that I could not pin to one stable, citable writeup despite looking: Jev scores 100 support/fraud emails in about 1.42 seconds, routes the 31 that fall below a 95% confidence threshold to a bigger model (Kimi K3) for a second opinion, and the blend gets 96 of 100 right for roughly $0.07 total — about $0.068 for the 31 Kimi calls and $0.003 for the 100 Jev calls. I'm reporting those numbers because they're a real, specific, and — critically — internally consistent instance of a pattern TypeSafe's own docs describe by name (confidence-gated routing: "use confidence as a second axis... the answer tells you what; confidence tells you whether to act"), and I'd rather flag the sourcing gap than either drop a good example or dress it up with a citation I don't actually have.

What's fully documented, and a useful cross-check on that pattern's shape, is an independent cascade benchmark — calibre — that runs Jev-plus-fallback (DeepSeek V4-Pro) across two real classification datasets with a full threshold sweep. On Banking77 (500 examples, 77 intent classes): Jev alone scores 77.8% for $0.0507/500 calls; DeepSeek alone scores 78.8% for $0.2207/500; the best cascade, at threshold 0.67, escalates only 58 of 500 (11.6%) and reaches 80.2% for $0.1033/500 — beating both single models on accuracy, at roughly half DeepSeek's cost. On Web of Science (500 abstracts, 145 classes), the same recipe at its own best threshold (0.37) matches Jev-alone's 52.8% while costing 46% more — routing bought nothing. The repository's own conclusion is the one worth remembering before trusting any single reported operating point, including the 95%-confidence fraud example above: "Every routing parameter measured on Banking77 came out differently on Web of Science... The optimal threshold moves from 0.67 to 0.37." calibre's calibration check on Banking77 adds one more caveat in the same direction: "every [confidence] tier sits below the diagonal: reported confidence runs ahead of measured accuracy at every level." Confidence-gated routing is a real, useful pattern — TypeSafe's own docs describe it correctly — and the one number any specific deployment reports for it doesn't transfer to the next task without being re-measured on that task.

Where this leaves the pitch

Read the launch post's own dare seriously — "extraordinary claims require extraordinary evidence" — and hold it against everything above, and the claims split cleanly into three kinds. Architecturally true, and the least interesting to have doubted: reading option logits instead of generating text is real, it's fast, and it's the one part outsiders reproduced the same week, on stock models, without needing TypeSafe's cooperation. The pricing follows from the same fact — free output tokens are close to automatic once there's no string to generate — which makes it honest, not a discount. True but narrower than the headline: "can't hallucinate" is a real, mathematically-guaranteed property of constrained decoding, and it is not a correctness guarantee, a distinction TypeSafe's own docs state more carefully than TypeSafe's own launch post does. Asserted, not yet shown: "frontier-level intelligence" rests on a self-designed, self-scored evaluation that an untrained 4B open model gets within a few points of; RLCD has a name, a one-paragraph rationale, and zero published calibration evidence anywhere on the documentation site I could find, three weeks after launch.

None of that makes Jev uninteresting — a genuinely fast, cheap, type-safe classifier that slots into ordinary software as "a smart if statement" is a real and useful thing to have, and the applications above (browser agents picking one action per step, confidence-gated cascades that only pay for a second opinion when they need one) are legitimate uses of exactly that. It does mean the size of the claim and the size of the evidence aren't the same size yet. The launch post asked for that comparison by name. This is what it looks like once you run it.