What Is Jev? TypeSafe's System One Model Explained
On 15 September 2026 a San Francisco lab left two years of stealth with $40M and a frontier model that cannot write a sentence. Jev does not generate strings. It reads your program state, answers typed questions about it with calibrated probabilities, and returns in about a tenth of a second for a fraction of a cent. Here is what a "System One model" actually is, how to call it, the five patterns that work, where it falls over, and which of the launch numbers survive outside scrutiny.
Jev, in sixty seconds
TypeSafe AI · early access since 15 September 2026
~100ms
Typical response
70–500ms end to end, vendor-measured
$0.042
Per million input tokens
Output tokens billed at zero
0%
Schema error rate
Structural, not an accuracy claim
64k
Token budget
State plus every question, combined
What it is
- A typed, probabilistic function you call from code — closer to a smart
ifstatement than to a chatbot. - Three answer shapes: Choice (one of N), Score (position on a scale), Noul (probability a statement is true).
- Every answer arrives with a confidence trained to mean something — 90% confidence should be right about 90% of the time.
- Non-autoregressive: all the answers are sampled in one parallel pass, which is where the latency goes.
What it is not
- Not a cheaper LLM. It writes no text, no code, no summaries, and gives no rationale for its answers.
- Not multimodal. Text in only — strings, JSON objects or arrays of text. No images, audio or video.
- Not a reasoning model. Multi-hop logic, arithmetic and date comparisons are documented weaknesses.
- Not generally available. Early access, waitlist, weights unpublished, architecture undisclosed.
Why anyone would build a model that refuses to write
Open any production AI system built since 2023 and count the model calls. A minority of them generate something a person reads. The majority decide something: is this ticket about billing, is this comment abusive, is this invoice safe to pay, is this retrieved passage relevant, should this tool call be allowed to run. Each of those is a bounded question with a small, known set of valid answers.
And each of them is currently served by asking a chat model to write a sentence, then parsing the sentence back into a value. You pay for a generative decoder, wait for it to emit tokens one at a time, and then throw almost all of that machinery away to keep one word. TypeSafe's thesis, in their own framing, is that a lot of what people ask LLMs to do is structured decision-making dressed up as chat.
The latency tax
Autoregressive decoding is sequential by construction. Even a short JSON answer costs a round of forward passes per token, and a reasoning model adds a thinking budget on top. Decisions that gate a UI cannot afford it.
The parsing tax
Constrained decoding and JSON mode narrowed this, but did not close it. TypeSafe measured structured-output error rates from 0.58% up to 45.5% across the models in its eval. Every one of those failures needs a retry path.
The confidence tax
Ask an LLM how sure it is and it writes a number that means very little. Without a trustworthy probability you cannot build the one thing automation needs: a threshold above which nobody has to look.
The Kahneman framing. TypeSafe borrows the name from Thinking, Fast and Slow: System 2 is slow, deliberate reasoning — that is what frontier chat models have been optimised for. System 1 is fast, automatic judgement. Most software does not need a deliberation; it needs a snap call it can act on. The model is named for William Stanley Jevons, the economist of the paradox that efficiency gains increase total consumption — which tells you exactly what TypeSafe expects to happen to decision volume when a decision costs four ten-thousandths of a cent.
How a System One model differs, mechanically
Three changes, and they compound. Fix the output space before inference, and you no longer need to generate it. Stop generating, and you can sample every answer at once. Sample at once, and you can train directly against whether the probabilities were right.
RLCD, and why it is the interesting part
RLHF trains a model to produce answers humans prefer. RLVR trains it against answers that can be checked. TypeSafe's Reinforcement Learning for Calibrated Decisions trains against whether the stated probability was honest: across many predictions, the things the model called 70% likely should happen about 70% of the time.
That is a narrower goal than intelligence, and a more useful one for automation. A well-calibrated 0.93 lets you write a rule — act automatically above this line, ask a human below it — and know roughly what that rule will cost you in mistakes. Nothing about an LLM's self-reported confidence supports that rule today.
Worth holding lightly: calibration is TypeSafe's strongest differentiator and the claim with the least outside evidence behind it. No third party has yet published reliability diagrams on messy production data. If you are going to build thresholds on these probabilities, measure the calibration on your own labelled slice before you trust it.
The three primitives
The whole API surface is a state plus a dictionary of questions. Each question is one of three types, and the shape of the answer is decided by which type you pick. TypeSafe's own guidance is to keep each question at the level of a gut check and let your code do the composition — decompose rather than ask one clever question.
Choice
One of N labelled options, up to 255 of them. Returns the selected key, the full probability distribution across options, and a confidence. Beyond 255 options TypeSafe falls back to a two-stage scoring pass, which costs latency.
Use for: routing, intent, category, which-tool-next.
Score
A position on an ordered scale you define with 2 to 10 described levels. Returns a weighted mean, so the answer can land between levels at 1.035, plus the distribution and a confidence.
Use for: severity, relevance, frustration, risk, quality.
Noul
A statement, and the probability from 0 to 1 that it is true. There is no separate confidence field — the value is the belief, so 0.5 means genuinely undecided rather than a weak yes.
Use for: flags, gates, guardrails, presence of a fact.
A complete first call
Install the SDK, export a key, and ask three questions of one support ticket in a single round trip. Note that the state can be a plain string, a JSON object, or an array of messages — you hand it your program state and let the model deal with the shape.
# Python 3.10+
pip install typesafe-sdk
# Node 20+
npm install @typesafe-ai/sdk
export TYPESAFE_API_KEY="sk-..."from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient()
response = client.system_one(
state={
"ticket": {
"subject": "Duplicate charge",
"messages": [
{"from": "customer",
"text": "I was charged twice for order A-104. Please refund the duplicate."},
],
},
"order": {"id": "A-104", "charges": [
{"amount_usd": 49, "status": "captured"},
{"amount_usd": 49, "status": "captured"},
]},
},
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={
"billing": "Payment, invoices 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",
],
),
"refund_requested": Noul(
instructions="The customer is explicitly asking for a refund"
),
},
)
dept = response.answers["department"]
print(dept.choice, dept.confidence) # billing 0.97
print(response.answers["frustration"].score) # 1.035
print(response.answers["refund_requested"].noul) # 0.98
print(response.model) # log the exact version that answeredimport { choice, noul, TypeSafeClient } from "@typesafe-ai/sdk";
const client = new TypeSafeClient();
const response = await client.systemOne({
state: { document: "I was charged twice. Please fix this ASAP." },
questions: {
category: choice("What is this ticket about?", {
billing: "Payment or subscription issues",
technical: "Bugs or integration problems",
other: "Anything else",
}),
urgent: noul("The message conveys urgency"),
},
});
console.log(response.answers.category.choice);If you are already on a framework
Both of the obvious hosts shipped adapters in launch week. The LangChain integration is the more interesting one: alongside a plain classifier it ships an AutoModeMiddleware that runs every proposed tool call past Jev before execution, so a destructive command gets classified and blocked in the ~100ms you can afford to spend inside an agent loop.
from langchain_typesafe import Noul, TypeSafeClassifier
classifier = TypeSafeClassifier()
response = classifier.invoke(
state=proposed_tool_call,
questions={
"destructive": Noul(instructions="This command deletes or overwrites data"),
"reversible": Noul(instructions="The effect of this command can be undone"),
},
)import { experimental_evaluate as evaluate } from 'ai'
import { typeSafeAi } from '@ai-sdk/typesafe-ai'
const result = await evaluate({
model: typeSafeAi.evaluationModel('jev-latest'),
state: { message: userInput },
questions: { /* choice / score / noul */ },
})Pin the version. The default route is jev-latest, which is the wrong choice the moment you tune a confidence threshold — a model update shifts the distribution under your threshold. Pin something like jev-1.13.0, and log the .model field every response returns.
The numbers, and who produced them
Launch week produced some very large multiples. They are worth separating into three piles: what you can check yourself today, what one outside party has now tested, and what remains a vendor slide.
- Published price of $0.042/MTok input, output unmetered.
- Schema conformance — one counterexample would falsify it.
- Per-call latency, if you have an early-access key.
- Rate limits: 250k tokens/sec, 1,200 requests/min.
- The $40M seed and the founders' track records.
- Every ran 777 judgments in under 0.7 seconds for roughly a quarter of a cent.
- Around 25x faster than Claude Fable 5.1 on the same task.
- Caught 6 of 7 planted defects; Fable 5.1 caught 7 of 7.
- Their conclusion: needs a much more thorough accuracy check before production.
- 193.6x faster / 238x cheaper than Fable 5.1 (homepage), and a 444.6x cost figure elsewhere.
- Calibration quality on real, messy data.
- Intelligence parity — and only ever on System One-shaped tasks.
- Any public benchmark result. There are none.
TypeSafe's workflow eval, read carefully
The launch comparison runs four production-shaped workflows — security incident triage, agent trace observability, invoice processing, and customer service — decomposed into narrow Choice/Score/Noul questions. Each point averages one model configuration over all four with equal weight.
GPT-5.6 Terra
Claude Opus 5GPT-5.6 SolThe honest reading of that table is not "Jev wins". It is that Jev lands at roughly GPT-5.6 Terra's agreement level for about 1/76th of the cost and 1/25th of the latency, while the strongest reasoning models remain five to six points more accurate. If those five points matter for your decision, buy them. If they do not, the price difference is close to absurd.
Three caveats TypeSafe flags itself, and they matter more than the multiples:
- The four workflows were designed by TypeSafe's own capabilities team. This is a benchmark the vendor invented.
- There is no ground truth. Reference labels are the average of GPT-6 Astra and Claude Fable 5.1 at high thinking — so "accuracy" is really agreement with two frontier models, which structurally caps Jev at their ceiling and inherits their errors.
- The competing LLMs were run through TypeSafe's own System One adapter rather than their native structured-output paths.
One finding in that eval has nothing to do with Jev and is probably the most portable thing in the whole launch: decomposed workflows beat single prompts on all three axes regardless of model. Sonnet 5 as a workflow hit 67.8% at $0.1174 per case; the same model as a prompt managed 60.4% at $0.2251. You can collect most of that gain this afternoon without changing vendor.
What it costs, in workloads rather than tokens
$42 per billion input tokens with free output is hard to feel. These are the numbers people actually published in launch week, which make the shape of the economics clearer than the rate card does.
$0.08
1,018 research papers classified
1kpapers.com — classification only, summaries billed separately
$0.0039
A flight booked end to end
browser-use/jev-ultrafast, 7.1 seconds
$0.0002
Per computer-use decision
vs ~$0.032 for the same screenshot decision on Opus 5
~$7/hr
A game loop deciding 10x a second
TypeSafe's own real-time demo
The batching effect is the real discount
Because every question is answered in the same parallel pass, the tenth question adds tokens but almost no time. TypeSafe measured 13 questions in one call at 12.2x cheaper and 10x faster than the same 13 asked sequentially, with identical answers. Ask everything you might want, including the questions that turn out to be irrelevant — speculative fan-out is cheaper than being selective.
Where the savings leak back out
Cost per solved task is the number that matters, not cost per token. If 8% of calls fall below your confidence threshold and route to a human, the human is your line item and the model is a rounding error. Model the escalation rate before you model the token bill — that is what decides whether this is a 100x saving or a 3x one.
On sustainability: TypeSafe has said plainly that it cannot prove the pricing is not subsidised, and that it expects prices to fall rather than rise. That is more candid than most launch posts, and it is still a $40M seed-stage company pricing a product at zero on one axis. Do not build a business whose unit economics only work at $0.042/MTok from a company that has been selling for five days.
Five patterns that actually use the shape of the thing
Dropping Jev in as a like-for-like replacement for an LLM classifier gets you the speed and roughly none of the leverage. These are the patterns that only make sense because answers are parallel, typed and probabilistic.
Speculative fan-out
Ask every question you might need in one call, including the ones that only matter conditionally. The bug-severity question is meaningless if the ticket is not a bug — ask it anyway. Branching in code on answers you already have beats a second round trip, every time.
response = client.system_one(
state=ticket,
questions={
"category": Choice(...),
"bug_severity": Score(...), # only meaningful if it is a bug
"has_repro": Noul(...), # asked regardless
"refund_wanted": Noul(...), # asked regardless
"frustration": Score(...),
},
)Confidence-gated routing
Scale the threshold to the cost of being wrong, not to a single global number. Showing a balance is recoverable; moving money is not. This is the pattern the whole calibration story exists to serve.
action = response.answers["intent"]
if action.confidence < 0.5:
route_to_human(user_message) # model is undecided
elif action.choice == "check_balance":
show_balance(account_id) # read-only, low bar
elif action.choice == "approve_transfer":
if action.confidence > 0.85: # moves money, high bar
approve_transfer(account_id)
else:
ask_user_to_confirm("Approve this transfer?")Composite scoring
Never ask "is this a good candidate". Ask three or four atomic questions and put the weights in your code, where they are reviewable, versionable and A/B testable. Re-weighting becomes a pull request rather than a prompt rewrite — and you can explain the decision even though the model cannot.
a = response.answers
composite = (
0.40 * (a["python_depth"].score / 4) +
0.25 * (a["team_leadership"].score / 4) +
0.35 * (a["system_design"].score / 4)
)The cascade
Jev decides which machinery the request deserves. Most requests resolve to a database lookup and never touch a language model at all; the genuinely hard ones get a specialist prompt or a person. This is where the 100ms buys you something structural — the routing decision costs less than the round trip you avoid.
if intent.confidence < 0.5:
route_to_human(message)
elif intent.choice == "order_status":
lookup_order(message) # pure code, no LLM
elif intent.choice == "complaint":
if complexity.score > 1:
route_to_human(message)
else:
handle_with_llm(message, COMPLAINT_SPECIALIST)Retrieve, then judge
Retrieval gets you candidates cheaply; Jev judges each one against bounded criteria for a fraction of a cent. Re-ranking a hundred passages before they reach a generation model is the single cheapest quality win available in a RAG pipeline right now — and it is the workload the 0% schema error rate is built for.
for paper in search_pubmed("GLP-1 outcomes", max_results=20):
verdict = client.system_one(
state={"title": paper.title, "content": paper.content},
questions={
"is_rct": Noul("This is a randomised controlled trial"),
"reports_mace": Noul("Reports major adverse cardiovascular events"),
"evidence_strength": Score(...),
},
)Where it breaks
TypeSafe documents these openly, which is to its credit, and most of them are the direct consequence of the design rather than bugs to be fixed later. Read them as the boundary of the tool.
It is not a calculator
Counting items and comparing quantities are unreliable, and get worse as the set grows. The documented workaround is to iterate in code — generate one Noul per item rather than asking "how many of these are X".
Dates are just text
Which of two dates came first, how far apart they are, whether one falls in a range — all unreliable. Parse and compare dates in your own code and hand Jev the semantic question that is left over.
It reads literally
Negations, scoping words and double negatives land at face value, and multi-hop indirection degrades accuracy noticeably. Write each question as a flat, positive statement. Criteria that quietly contradict the instruction will confuse it.
Context rot is real
Accuracy falls as the state fills with material irrelevant to the question. The 64k budget is a ceiling, not a target — filter first, then ask. You are paying for precision, not for stuffing.
No rationale, ever
You get a value and a probability, never a because. In any regulated flow that owes someone an explanation, Jev can be the fast filter but cannot be the decision of record — escalate the flagged cases to a model that can write one.
Zero hallucinations is about shape
The strongest version of this claim is defensible and narrow: it cannot emit an invalid value or an unparsable response. A wrong choice among three valid ones is still wrong — it just arrives as well-formed JSON, which makes it easier to miss.
The framing problem. Calling Jev a frontier model invites a comparison it was never built to win — it cannot code, chat, or write a sentence, and the accuracy column in its own eval sits below the reasoning models it is charted against. The defensible claim, and the one the evidence supports, is narrower and still significant: TypeSafe has pushed the speed-and-cost frontier for structured decisions a very long way out.
Where this sits in a 2026 stack
The signal from this launch outlives the specific numbers. Production AI stacks are converging on polymodel architectures — a routing layer decides which kind of intelligence each call deserves, and the expensive one is the exception rather than the default. Jev is a new tier in that stack, not a replacement for one that exists.
Deterministic code
Free, exact, auditable. If a regex or a lookup table answers it, nothing here beats that. Jev does not change this line.
System One decisions
Bounded judgement at ~100ms and ~$0.0004. Triage, routing, filtering, guardrails, re-ranking. The layer that used to be an unjustifiable LLM call.
Fast chat models
Haiku-class and mini-class models, for generation that has to be quick and cheap but still has to be words on a page.
Frontier reasoning
Opus 5, Fable 5.1, GPT-6 Astra. Open-ended work, long-horizon agents, anything that has to explain itself. Reached deliberately, not by default.
The cost of that architecture is orchestration. Four tiers means a stable seam in front of your models, so that moving a decision from Tier 1 to Tier 3 is a config change rather than an application rewrite. If you have no such seam today, building one is a better first move than adopting any single new model — and it is what makes the next launch, from whoever ships it, cheap to evaluate.
Should you use it yet?
There is no single answer here, because the constraint you are under decides it. Find yours.
You are making millions of small, bounded calls
Moderation, tagging, triage, relevance filtering, spam gates. This is the case Jev was built for and the one where the arithmetic is not close — a workload costing thousands a month in LLM calls lands in the tens. Join the waitlist and run it in shadow this quarter.
A decision sits in front of a user interface
Anything that has to resolve inside a keystroke, a frame, or a block time. A 100ms budget rules out every frontier model regardless of price, which makes this less a cost decision than a feasibility one. Agent loops calling a guardrail on every tool use are the same shape.
The decision has to be explainable
Lending, hiring, clinical, anything with a regulator or an appeals process. Jev can still be the first pass, but the decision of record needs a rationale it cannot produce. Use it to reduce the volume reaching the model or the person who can write one.
Your volume is modest and your bill is fine
Then wait. At a few thousand classifications a month you are optimising a line item you cannot see, against an early-access product with no public benchmarks, unpublished weights and one outside test. Re-read this in a quarter, when there are three.
You need counting, dates or arithmetic
Use code. This is the boring answer and it is right — these are documented failure modes, not tuning problems, and no prompt fixes them. Jev is for the semantic residue after your code has done the parts that are actually deterministic.
You want the win without the vendor risk
Take the finding underneath the launch instead: decompose your one clever prompt into narrow, independent questions and combine them in code. That beat single prompts on accuracy, cost and latency for every model in the eval. It costs you an afternoon and no new dependency.
How to adopt it without betting anything
Treat it as a new if statement, not a migration. Shadow-run it beside the logic you already have, log every disagreement, label a few hundred of them, and check whether the confidence numbers mean what TypeSafe says they mean on your data. Then automate the lowest-risk path first, with a threshold you derived rather than guessed. Pin the model version before you tune that threshold, because the next release moves the distribution under it.
Who built it
TypeSafe AI is a San Francisco lab that spent roughly two years in stealth and announced itself on 15 September 2026 with a $40M seed round led by DCVC. The founding team is Diogo Almeida (CEO), Erik Gafni (CTO) and Sasha Sheng (COO). Almeida was a researcher at OpenAI and is credited as a co-inventor of the RLHF work behind ChatGPT — which makes a company whose pitch is "stop training models to please people, start training them to be calibrated" a pointed second act.
The positioning they use is "machine-native, composable AI": models built for software to call rather than for people to talk to. Jev is the first public model under that banner, and the naming suggests it is meant to be the first of a class rather than a one-off product.
- Founded 2024, San Francisco
- $40M seed, led by DCVC
- Out of stealth 15 Sep 2026
- First model: Jev, early access
- Docs at docs.typesafe.ai
- Evals at evals.typesafe.ai
Frequently Asked Questions
What is Jev?
Jev is the first publicly available "System One model", released in early access by TypeSafe AI on 15 September 2026. Instead of generating text token by token, it takes unstructured state plus a set of typed questions and returns typed answers — a choice, a score, or a probability — with a calibrated confidence attached, in a single parallel pass. TypeSafe measures end-to-end responses at 70–500ms, with most queries landing near 100ms. It is named after the Victorian economist William Stanley Jevons; "System One" is a reference to the fast, intuitive mode of thinking in Daniel Kahneman’s Thinking, Fast and Slow.
What is a System One model?
A System One model is a class of model trained to make fast, bounded decisions that software consumes directly, rather than to produce strings a human reads. The contract is inverted compared to an LLM: you declare the shape of the answer in advance, and the model fills it. Because the output space is fixed before inference, the model samples all answers in parallel instead of autoregressively, and the response cannot be malformed. TypeSafe trains for this with a method it calls Reinforcement Learning for Calibrated Decisions (RLCD), which optimises for probabilities that match real outcomes, as opposed to RLHF’s optimisation for human preference.
How much does Jev cost?
TypeSafe lists $0.042 per million input tokens — $42 per billion — and bills output tokens at zero, on the grounds that the output is a handful of numbers rather than a generated document. Frontier chat models sit in the $0.20–$10 per million range on input, with output typically around 5x the input rate. In practice, TypeSafe’s own workflow eval puts Jev near $0.0004 per decided case. The company has said openly that it cannot prove the pricing is not subsidised, and expects prices to fall rather than rise.
Can Jev really not hallucinate?
It cannot produce a malformed or out-of-schema answer — that part is a structural guarantee, not a benchmark, and TypeSafe reports a 0% structured-output error rate against 0.58–45.5% for the LLMs it tested. But this is a guarantee about shape, not about correctness. A model constrained to three categories can still confidently pick the wrong one. The honest reading is that Jev eliminates the parsing failure and the invented field; it does not eliminate the wrong judgement. Calibrated confidence is the intended answer to that second problem, and that calibration claim has not yet been independently verified.
Is Jev faster and cheaper than an LLM?
For bounded decision work, substantially — though the headline multiples are vendor-generated. TypeSafe’s homepage claims 193.6x faster and 238x lower input price than Claude Fable 5.1, and its blog quotes figures up to 444.6x cheaper, while noting these represent the higher end of real-world gains. The one independent test published so far, by Every, ran 777 judgments in under 0.7 seconds for roughly a quarter of a cent, around 25x faster than Fable 5.1 — a real advantage, an order of magnitude below the marketing number. Speed and cost survive contact with outside testing; the exact multiples do not.
What can Jev not do?
It cannot generate text, code, summaries or explanations — that is the trade, not a gap. Beyond that, TypeSafe documents several real weaknesses: it is not a calculator, so counting and arithmetic over sets are unreliable; it reads dates as text, so ordering and interval logic fail; double negatives and multi-hop indirection degrade accuracy; and precision drops as the state fills with irrelevant material, so you should retrieve and filter before you ask. It also gives you no rationale, which rules it out as the sole decision-maker anywhere you need an auditable explanation.
How do I get access to Jev?
Jev is in early access behind a waitlist at typesafe.ai, with accounts invited progressively; the console and a shareable query playground live at console.typesafe.ai. Once you have a key, there are official Python (pip install typesafe-sdk, 3.10+) and JavaScript (npm install @typesafe-ai/sdk, Node 20+) SDKs, a raw endpoint at POST https://api.typesafe.ai/v1/systemone, and community integrations for the Vercel AI SDK (@ai-sdk/typesafe-ai) and LangChain (langchain_typesafe).
Should I replace my LLM classifier with Jev?
Only where the decision is genuinely bounded, high volume, and latency-sensitive — triage, routing, moderation, relevance filtering, guardrails on another model’s output. Everywhere else the existing answer is still better: deterministic code is cheaper and exact, and a reasoning model is still what you want for open-ended judgement that has to be explained. The sensible migration is a shadow run: send the same input to both, log where they disagree, and only cut over the paths where you have data.
Related Articles
The Tier 3 models Jev routes to
LLM Observability & Evals 2026How to check calibration on your own data
LangGraph vs CrewAI vs AutoGenThe loop a decision model sits inside
Best Vector Database for RAG 2026Retrieve first, then judge
Browser Infrastructure for AI AgentsWhere the 7.1-second flight booking ran
MCP in 2026: Complete GuideThe tool calls a guardrail classifies