A yes/no question where the probability itself is the signal.
One option from a set you define, with no order between the options.
A position on an ordered spectrum whose levels you describe.
A single number from 0 to 1 collapsing the shape of the probability distribution: concentrated means certain, flat means uncertain.
Reverse-engineered from the ConfidenceExplorer widget embedded in https://docs.typesafe.ai/confidence, which states the three-option case as (3 × p_max − 1) / 2. TypeSafe does NOT publish the production formula.
It is an approximation. Recomputing it from the probabilities printed in the docs matches most worked examples but not all. Two Score examples differ materially — a 5-level case with probabilities {1:0.14, 2:0.86} is documented at confidence 0.89 where this formula gives 0.83 — and the Choice example in the API reference differs by 0.01 (documented 0.81, formula 0.82), which is consistent with its printed probabilities being rounded to two places. TypeSafe does not publish the production formula. Treat this as a close approximation for display, and act on the `confidence` the API actually returns.
The docs use different cut points for different stakes rather than one number: a generic 0.5 floor for routing to a human, 0.6 in a voice-banking example, 0.85 before auto-approving a transfer, above 0.9 for destructive actions, below 0.3 for manual triage, and a 0.8/0.2 band for nouls with the middle going to a reviewer. This app defaults to 0.75/0.40 and lets each call override.
Nouls are the exception. Noul answers carry no confidence. This app derives a "distance from the coin flip" figure (|noul − 0.5| × 2) purely so nouls can be banded in the UI — that derivation is ours, not a TypeSafe statistic, and is labelled as derived wherever it is shown. Note the vendor’s own caution under "Common-sense structural invariants" below: Noul values and Choice confidences are not on a comparable scale, and a threshold tuned on one should not be carried to the other. This app bands them side by side for display and marks the noul figure as derived, but a gate that matters should be tuned per question type.
TypeSafe recommends splitting confidence into three ranges: high → act automatically, medium → proceed with caution or flag for review, low → do not act, route to a human. The docs are explicit that "a confidence threshold is not one number" and that the boundaries scale with the stakes, so the 0.75/0.40 cut points this app uses are its own defaults, not vendor constants.
Unverified. No calibration curve has been published by TypeSafe or by anyone else, so how well these probabilities track real-world frequencies is untested in public.
| Failure mode | What happens | Do this instead |
|---|---|---|
| Literal reading | It answers the question you wrote, not the one you meant. Negations and scoping words are read at face value. | State the exact condition; put boundary cases in the criteria. If you catch yourself explaining what you really meant, that explanation is the missing half of the instruction. |
| Math and counting | Not a calculator. It does not count reliably — characters, occurrences, or items in a long list — and error grows with size. | Count in code. Ask one question per item and add up the answers yourself. |
| Numeric representations | Performs worse on numeric forms than semantic ones — hex colors versus color names, assembly versus high-level code. | Convert in code and pass a name or a bucket. |
| Score arithmetic | Score levels are weakly calibrated numerically; you cannot reconstruct an exact quantity by interpolating between levels. | Use the expectation for a threshold test only. |
| Date and time comparison | Reads dates as text, not ordered quantities. Ordering, duration and window membership are unreliable. | Extract date parts as Choices over closed sets, then do all arithmetic in code. |
| Indirection | Double negatives and multi-hop reasoning — a property of a property — cost accuracy. | Write instructions directly and name the relevant state field. |
| Large state full of irrelevant detail | Accuracy falls as the state grows with content unrelated to the decision; unrelated detail acts as a distractor. | Filter in code first and send only the fields the question needs. |
| Adversarial content | State is data, and jev-1.13 does not treat it as hostile by default. Injected instructions or self-serving framing can move the answer. | Be explicit in the criteria and test edge cases before deploying. |
| Contradictory instructions and criteria | When instructions and criteria ask for different things the model gets confused — e.g. a noul whose `true` maps to "no". | Treat the criteria as an extension of the instruction and align the two. |
| Common-sense structural invariants | Jev is consistent for similar inputs, but the structural identities you would expect between questions do not hold. The docs ask "Is the customer asking for a refund?" as a Noul and as a yes/no Choice on the same ticket and get noul 0.22 against Choice yes 0.01 / no 0.99 at confidence 0.97. A question and its negation asked as two Nouls sum to 1.19, not 1. | Do not carry a threshold tuned on a Noul over to a Choice, and do not hold the model to arithmetic identities across separate questions. A Choice is relative — it settles which option — while each Noul is absolute and can be low for all of them. |
| Generation | It does not generate text. That is the design, not a defect. | Use a generative model for generation. |
Jev sits between complicated incoming information and code that already has processes waiting. The classifier decides only what the input MEANS inside a limited answer set the caller supplies up front — a category, a priority judgment, a risk flag — and deterministic code downstream uses that verdict to select an existing process: who gets it, how fast it gets attention, whether a human is asked. A generative model appears only AFTER the decision, if at all, to write whatever text the chosen process needs; the video's phrasing is that the decision to spend an LLM on something 'already got decided by Jev' (00:14:55). The video later names this arrangement 'a shim where you can see information calls out' (00:18:22).
The same complicated-in / simple-out contract, but pointed at a whole corpus instead of one inbound item. Jev decides which members of a large candidate set matter most, and the ranking itself is the product — no code branch hangs off each individual verdict. What sits around it is a corpus on one side and expensive intelligence (an LLM, or a human expert) on the other, working only the shortlist Jev hands back. The video is explicit that Jev is not answering the selected items: 'I'm not saying that Jev can look at the immunology questions and immediately solve them. That's an LLM-shaped problem' (00:17:56). It names the pattern as Jev being 'a figure outer of big problem spaces... something that helps us pick out what matters from this giant pile' (00:18:22-00:18:47), and argues the value case from information growth: 'as information grows and grows and grows faster and faster in the age of AI, getting attention right is incredibly valuable' (00:18:22).
This arrangement reverses who drives the work. Instead of an LLM running the loop and calling tools, the classifier is the outer decider: given the current state of a document, a task or a page, Jev picks the next step from a fixed set — call a deterministic tool, call an LLM to produce text, escalate to a frontier reasoning model because this is a hard exception, or hand off to a human — and the result is dispatched by the surrounding program. Generative models become effects inside the loop rather than the thing steering it. The video's summary line is that in both the workflow case and the browser case 'Jev is basically deciding what goes where' (00:21:00).
The arrangement the video calls the most exciting. There is not necessarily an LLM in play at all. Application code enumerates all the available components, actions and output options in advance; Jev's only job is to interpret what the user is trying to do right now and choose the fitting response fast enough to feel like part of the interface. Deterministic machinery then composes the resulting judgments with ordinary data — 'ordinary formulas can combine all those judgments with dates and amounts' (00:21:53) — and a generative model, if it appears, arrives only at the end for the eventual written response, never for the classification itself. The video's point is what happens to a surface when judgment gets cheap enough to be ambient: a spreadsheet 'becomes a place where calculations and language judgments are working together seamlessly' (00:22:18).
| Idea | What the video argues |
|---|---|
| Semi-deterministic work: the glue between language and choice 00:04:39-00:05:58 | The video's own coinage for the class of work Jev addresses. Deterministic code handles conditions you can write down precisely — an invoice 30 days overdue, an order total over a limit (00:02:06). Semi-deterministic work is what sits one step past that: questions like 'does the customer sound like they're about to leave the contract in this email?' or 'does this email contain a serious business opportunity or does it just have the words business opportunity in it?' (00:02:31). The presenter defines the term as 'the glue between language and choice' (00:05:05): you or an agent define a short list of available outcomes and what happens after each one, then hand an arbitrarily complicated input in and ask the model to sort. The determinism is in the OUTPUT SHAPE and the downstream branch, not in the judgment — 'judgment does remain probabilistic. We don't write the specific rules... judgment is still happening through a transformer architecture, but because the output is so structured and because Jev was trained specifically for this kind of general-purpose decisioning, we get it really fast, really really cheap' (00:05:32-00:05:58). The reusable test the video gives for spotting one of these problems is a shape: 'complicated in, simple out' (00:11:34) — text you must genuinely interpret going in, and a category, a score, or a yes/no to proceed coming out (00:03:22). |
| The third primitive: deterministic code, LLMs, and now a general-purpose classifier 00:12:24-00:13:39 | The video's central architectural argument. 'Really before now, before the 15th of September when Jev launched, you had two capabilities to build software with. You had deterministic code and you had LLMs. Now you have three' (00:12:24). The three, as the video enumerates them: generative models 'that can reason and develop plans, that can use symbolic language, that can write'; a general-purpose classifier 'that can interpret any situation and choose very reliably among defined outcomes'; and deterministic code 'that can calculate and retrieve records. We've been familiar with that one for 80 years' (00:12:49). A primitive, it glosses, is 'just a fancy word for a building block that other people can compose into products' (00:11:34) — the point being that language understanding is now available 'at the level of an ordinary software function in a way that ties language into simple choice' (00:11:59). The argument for why this is a category and not a product: what was missing was not classification but a GENERAL-PURPOSE one. Machine-learning classifiers are decades old and cheap to run once built, but 'until now they've pretty much all been custom' — every new category meant data labelling, specialised expertise and its own evaluation, an investment only a giant stable platform could justify, and so 'you're not ever going to justify the millions and billions of tiny classifier-type judgments that are scattered through all of our digital products' (00:06:23-00:07:14). LLMs partly closed that gap, and the video's uncomfortable question is how much we have been doing with the wrong tool: 'how often have we been using an LLM, a text-generating token architecture, as a general-purpose classifier?' (00:08:05). The presenter stakes his strongest claim here — 'the history of software is the history of finding these new building blocks. When ChatGPT launched we got that new building block, the first new building block in decades... Now we have a third one. That's how big this is. One of the biggest events in the history of computer science in my view' (00:13:14). Note this is the commentator's framing, not a vendor claim. |
| Jevons paradox: cheap classification changes which questions are worth asking 00:27:04-00:29:36 | The strategic close, and the reason for the model's name. 'The strategic effect of a large cost reduction is that it changes which questions are worth asking. It increases the possible uses of intelligence' (00:27:30). The video gives the saving and then dismisses it as the small half of the story: 'If classification is 10% of your existing AI bill today, imagine making it 1%. It saves roughly your entire slice. Your current bill is only the beginning of the story, though, because Jevons paradox reminds us that the work you decided was worth paying for when it was expensive is not all of the work you would want to do if it was cheap' (00:27:30-00:27:55). The consequence is a change in FREQUENCY and GRANULARITY, not just unit price: 'tasks that were done once per document become daily, per section, or per customer, or per interaction. A decision at the beginning of an agent task becomes a safety decision you can make at every relevant step' (00:28:21-00:28:46). Its three worked illustrations: a company that samples customer calls can examine every call every time for multiple kinds of problems and evolve the classifier on the fly; a team that tags documents once can reclassify its whole history every day when a new opportunity appears; an interface that asks you to stop and explain what you want can instead evolve and suggest as you work (00:27:55-00:28:21). The naming: 'William Stanley Jevons of course observed that greater efficiency could expand the uses of a resource enough to increase overall consumption. That was back in the 19th century. TypeSafe named the model for that idea because cheaper intelligence can create massively more demand for intelligence in places where there was previously no model that we would really be able to afford to use' (00:28:46-00:29:11), which the presenter sums up as 'intelligence too cheap to meter' (00:29:11). Caption artifacts to ignore: 'Jieven's', 'Jievens' and 'William Stanley Jivens' are all Jevons. |
| The corollary: cheap classification grows the LLM pie rather than shrinking it 00:01:15-00:30:03 | The video repeatedly refuses the substitution reading, and this is the load-bearing qualifier on everything above. It states the position up front — 'I'm not here to tell you that Jev replaces LLMs. And that's exactly why it matters so much' (00:01:15) — restates it mid-argument (00:15:21: 'I am not saying that LLMs are done. Quite the opposite') and works out the mechanism at the end: more classification 'can uncover a whole universe of new opportunities worth pursuing, more questions worth investigating with high-grade intelligence, and more exceptions that require LLMs to think and ultimately humans to think. Each of those can create work for a model that reasons and writes with language. So the total pie of useful AI work, including LLM work, is growing really, really rapidly' (00:29:36-00:30:03). The division of labour it draws: selection, triage, gating and routing are classifier-shaped; 'systems that reason and write and invent and explain... those are LLM-shaped problems' (00:31:44). Its diagnosis of why adoption moved so fast is about recognition rather than novelty: 'We've used rules where interpretation was needed. We've built dedicated classifiers when the investment made sense. We've put LLMs into countless places where the immediate output was a decision. Now we all have a new building block' (00:30:28). |
| The cost and speed numbers as the video states them, and what the sources actually say 00:00:25-00:26:39 | Two headline figures carry the video's economics, and both need correction before a reader relies on them. PRICE (00:24:52-00:26:39, all correct except one rounding): TypeSafe's own model documentation lists Jev at $0.042 per million input tokens — $42 per billion — with output tokens free, and the video's arithmetic at a chosen hypothetical of 1,000 input tokens per request holds: 10,000 calls is 42 cents and a million requests is $42, landing exactly on the vendor's per-Btok line. Its '1,000 calls cost you 4 cents' is the documented 4.2 cents rounded down, and its spoken chain ('4 cents... which means 10,000 calls cost 42 cents') does not follow as stated. Two things the video does not mention: this is vendor list price on input tokens only, never an invoiced or independently replicated cost; and the same documentation page caps Jev at 1,200 requests per minute, so the million-request scenario would take roughly 13.9 hours rather than being available on demand. VENDOR GAINS (00:26:39): the video says TypeSafe's launch evaluation 'reported gains approaching two orders of magnitude or 100x faster on speed and more than two orders of magnitude or more than 100x cheaper in cost compared to an LLM.' TypeSafe's launch post actually claims 193.6x faster and 444.6x cheaper — so the speed figure is understated by about half and 'approaching' points the wrong way, while the cost figure is reduced to a floor about a quarter of the published number. The string '100x' appears nowhere in the vendor's post and must not be attributed to it. Three vendor caveats the video drops: TypeSafe calls these figures 'on the higher end of real world gains'; the test cases were 'made by individuals on our model capabilities team, so some bias could exist'; and the LLM baseline is not a raw LLM but LLMs run through TypeSafe's own 'System One LLM wrapper, which constrains LLMs to output structured decisions.' ADOPTION (00:00:25): the video's 'fastest adopted model in Vercel's AI gateway history. Faster than any LLM from any lab' overstates its source — Vercel, reporting its own unaudited platform data on 18 September 2026, wrote that Jev 'reached more than twice as many paid teams as any previous model launch,' with 'nearly 13% of paid teams' using it by hour 24. The metric is share of Vercel's own paid customer base, the comparison set is other launches on Vercel's gateway, nothing about 'any lab' appears in the source, Vercel never says those teams paid for Jev, and Vercel's own caveat — 'the next test is whether that early adoption lasts' — is dropped. |
| Claim | Context |
|---|---|
| 193.6× faster and 444.6× cheaper on System One tasks | TypeSafe’s homepage headline. The company itself writes that these "are on the higher end of real world gains" — i.e. a ceiling, not a typical result. |
| End-to-end response time of 70ms–500ms, versus 3 to 329 seconds for LLMs | Vendor-measured. TypeSafe discloses the caveat itself in the launch post’s Evidence section: its published latencies are taken from the US West Coast, where the service runs. No latency measurement from a neutral network location exists. |
| 40×–200× faster at comparable intelligence | Vendor site. Restatements in coverage diverge wildly — 100×, 200×, 20–200× — and no two agree. |
| Accuracy 67.8% for Jev versus 74.1% for the best comparator | Self-disclosed by TypeSafe. Never independently replicated. Note it is the vendor reporting itself as LESS accurate than the comparator. |
| Never makes type errors; output is always within the supplied option set | A structural property of constrained decoding rather than a benchmark, and the one claim that is straightforwardly checkable from the response shape. |
| Does not hallucinate | TypeSafe states plainly that "Our number is not empirical." The Register objects that the comparison is unfair because Jev’s output is not natural language in the first place. |
| 238× lower input price than Claude Fable 5.1 | Printed on TypeSafe’s homepage. This is a list-price ratio on input tokens only — a different quantity from the 444.6× workflow-cost headline beside it, which is why the two do not match. The Register repeats the 238× figure; it did not derive it. |
The only genuine third-party measurement found. Median 0.35 s per passage for Jev versus 8.83 s for Claude Fable 5.1 (~25× faster); 777 judgments across 37 documents in under 0.7 s for about a quarter of a cent; estimated ~580× lower total cost.
On accuracy the result was mixed, not a win: Jev caught 6 of 7 planted defects, Fable 5.1 caught all 7. Taylor said he would want a more thorough accuracy check before production use.
Third-party but self-reported. Rebuilding his company’s tax-document page classifier on Jev measured $0.00115 per page at ~0.5 s warm latency, against his own previous Claude Sonnet pipeline at $0.039 per page and ~3.3 s — 33.9× cheaper and 6.6× faster, which he published rounded as “34x cheaper and 6x faster than the LLM setup”. It classified 100% of a 314-page TaxCalcBench filled-form corpus across 15 forms with 0 strict errors for $0.36 total, and 753 blank IRS form pages covering 261 forms for $0.86 with 38 low-confidence results (5.05%) and none incorrect. Method note, verbatim: “Measured on the same bench pages, same machine, same hour.” Unusually for this list, the code and the per-page table are both public.
Not an independent benchmark — the baseline is his own earlier pipeline (“an LLM pipeline I built last tax season”), so the same person wrote both sides. The README also discloses that the predecessor “sends each page as a PDF to Claude Sonnet with the form registry in the prompt; different pages never share the prompt cache, so every page pays the full prompt”, and an uncached full-prompt-per-page baseline inflates the cost multiple against any cache-optimised or batched Sonnet setup. Scope is narrower than it sounds: page classification only — one of 261 IRS forms plus 7 page kinds, which the README calls “document triage, not tax advice” — measured over roughly a thousand bench pages, not the “thousands” of production documents his post describes ingesting. Text layer only (scanned pages need OCR first), federal forms only, English only, and the confidence gate is calibrated on his corpora, not yours. The X post carries only the two multipliers; the numbers live in the README.
Third-party but self-reported. A spreadsheet demo published 2026-09-18 in which typing a header such as `Urgency` into an empty row-1 cell beside a text column sends one Choice request — header text plus three sample rows — that picks one of 14 prediction schemas in 72–132 ms, and, on Enter, fills the column through `=JUDGE` / `=PICK` / `=RATE` cells mapping to noul / choice / score. Measured: 300 rows in 3.5–5.2 s wall time, p50 114–120 ms, p95 259–379 ms, 57–85 rows/s; “Mentions a defect?” 300 rows in 4.7 s; “Ready to buy?” 150 rows in 1.9 s. It is the best public illustration of the batching economics recorded under pricing.
Self-measured on “real API, jev-latest, 12 concurrent lanes, Linux VM”, never independently reproduced, and the repo’s headline “230–339× faster” rests on an author-stipulated “per-cell LLM @ 4 s” baseline rather than a measured competitor run. Two framings to resist, both of which circulate: the column does not fill instantaneously — only the header intent read is sub-second, and Dabit’s own “~100 ms” refers to that read, not to the fill — and typing alone classifies nothing, since the fill waits on Enter and stalled requests are “aborted after 2.5 s and retried”. It also requires an empty row-1 cell immediately right of a text column, and picks from 14 fixed schemas rather than interpreting arbitrary headers. Dabit published and promoted it, but the repo states the demos were “built by Devin”, the PRs were opened by devin-ai-integration[bot], and his bio places him at Cognition, which makes Devin — so the artifact carries a commercial interest of its own.
Third-party and open source (MIT, in the official browser-use GitHub org). One Jev request picks both the browser operation and its target element — “Two decisions, one network round trip” — using speculative target heads, so that “if the operation is `CLICK`, only `click_target` can execute”, over the set CLICK, TYPE_TEXT, SELECT, SCROLL_UP, SCROLL_DOWN, WAIT, DONE, BLOCKED. In-repo measurement on a Zürich→London Google Flights search: 7,073 ms, task time down from 9.450 s to 7.092 s (a 25% reduction), and browser protocol calls down from 1,092 to 101. The closest thing to a public, runnable demonstration that a System One model can sit in the outer loop of an agent.
In-repo numbers with no independent reproduction, and Jev does not drive the loop alone — the README states “a small LLM writes text only when the operation is `TYPE_TEXT`”, so there is a generative model inside the loop. The launch announcement circulating as “~7s, $0.0039” from the browser-use founder could not be verified (x.com returned HTTP 402 to every fetch), and the repo itself carries no date and no individual author line.
Third-party but self-reported, by a call-centre operator who introduces himself as “a non-developer”. On 2026-09-17 he reported sorting 20,000 emails, Slack messages and transcripts into “upsells, complaints, missed follow ups and 5 other things” — eight buckets, five of them never named — in 7 minutes for $1.45. His framing of where the model sits is worth recording alongside the numbers: “Claude or GPT does the thinking and works out what questions are worth asking. Jev answers those questions across everything you’ve got”, and because Jev “charges on input tokens - output is free”, “adding questions doesn’t change the price much”.
The weakest datapoint on this list and not a benchmark: no methodology, question count, token count, label set, dataset, code, or accuracy check is published, and none of the three numbers has independent confirmation — he is candid that he has never been able to check his own labelling scheme properly. Kept because it is a real non-vendor run at a volume no vendor example reaches, and because it is where restatement can be caught: the 2026-09-21 Nate B Jones video gives the cost as “$1” while calling its figures exact, which is about 31% below the $1.45 in the source, and adds a “20,000 plus” the post does not say. Do not read github.com/bitnovus/jev-spam-eval (19,528 emails, four questions each, ~$1.12) as corroboration — different author, public spam corpus, different task.
| Issue | What the sources say |
|---|---|
| The benchmark ground truth | TypeSafe’s accuracy evaluations score agreement with the average of GPT-6 Astra and Claude Fable 5.1 rather than against an independent oracle. The vendor discloses this itself in the launch post, under a "Nuance" heading, saying it "biases answers towards OpenAI and Anthropic’s models". Forkast restated it in coverage. Credit for the disclosure belongs to TypeSafe; the point still stands that the headline accuracy numbers are not measured against ground truth. |
| The cost multiple | Three figures circulate for what sounds like one comparison, and they measure different things: TypeSafe’s homepage gives 238× as an input list-price ratio against Fable 5.1, its headline gives 444.6× as a whole-workflow cost ratio from its own evaluations, and Every independently measured ~580× on one real task. Every’s figure exceeding the vendor’s own stated ceiling is the clearest sign these are not the same measurement rather than evidence that Jev beats its marketing. |
| The speed comparison basis | The 70ms-versus-329s comparison sets a single Jev request against an LLM performing full chain-of-thought reasoning — not an equivalent unit of work. TypeSafe’s own framing is that the comparison is workflow-level rather than call-level, which is the honest reading; the headline does not carry that qualifier. |
| The $40M seed round | Every trail leads back to a Business Wire press release dated 2026-09-15. Funding databases that ingest press releases are weak corroboration, not independent confirmation, and they disagree: Dealroom’s structured record shows $25.9M while its own text says $40M. The round date is variously given as Sep 15, 16 and 17. |
| "Co-invented RLHF" | Not supported. Diogo Almeida is verified as the 4th author of InstructGPT (arXiv:2203.02155), which applied RLHF, but is not an author of the foundational RLHF paper (Christiano et al., arXiv:1706.03741). "Co-authored InstructGPT" is the defensible claim. |
| The Vercel AI Gateway adoption claim | Vercel — the operator of the gateway, publishing its own unaudited platform data — wrote on 2026-09-18 that “Within 24 hours of launching on AI Gateway, Jev from TypeSafe AI reached more than twice as many paid teams as any previous model launch”, with “nearly 13% of paid teams” using it by hour 24, “2x the GPT-5.6 family and more than 6x Fable 5.1’s share”, and “Every other recent model launch remained below 7% after a full day”. Recorded here rather than under claims.independent because it is not a measurement of the model: the metric is share of Vercel’s own paid teams, “paid teams” is never defined, trial is not separated from sustained use, no token-volume or traffic-share figure is given, and Vercel never says the data is audited or externally verified. Four scope problems then ride on top of it. Vercel’s post disagrees with itself — title and body say “any previous model launch” / “in gateway history”, while its own caveat and its blog index say “any other recent model launch”. Its forward-looking caveat, “the next test is whether that early adoption lasts”, is dropped in restatement, including by the 2026-09-21 Nate B Jones video, which escalates the comparison set from launches on Vercel’s gateway to “faster than any LLM from any lab”; nothing resembling “any lab” appears in the source. “Reached” becomes “adopted and paid for that product” downstream, a purchase implication the source does not support and an odd one given input at $0.042/Mtok and free output. And the window is misdated: the video ties it to TypeSafe’s 2026-09-15 ship date, but Vercel measures from availability on AI Gateway, which its own changelog dates to 2026-09-16, so the measured 24 hours is most likely 09-16 to 09-17 — Vercel prints no calendar boundaries. Useful corroboration in the same post, though: Vercel attributes the performance headline to the vendor, “In its own workflow evaluations, TypeSafe AI reports that Jev was up to 194 times faster and 445 times cheaper than language models”, which rounds the 193.6× / 444.6× recorded above. |
| How the launch figures survive restatement | A dated, checkable instance of the divergence already noted against the 40×–200× claim above. The 2026-09-21 Nate B Jones video attributes to TypeSafe’s launch evaluation gains “approaching two orders of magnitude or 100x faster on speed” and “more than two orders of magnitude or more than 100x cheaper”. The launch post reports 193.6× faster and 444.6× cheaper. So the speed figure is understated by roughly half and pointed the wrong way — 193.6× has passed 100×, not neared it — while the cost figure is turned into a floor at about 22% of the published number. Neither “100x” nor “approaching” appears anywhere in the launch post, which applies “two orders of magnitude” flatly and symmetrically to both axes (“two orders of magnitude faster and more efficient”); the approaching-versus-more-than asymmetry is the commentator’s own. Two further substitutions: the vendor’s “more efficient” becomes “cheaper in cost”, and the baseline is described as “an LLM” when TypeSafe discloses that “The LLMs use our System One LLM wrapper, which constrains LLMs to output structured decisions” — i.e. LLMs already forced into Jev’s output shape. All three limits TypeSafe attaches to these exact figures are dropped, and unquantified personal corroboration is offered in their place. Worth keeping because the direction is consistent: every restatement checked in this pass moved a number toward the speaker’s argument, and in this case that meant understating the vendor’s own marketing. |
| The homepage demo does not reproduce the homepage headline | Surfaced while checking the launch figures, and a fourth cost figure for the set already listed under “The cost multiple”. The typesafe.ai side-by-side demo shows Jev at $0.000081 and 0.114 s against LLMs at $0.013880 and 8.566 s, which computes to 171.4× cheaper and 75.1× faster — matching neither the 444.6× nor the 193.6× printed on the same page. The footnote is internally consistent, since it sources the headline to the separate launch-post evaluation rather than to that demo run, so this is not a contradiction so much as one more number circulating under a single banner: 238× input list price, 444.6× workflow cost, Every’s measured ~580×, and now 171.4× from the vendor’s own demo. Note the irony that its 75.1× is the one speed figure genuinely “approaching 100×”, and it is not the one restatements cite. |
| The immunology top-100 anecdote | Circulating through the 2026-09-21 Nate B Jones video only: a bioscientist is said to have asked Jev to select “the top 100 most important immunology questions” from 10,000 literature-grounded candidates, and to have judged that it reliably returned “what he views as about the right top 100”, quickly and cheaply. No primary source has been located. The originating post is presumed to be on X, where every fetch returned HTTP 402 and the xcancel mirror returned HTTP 451, and five curated Jev use-case collections that were fetched contain no immunology or research-prioritisation entry at all. Logged as unverified in both directions rather than as evidence: the success criterion is the researcher’s own satisfaction rather than any measurement, so “it worked reliably” is unfalsifiable as stated; “quickly and cheaply” carries no numbers, and the numbers from the two adjacent examples in the same passage belong to different people and different tasks; how the 10,000 candidates were generated is undisclosed, and “literature grounded” appears to be the commentator’s gloss; and the primitive is undisclosed, which matters because picking 100 of 10,000 is a ranking task rather than the single Choice the video spends its first seventeen minutes describing. The researcher is named only in auto-captions whose spelling could not be matched to any source, so no name is recorded here — the same passage renders two other attributions wrong and the model itself as “Jeb”, “Jeff” and “Jev”. |
Jev is absent from the router's PROVIDERS map and from every fallback chain. That map is the set of OpenAI-compatible chat backends the gateway forwards completions to, and Jev has no chat endpoint at all. Listing it would put a model in the chain that can never answer a completion.
The key is read from the X-Typesafe-Key header per request, exactly like the other provider keys — held in memory for the call, never persisted or logged. Set it in Settings, or give the server a TYPESAFE_API_KEY.
| Kind | Source | Used for |
|---|---|---|
| vendor | TypeSafe HTTP API reference ↗ | The full request/response contract implemented in router/jev.mjs. |
| vendor | TypeSafe models & limits ↗ | Pricing, rate limits, context budget, aliases. |
| vendor | TypeSafe primitives ↗ | Choice/Score/Noul semantics and question-design rules. |
| vendor | TypeSafe confidence ↗ | The confidence formula and the three-band gating pattern. |
| vendor | Jev 1.13 jaggedness ↗ | The published failure modes, reproduced above. |
| independent | Every — Mini-Vibe Check (Mike Taylor) ↗ | The only third-party measurement of speed, cost and accuracy found. |
| journalism | The Register — TypeSafe AI debuts model for machines ↗ | Launch coverage and the 238× cost figure. Ran no testing of its own. |
| journalism | Forkast — Jev is not an LLM ↗ | The benchmark-methodology critique (agreement with frontier models rather than independent ground truth). |
| primary | InstructGPT (Ouyang et al. 2022) ↗ | Confirming Almeida’s authorship. |
| primary | Deep RL from human preferences (Christiano et al. 2017) ↗ | Refuting the "co-invented RLHF" framing — he is not an author. |
| commentary | AI News & Strategy Daily | Nate B Jones (YouTube) — “Why Developers Are Losing Their Minds Over AI That Can't Write”, 2026-09-21 ↗ | Third-party commentary, not evidence. It is the pointer that led to the four developer self-reports and the Vercel adoption post recorded below, and — once its figures were checked against those primaries — a dated worked example of how Jev’s numbers drift in restatement; the drift itself is recorded in claims.disputed rather than the restatements being treated as findings. |
| operator | Vercel — “Jev is the fastest-adopted model in AI Gateway history” (2026-09-18) ↗ | The AI Gateway first-day adoption figures quoted in claims.disputed. Also the clearest non-TypeSafe attribution of the performance headline: Vercel labels it “In its own workflow evaluations, TypeSafe AI reports” and rounds it to 194× / 445×. |
| vendor | TypeSafe — “Introducing System One Models & Jev” (launch post) ↗ | The 193.6× / 444.6× headline and the three limits TypeSafe self-discloses against those exact figures, the Evidence section’s latency basis, and the benchmark-ground-truth admission. Cited as “the launch post” in claims.* since 2026-09-20 but missing from this list until now. |
Catalog last verified 2026-09-21. Jev launched 2026-09-15 and is waitlist-gated, which structurally limits independent verification. Nothing here is inferred: where only the vendor has said it, it sits under claims.vendor and is labelled as such in the UI.