Anatomy of Jev
The idea in one line: Jev is a hosted model that reads some material (the state) plus typed questions you define, and returns a probability for every allowed answer to every question, without writing a single word.
Why this matters
Section titled “Why this matters”Most of the speed and price gains in this course come from one design choice: never generate. A chat model writes its answer one token at a time, and each token waits for the one before. Jev reads your input once and reads off a number for each answer you allowed. When TypeSafe asked 13 questions about one 54,000-character article in a single call instead of 13 calls, it was 12.2x cheaper and 10x faster, with the same answers (TypeSafe cookbook: parallel questions, jev-1.12, read 2026-10-28). That is the 10x lens for this lesson: one expensive read of the context, many nearly free questions.
The second reason is the contract itself. Within weeks, OpenAI, Microsoft, Vercel’s AI SDK and dozens of open projects copied its shape: state and typed questions in, distributions out. Learn it and you know the whole category.
What Jev is, in plain words
Section titled “What Jev is, in plain words”Picture a panel of experts. You hand them a briefing pack and a ballot with tick boxes: “Which team should handle this: billing, technical or sales?” Each expert ticks one box and you count the ticks. If 9 of 10 tick “technical”, you have a decision and a sense of how sure the panel is.
Jev does the arithmetic version. As far as outsiders can tell, the model reads the state and the question in one pass, produces a score for each option you listed, and turns those scores into probabilities that add up to 1. You met both halves in Part 1: a probability distribution (a list of probabilities over every possible answer that sums to 1; see probability is the product) and scoring known options in one forward pass instead of the token-by-token loop (see generating vs deciding).
TypeSafe AI calls this class System One models, after Daniel Kahneman’s fast, intuitive “System 1” thinking (TypeSafe docs: System One, read 2026-10-28). The CEO’s own description: “a structured data model, but technically not a language model (it doesn’t generate language)” (HN launch thread, 2026-09-15).
The dates to know: early access opened on 2026-09-15 with jev-1.13.0 and a $40M seed led by DCVC (launch post); an $870M Series A at a $7.5B valuation, led by Andreessen Horowitz with Sequoia and DCVC, followed on 2026-10-09 (TypeSafe: Series A); and jev-1.14.0 arrived on 2026-10-14, with images and a Box question behind opt-in headers (TypeSafe: Jev 1.14).
The CEO, Diogo Almeida, is 4th of 20 authors on the InstructGPT paper (arXiv 2203.02155). TypeSafe’s docs say he “co-invented” RLHF (reinforcement learning from human feedback, which trains a model toward answers people prefer), but he is not an author of the 2017 paper that introduced it (arXiv 1706.03741); “co-author of InstructGPT’s RLHF recipe” is accurate.
The contract: state, questions, answers
Section titled “The contract: state, questions, answers”State is “the content you ask a System One model to evaluate”: a string, a JSON object or a JSON array. TypeSafe advises an object with named fields, and to “think of state as the material you would present to a panel of experts before asking them to make a judgment” (TypeSafe docs: State, read 2026-10-28).
Questions
Section titled “Questions”Questions are a map from your own IDs to typed questions. Each has a type, instructions, and criteria (required for Choice and Score, optional for Noul). Two rules shape everything else:
- Independence. “Every question in a request sees the same state, is evaluated independently … One question’s answer is not hidden context for another.” There is no cap on the number of questions, only on tokens (TypeSafe docs: Primitives, read 2026-10-28).
- The model never sees your question ID (TypeSafe docs: Choice). Naming a question
is_urgenttells Jev nothing; the instructions do the work.
The four question types
Section titled “The four question types”| Type | Answers | Limits | Returns |
|---|---|---|---|
| Choice | Which one of these named options? | Up to 255 options; “adding options costs a few tokens each” | choice, probabilities per option, confidence |
| Score | Where on this ordered scale? | 2 to 10 levels | score (the probability-weighted average level), probabilities, confidence, legend |
| Noul | Is this statement true? | Optional criteria.true and criteria.false | noul, the probability of “yes”; no confidence |
| Box (preview) | Where in this image? | Jev 1.14 only, behind the header TypeSafe-Danger-Zone-Images: true | box with top, bottom, left and right as fractions, plus confidence |
Sources: TypeSafe docs for Choice, Score, Noul and Box, all read 2026-10-28. “Noul” is short for Bernoulli, the name for a yes/no random outcome. The CEO maps the types onto code you already write: “choice maps to ‘match’ statement, ‘score’ maps to sorting, ‘noul’ … maps to if-statements” (HN comment, 2026-09-15). TypeSafe says images and Box are “not yet up to our standards to call ready for production”.
Two documented details hint at how the model reads questions. Score levels are judged one at a time: “The model doesn’t see a level’s number or its neighbours”, so write each level to stand alone. Choice options are seen together, so write descriptions that “separate the options from each other”; the model also “leans toward the option that comes first” in some cases (Jev 1.13 jaggedness, reviewed 2026-10-02).
A worked example: one ticket, three questions
Section titled “A worked example: one ticket, three questions”Here is TypeSafe’s quickstart in Python, with the ticket text shortened. One call asks a Choice, a Score and a Noul about the same ticket.
# Adapted from TypeSafe's quickstart (docs.typesafe.ai); ticket shortenedfrom typesafe_sdk import Choice, Noul, Score, TypeSafeClient
ticket = "Our API has returned 500 errors on every request for 20 minutes."
with TypeSafeClient(model="jev-latest") as client: # reads TYPESAFE_API_KEY r = client.system_one( state=ticket, questions={ "department": Choice( instructions="Which team should handle this", criteria={"billing": "Payment or subscription issues", "technical": "Bugs or integration problems", "sales": "Pricing or account questions"}), "frustration": Score( instructions="How frustrated the customer appears", criteria=["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]), "is_urgent": Noul( instructions="The message conveys urgency or time-sensitivity"), }, )print(r.choices["department"].choice, r.scores["frustration"].score, r.nouls["is_urgent"].noul)The raw response the docs show for the full ticket (jev-1.13.0, 428 input tokens), laid out as a table (TypeSafe docs: Quick start, read 2026-10-28):
| Question | Answer | Probabilities | Confidence |
|---|---|---|---|
department (Choice) | technical | technical 1.0, billing 0.0, sales 0.0 | 1.0 |
frustration (Score) | score 0.67 | level 0: 0.33, level 1: 0.67, level 2: 0.0 | 0.5 |
is_urgent (Noul) | noul 0.99 | one number, P(yes) | none |
Check the Score by hand. The expected level is each level times its probability, added up: 0 × 0.33 + 1 × 0.67 + 2 × 0.0 = 0.67. So score is not a level. It is an average that can land between levels: “frustrated but civil”, leaning a little toward calm.
The same response reports 73 output_tokens, even though output is not billed. Keep that clue for the next lesson: something is read out per question, just not written token by token.
The TypeScript SDK goes one step further: “The SDK infers answer types from your questions, so response.answers.department.choice has the type "billing" | "technical" | "sales"”. A misspelled option becomes a compile error instead of a production bug.
Confidence is not the probability of being right
Section titled “Confidence is not the probability of being right”This is the most misunderstood field in the API.
Confidence in Jev is a fixed, published formula applied to the distribution it just returned. It is not a second model output, and it is not “the chance this answer is correct”. It measures how concentrated the distribution is: 1 when all probability sits on one answer, 0 when it is spread evenly (TypeSafe docs: Confidence, read 2026-10-28).
The formulas:
- Choice with n options:
confidence = (p_max − 1/n) / (1 − 1/n), wherep_maxis the top probability. In words: how far the top answer sits above a blind guess, as a share of the way to certainty. - Noul: none is returned. If you want one, use
|2p − 1|. - Score:
max(0, 1 − Σ p_i·|i − m| / MAD_unif), wheremis the most likely level andMAD_unifis the same average distance for an even spread. Probability on a neighbouring level costs less than probability on a far level.
Small numbers you can check by hand:
- A 3-option Choice at (0.6, 0.3, 0.1) gives (0.6 − 0.333) / (1 − 0.333) = 0.267 / 0.667 = 0.4. The spread (0.6, 0.2, 0.2) also gives 0.4, because only the top probability counts.
- A 10-option Choice with
p_max0.55 gives (0.55 − 0.1) / 0.9 = 0.5. A 2-option Choice reaches the same 0.5 only atp_max0.75. Same confidence, very different top probability. - A 3-level Score at (0, 0.5, 0.5) gives 0.25; at (0.5, 0, 0.5) it gives 0. Splitting between neighbours means “fairly sure it is high”. Splitting between the two ends means “no idea”.
# Jev's published confidence formulas, re-implemented to check by handimport numpy as np
def choice_confidence(p): p, n = np.asarray(p, float), len(p) return (p.max() - 1 / n) / (1 - 1 / n)
def score_confidence(p): p = np.asarray(p, float) levels = np.arange(len(p)) m = p.argmax() # most likely level mad = (p * abs(levels - m)).sum() # weighted distance to m mad_unif = abs(levels - m).mean() # same, for an even spread return max(0.0, 1 - mad / mad_unif)
print(round(choice_confidence([0.6, 0.3, 0.1]), 2)) # 0.4print(round(choice_confidence([0.55] + [0.05] * 9), 2)) # 0.5print(round(score_confidence([0.0, 0.5, 0.5]), 2)) # 0.25print(round(score_confidence([0.33, 0.67, 0.0]), 2)) # 0.5, as in docsWhy this matters: confidence is a handy single dial to threshold on, but it only means something if the probabilities underneath are calibrated, meaning that across many answers given 0.8, about 80% turn out right. TypeSafe itself says calibration is a property of groups: “it does not guarantee that an individual answer is correct” (TypeSafe docs: System One). Whether Jev is calibrated on your data is something you measure; calibration shows how.
TypeSafe’s design rule is to use confidence as “a second axis. The answer tells you what; confidence tells you whether to act” (TypeSafe docs: Patterns, read 2026-10-28). Its docs show this gate:
# From TypeSafe's Confidence docs, verbatim apart from this commentif confidence < 0.5: # Model is genuinely unsure. Don't guess. route_to_human(user_message)
elif action.choice == "check_balance": # Low stakes. Showing the wrong screen is recoverable. show_balance(account_id)
elif action.choice == "approve_transfer": if confidence > 0.9: # High stakes, high confidence. Proceed with confirmation. confirm_then_execute(account_id) else: # High stakes, moderate confidence. Verify first. ask_user_to_confirm(account_id)Notice that the bar rises with the stakes; from probability to automation turns that into arithmetic. TypeSafe’s starting Noul thresholds are 0.7 for yes and 0.3 for no, and it says thresholds “depend on your domain” (TypeSafe docs: Noul).
Where Jev sits in an app
Section titled “Where Jev sits in an app”C4 · L1 System context · A support desk that uses Jev
+---------------------+| [Person] || Customer || needs help, fast |+---------------------+ | | sends a ticket v+---------------------+ state + typed +-------------------+| [Software system] | questions | [External system] || Support desk app |----------------->| Jev API || routes, ranks, acts |<-----------------| by TypeSafe AI |+---------------------+ distributions +-------------------+ | | | hands over | asks for a | unsure | drafted reply | tickets | when text v v is needed+-----------+ +--------------------+| [Person] | | [External system] || Support | | Frontier LLM API || agent | | writes reply text |+-----------+ +--------------------+The app in focus is yours. It sends each ticket’s state and typed questions to Jev, gets distributions back, acts on the confident ones, hands the unsure ones to a person, and calls a text-writing LLM only when it needs prose. New to these boxes? See how to read the diagrams.
People run Jev on routing and triage, agent gates (“continue, retry, ask the user, or stop”), moderation, and re-ranking: TypeSafe’s cookbook re-ranked a keyword-search shortlist on 40 legal queries and lifted top-1 accuracy from 5% to 18% (TypeSafe docs: Patterns; Vercel blog, 2026-09-18; cookbook: re-ranking). TypeSafe’s rules of thumb: keep each question atomic, ask “speculative” questions because they are nearly free, and combine answers with weights in code.
Limits and price, as of October 2026
Section titled “Limits and price, as of October 2026”| Item | Value |
|---|---|
| Context per request | 64k tokens (state plus all questions) |
| Context per question | 32k tokens (state plus one question) |
| Long context | 262k for both with the header TypeSafe-Danger-Zone-Long-Context: true; “slower and less accurate” |
| Request body | 32 MiB, 64 nesting levels, finite numbers only |
| Languages | English best; other languages and CJK “lower accuracy” |
| Price | $0.042 per million input tokens; output free |
| Model IDs | jev-1.13.0, jev-1.14.0; jev-latest and jev-preview both point at 1.14.0 |
| Customisation | None per customer: “the same weights serve every account” |
Sources: TypeSafe docs: Models and Request rules, read 2026-10-28. Secondary sources often quote a “32,000-token” context; that is the per-question limit.
In practice, JevBench measured about 950 input tokens per decision, so 1,000 decisions cost $0.0399 (JevBench README, v1.6.1, 2026-10-06), and the community Decision Index ran 110,201 requests for $12.26 in total (Decision Index, edition 0.4.1). TypeSafe itself warns the pricing may be subsidised and its sustainability is unproven (launch post).
Why output is free, in the CEO’s words: “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)” (HN comment, 2026-09-15).
Pin a version if you tuned thresholds: “its answers can change without any change to your code”. Deprecation windows are 60 days for 1.13.0 and 30 for 1.14.0 (Jev 1.14).
What Jev is bad at, in TypeSafe’s own words
Section titled “What Jev is bad at, in TypeSafe’s own words”TypeSafe publishes a “jaggedness” page of known failure modes for 1.13 (reviewed 2026-10-02): literal reading; maths and counting; numbers in odd forms such as hex colours; reading magnitudes off Score averages; comparing dates and times; double negatives; large state full of irrelevant detail (“Jev suffers from context rot”); adversarial content; contradictory instructions; option-order bias; and generation. The cure is always the same: extract with the model, compute with code. Its counting workaround asks one Noul per item and adds them up in Python:
# From TypeSafe's Jev 1.13 jaggedness page, verbatim apart from this commentresult = client.system_one( {"items": items}, { f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?") for i in range(len(items)) },)
count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))What is known versus claimed
Section titled “What is known versus claimed”ECE (expected calibration error) below is the average gap between stated confidence and actual accuracy, so lower is better; calibration defines it properly.
| Claim | Who says it | What independent tests found |
|---|---|---|
| 70 to 500 ms end to end | TypeSafe, measured “from a laptop on the West Coast” | Vals AI: 0.10 s for 1 judgment, 0.12 s for 64 on one document. Decision Index: median 196 ms, p95 297 ms. JevBench from a server in Germany: p50 0.65 s |
| “193.6x faster, 444.6x cheaper” | TypeSafe homepage | True only against the slowest and priciest comparators (next section) |
| 67.8% accuracy on four workflows | TypeSafe’s own evals | “Accuracy” there means agreement with two frontier models, not ground truth. Vals: 97.5% on 400 claim checks against 10-K filings, within noise of frontier models, but last of 12 on a LegalBench slice at 73.0% |
| Calibrated probabilities | TypeSafe | TypeSafe publishes no ECE and no reliability chart. Independent ECE runs from 0.011 to 0.245 depending on the task |
| “Can’t hallucinate” | TypeSafe, which admits the 0% figure is “not empirical” | It cannot return an invalid type, but “it can still emit a completely wrong valid value” |
| Same input, same answer | Not a headline claim | Vals: identical answers across 5 repeats of 25 items |
Sources: Vals AI, 2026-10-06; Decision Index (data generated 2026-10-28); JevBench results; TypeSafe evals (read 2026-10-28); launch post; HN comment 49718492.
Across all tests, Jev is reliably fast and cheap, with the accuracy of a good mid-tier model: strong on common sense and bounded checks, weak on legal entailment and hard multi-step items.
The headline multiples versus the fair comparison
Section titled “The headline multiples versus the fair comparison”The “193.6x faster, 444.6x cheaper” headline comes from TypeSafe’s own workflow table, and TypeSafe itself calls those multiples “likely on the higher end of real world gains”. Redo the arithmetic on that table and you find:
- Speed is measured against Sonnet 5 at 78.1 s per case versus Jev’s 0.4 s: about 195x.
- Cost is measured against Opus 5 at $0.1761 per case versus Jev’s $0.0004: about 440x.
Each multiple picks a different worst-case rival. The fair question: how much better than the cheapest model of equal accuracy? In the same table, GPT-6 Luna scores 66.8% against Jev’s 67.8% and costs $0.0033 and 12.9 s per case. That makes Jev about 8x cheaper and 32x faster (0.0033 / 0.0004 ≈ 8; 12.9 / 0.4 ≈ 32). Still a big win, and the number to put in a business case. Against GPT “sol”, which is six points more accurate (74.1%), the gap is 209x on cost and 58x on time (arithmetic on TypeSafe’s own table, read 2026-10-28).
Other views of the same question:
- Vals measured 194x faster than GPT-6 Astra at 32 judgments per document, but 4x to 74x on single judgments under load; GPT-6 Luna matched Jev’s claim-checking accuracy at about 4x the price (Vals AI).
- One source, a scan of 12,759 launch tweets, found a median user-reported speed-up of 7x and cost saving of 30x (InfoQ, 2026-10-01).
- Asking LLMs for probabilities raised their bill by 29% to 101% in Vals’s test; Jev’s distribution comes free.
“No hallucinations”, read carefully
Section titled ““No hallucinations”, read carefully”TypeSafe claims Jev “can’t hallucinate” and type errors are “mathematically impossible”. Armin Ronacher: “it delegates the hallucination problem a little bit to the user” (TechCrunch, 2026-09-18). The CEO: “Would you say a linear classifier hallucinates?” The honest framing: Jev removes format errors and made-up values, not wrong decisions.
Security
Section titled “Security”HiddenLayer reported a browser agent using Jev hijacked by an attacker’s ad, and odd characters inserted into words (a “TokenBreak”-style attack) lowering toxicity scores, with no success rates published (InfoWorld, 2026-10-15). TypeSafe’s docs concede: “State is data, and jev-1.13 does not treat it as hostile by default.”
The architecture is a black box
Section titled “The architecture is a black box”TypeSafe has said only “a new model architecture”, a “parallel sampler”, and a training method called RLCD (“Reinforcement Learning for Calibrated Decisions”), trained “exclusively on synthetic data” (TechCrunch), and that 1.13 “was multimodal all along”. No parameter count, data size or paper. Outside observers suspect a fine-tuned open-weight model underneath; unconfirmed. The next lesson shows the published techniques that explain everything Jev does in public.
Rivals arrived within weeks
Section titled “Rivals arrived within weeks”The contract proved easy to copy. OpenAI’s Decisions API entered public beta on 2026-10-06 on GPT-6 Luna at $0.10 per million input tokens, output free. Microsoft-Decision-1, built on the open Qwen3.5-9B, was announced on 2026-10-09 at Jev’s own $0.042 price (Let’s Data Science, 2026-10-09; The Register, 2026-10-10). Perplexity, Cloudflare, H2O, Liquid AI and AWS followed, and Vercel’s AI SDK added a provider-neutral experimental_decide (AI SDK docs).
On the community Decision Index, as of October 2026, 47 of more than 240 entries outscore Jev 1.14, including a stock Gemma-4-31B with an inference-time scoring trick and no training at all (Decision Index). One source reports that two weeks in, 35% of paid Vercel AI Gateway teams used Jev, yet it was only 0.27% of gateway spend (AI Weekly, 2026-10-17). The interface became a standard; the moat moved to data, calibration evidence and distribution. More in the market map.
Where it fits next to LLMs
Section titled “Where it fits next to LLMs”| Approach | Train per task? | Returns probabilities? | Many questions on one state? | Output cost |
|---|---|---|---|---|
| Jev and its rivals | No | Yes, natively | Yes, in parallel | Free |
| Reading an LLM’s token probabilities yourself | No | Yes | Yes, with prefix caching | Small |
| JSON-mode structured outputs | No | No, one sampled answer | Written out in sequence | Paid |
| Small zero-shot encoders (GLiClass) | No | Yes | Partly | None |
| A classic trained classifier | Yes | Yes | One model per task | None |
The mechanisms behind each row are in the next lesson. The short version: use a decision model when the answers can be listed in advance; use an LLM when you need words, code or long reasoning.
Open problems, as of October 2026: what the architecture and RLCD are; whether calibration holds on a given task (it varies tenfold across tests); whether the price survives without subsidy; and why leaderboards disagree (JevBench v1.3.0 ranks Jev first, the Decision Index about 48th).
Check yourself
Section titled “Check yourself”A 4-option Choice returns (0.70, 0.10, 0.10, 0.10). What is its confidence, and does it mean the answer is 70% likely to be right?
Confidence is (0.70 − 0.25) / (1 − 0.25) = 0.45 / 0.75 = 0.6. It measures how concentrated the distribution is, not the chance of being right. Whether “0.70” really means right 70% of the time depends on calibration, which you have to measure on your own labelled cases.
Why is “444.6x cheaper” the wrong number for a business case?
It compares Jev against the most expensive model in TypeSafe’s table (Opus 5), which is also more accurate. The fair comparison is the cheapest model of equal accuracy: GPT-6 Luna at 66.8% versus Jev’s 67.8%, which makes Jev about 8x cheaper and 32x faster.
You want to know how many of 40 packages in a build log failed. How do you ask Jev?
Not with one Score or Choice asking “how many”: counting is a documented weak spot. Ask one Noul per package (“did this package fail?”) in a single request, then count the answers above your threshold in code. Extract with the model, compute with code.
TypeSafe says Jev “can’t hallucinate”. What does that actually guarantee?
Only that every answer is one of the options you defined, with no format errors and no invented values. It does not guarantee the chosen option is right. A confident wrong answer is still possible, which is why you threshold on calibrated probabilities and route unsure cases.
Go deeper
Section titled “Go deeper”- TypeSafe docs: Primitives and Confidence — the contract and the exact confidence formulas, from the source.
- Vals AI: An Independent Evaluation of TypeSafe’s Jev (2026-10-06) — the most careful third-party test of speed, accuracy and calibration.
- Victor Dibia: How Jev works (2026-09-28) — a $4 rebuild of the scoring trick with calibration numbers.
- TypeSafe workflow evals — read the table yourself and redo the multiples.
- Jev 1.13 jaggedness — the vendor’s own list of failure modes, rare and useful.
- Jev Decision Index — 240+ decision models on one leaderboard, with ECE per task.