Skip to content

Anatomy of Jev

Builder Founder Expert

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.

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.

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.

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 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_urgent tells Jev nothing; the instructions do the work.
TypeAnswersLimitsReturns
ChoiceWhich one of these named options?Up to 255 options; “adding options costs a few tokens each”choice, probabilities per option, confidence
ScoreWhere on this ordered scale?2 to 10 levelsscore (the probability-weighted average level), probabilities, confidence, legend
NoulIs this statement true?Optional criteria.true and criteria.falsenoul, the probability of “yes”; no confidence
Box (preview)Where in this image?Jev 1.14 only, behind the header TypeSafe-Danger-Zone-Images: truebox 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 shortened
from 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):

QuestionAnswerProbabilitiesConfidence
department (Choice)technicaltechnical 1.0, billing 0.0, sales 0.01.0
frustration (Score)score 0.67level 0: 0.33, level 1: 0.67, level 2: 0.00.5
is_urgent (Noul)noul 0.99one 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), where p_max is 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), where m is the most likely level and MAD_unif is 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_max 0.55 gives (0.55 − 0.1) / 0.9 = 0.5. A 2-option Choice reaches the same 0.5 only at p_max 0.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 hand
import 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.4
print(round(choice_confidence([0.55] + [0.05] * 9), 2)) # 0.5
print(round(score_confidence([0.0, 0.5, 0.5]), 2)) # 0.25
print(round(score_confidence([0.33, 0.67, 0.0]), 2)) # 0.5, as in docs

Why 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 comment
if 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).

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.

ItemValue
Context per request64k tokens (state plus all questions)
Context per question32k tokens (state plus one question)
Long context262k for both with the header TypeSafe-Danger-Zone-Long-Context: true; “slower and less accurate”
Request body32 MiB, 64 nesting levels, finite numbers only
LanguagesEnglish best; other languages and CJK “lower accuracy”
Price$0.042 per million input tokens; output free
Model IDsjev-1.13.0, jev-1.14.0; jev-latest and jev-preview both point at 1.14.0
CustomisationNone 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 comment
result = 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)))

ECE (expected calibration error) below is the average gap between stated confidence and actual accuracy, so lower is better; calibration defines it properly.

ClaimWho says itWhat independent tests found
70 to 500 ms end to endTypeSafe, 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 homepageTrue only against the slowest and priciest comparators (next section)
67.8% accuracy on four workflowsTypeSafe’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 probabilitiesTypeSafeTypeSafe 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 answerNot a headline claimVals: 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.

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.

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.”

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.

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.

ApproachTrain per task?Returns probabilities?Many questions on one state?Output cost
Jev and its rivalsNoYes, nativelyYes, in parallelFree
Reading an LLM’s token probabilities yourselfNoYesYes, with prefix cachingSmall
JSON-mode structured outputsNoNo, one sampled answerWritten out in sequencePaid
Small zero-shot encoders (GLiClass)NoYesPartlyNone
A classic trained classifierYesYesOne model per taskNone

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).

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.