On 15 September, Diogo Almeida opened a launch post on
X with this: "After co-inventing
ChatGPT, I kept asking myself: why have superhuman chat models not
led to AGI?" The Register
describes him as a former OpenAI researcher and a co-inventor of
RLHF and ChatGPT. His company, TypeSafe AI, has raised $40 million.
His new model is called Jev, and it cannot write you an email. It
cannot summarise a document or explain a stack trace. TypeSafe gave
up string generation on purpose. One of its launch demos plays
Doom.
Think about the last LLM call you wired into a code path that had
to act on the answer. You asked for one of four ticket categories.
Most calls came back as Billing. Some came back as billing. with
a trailing period, and one returned a polite paragraph saying it was
probably billing but could be account access. So you wrote a parser,
then wrapped it in a schema check and a retry. All of that existed
to feed one if statement downstream.
Jev is a bet that a large share of AI traffic is that if
statement.
TypeSafe's homepage calls Jev the "first
public System One Model, optimized for automation". The
explains the name. It comes from Daniel Kahneman's split between
System 1, the fast and intuitive mode of thinking, and System 2,
the slow and deliberate one.
Chat models answer by writing, token after token, and the decision
you need sits somewhere inside the text. A System One model skips
the writing. You hand it the state of the world and a set of
questions, and it hands back decisions.
Two parts of the design are named in the launch post. The training
method is RLCD, "Reinforcement Learning for Calibrated Decisions".
TypeSafe places it next to RLHF, which optimises for human
preference, and RLVR, which optimises for verifiable rewards. RLCD
targets "calibrated decisions: answers with epistemically honest
probabilities". The second part is a "parallel sampler" that
"Generates all outputs in a single query" instead of going token
by token.
Calibrated has a concrete meaning. When the model says 0.8, it
should be right about 80% of the time. As of launch, TypeSafe has
not published the algorithm or the architecture behind either
piece.
Put the two paths side by side. With a chat model, your decision
code sends a prompt, receives text, parses it, validates it and
retries when validation fails. With Jev, you send state plus typed
questions and get back what the homepage calls "typed decisions
with calibrated probabilities". There is nothing to parse.
Strict structured-output modes on the major LLM APIs already get
you a valid enum with no parser. What Jev adds, by TypeSafe's
account, is a calibrated probability next to the answer, at far
lower latency and cost.
The docs state the
philosophy in one line: break judgments down into "atomic
questions, composed in code". Every question is one of three
primitives, and you can put several in one request, where they are
evaluated in parallel.
boolean.
The Register printed an example answer to a routing question:
{"billing": 0.08, "technical": 0.85, "sales": 0.07}, with a
confidence of 0.82. That is a distribution over your options. Your
code decides what 0.85 is worth.
The AI SDK has a TypeSafe provider. Vercel's
from 16 September says Jev "is now available on AI Gateway", with
AI SDK 7 as the client. Direct TypeSafe API keys are still in early
access, so expect to wait for one.
pnpm add ai@latest @ai-sdk/typesafe-ai
export TYPESAFE_AI_API_KEY=...
The scenario: a support ticket arrives. You want to know which team
owns it, how blocked the customer is, and whether they are asking
for money back. The call below follows the
field for field.
import { typeSafeAi } from '@ai-sdk/typesafe-ai';
import { experimental_evaluate } from 'ai';
export async function triage(ticketText: string) {
const result = await experimental_evaluate({
model: typeSafeAi.evaluationModel('jev-latest'),
state: { message: ticketText },
questions: {
team: {
type: 'choice',
instructions: 'Which team should handle this?',
criteria: {
billing: { includes: ['Charges', 'Refunds'] },
technical: ['Bugs', 'Error messages'],
account: ['Login problems', 'Access'],
other: null,
},
},
severity: {
type: 'score',
instructions: 'How blocked is the customer?',
criteria: ['Cosmetic', 'Workaround exists', 'Blocking'],
},
wantsRefund: {
type: 'boolean',
instructions: 'Is a refund requested?',
},
},
});
const a = result.answers;
return {
team: a.team.choice,
teamConfidence:
result.providerMetadata.typesafe.confidence.team,
severity: a.severity.score,
refundP: a.wantsRefund.probability,
};
}
Three shapes come back. choice is the selected option.
score is a fractional score for the ordered levels you listed.
probability is P(true). Confidence lives in
providerMetadata.typesafe.confidence and exists for Choice and
Score questions only. Values are rounded to two decimals. A failed
call throws APICallError, and the SDK retries 429 and 529
responses up to maxRetries, which defaults to 2. If you go
through AI Gateway, the model id is the string 'typesafe-ai/jev'
instead.
The routing logic is the part your team owns. It is plain
TypeScript with no API dependency, so you can run and test it
today.
type Triage = {
team: string;
teamConfidence: number;
severity: number;
refundP: number;
};
type Route =
| { kind: 'human'; reason: string }
| { kind: 'refund-desk'; priority: number }
| { kind: 'queue'; team: string; priority: number };
const MIN_TEAM_CONFIDENCE = 0.7;
const REFUND_YES = 0.9;
const REFUND_NO = 0.1;
Those three constants are the numbers you tune. Below
MIN_TEAM_CONFIDENCE, a person picks the team. REFUND_YES and
REFUND_NO mark where a refund probability counts as a clear yes
or a clear no.
export function decide(t: Triage): Route {
if (t.teamConfidence < MIN_TEAM_CONFIDENCE) {
return { kind: 'human', reason: 'unsure which team' };
}
if (t.team === 'other') {
return { kind: 'human', reason: 'no matching team' };
}
if (t.team === 'billing') {
if (t.refundP >= REFUND_YES) {
return { kind: 'refund-desk', priority: t.severity };
}
if (t.refundP > REFUND_NO) {
return { kind: 'human', reason: 'refund unclear' };
}
}
return {
kind: 'queue',
team: t.team,
priority: t.severity,
};
}
The probability is what makes this different from a boolean flag.
A billing ticket with a refund probability of 0.95 goes straight to
the refund desk. One at 0.05 stays in the billing queue. Anything in
between lands with a person, because that middle band is where an
automated refund decision costs you most. The thresholds here are starting
points. Set yours from a few hundred tickets your team has already
labelled.
The homepage says "Zero Hallucinations". The launch post lists a 0%
hallucination rate and adds its own caveat: "Our number is not
empirical. Schema matching is guaranteed".
That second sentence is the entire guarantee. Ask for one of
billing, technical, account or other, and TypeSafe
guarantees one of those four comes back. No billing. with a
stray period, and no fifth team invented on the spot.
You can still get the wrong one. Anthony Maio makes that point in a
a schema guarantee stops malformed output, and it does nothing to
stop the model from "picking the wrong option". The Register says the hallucination-free
comparison "really isn't a fair comparison as its output is not
natural language", and notes that answers can still be wrong. The
schema was always the easy half of the problem. Whether technical
was the right call is the hard half, and no output format settles
it.
Maio raises two more issues worth carrying into production. First,
"The reward function, architecture, training procedure, and
calibration methodology are all undisclosed", and calibration has
to survive distribution shift. Your tickets are not TypeSafe's test
set. Second, and this one hits the decide function directly:
"individually calibrated judgments do not automatically compose
into a calibrated workflow once you run them through thresholds,
weights, and branches". Three well-calibrated answers fed through
your if statements can still produce a badly calibrated route.
Measure the routes, end to end, against labels.
The homepage runs a side-by-side example. Jev answers in 0.114s for
$0.000081. The LLM takes 8.566s and $0.013880. On those numbers,
Jev is about 75x faster and 171x cheaper. All of it is
vendor-reported.
A separate banner on the same page reads "193.6x Faster, 444.6x
Cheaper", with a footnote: "based on workflows for System One
tasks". That banner is a different measurement from the example.
The launch post puts end-to-end latency at "70ms-500ms", against
"3 to 329 seconds" for LLMs. Input is priced at $0.042 per million
tokens, which TypeSafe also writes as $42 per billion. Output
tokens are listed as "FREE (too cheap to meter)".
TypeSafe deserves credit for printing its own footnotes. The
side-by-side query is "highly simplified". Its short input "paints
our model in an advantageous light". And the 193.6x and 444.6x
banner figures sit at "the higher end of real world gains".
The vendor-run workflow evals add
accuracy to the comparison. Across four workflows, Jev scores 67.8%
at $0.0004 per case and 0.4s. GPT-5.6 Sol scores 74.1% at $0.0836
and 23.3s. GPT-5.6 Luna scores 66.8% at $0.0033 and 12.9s.
"Accuracy" there means agreement with reference labels generated
from an average of GPT-6 Astra and Claude Fable 5.1 responses, both
at high thinking, and TypeSafe says the evals may carry "some bias"
because its own team built them. On TypeSafe's own numbers, GPT-5.6
Sol and Claude Opus 5 (73.1%) clearly beat Jev, which sits with the
pack at a small fraction of the cost and latency.
The most useful result on that page applies to every model. Each
LLM got more accurate, cheaper and faster when the task was split
into Choice, Score and Noul questions instead of one big prompt. In
aggregate, Luna went from 51.9% to 66.8%, one point behind Jev.
Decomposition carries a big part of the win, and you can have that
part with the model you already call.
Vercel CEO Guillermo Rauch wrote about fx,
a Vercel tool whose default auto mode runs a safety reviewer on
every command. He said that reviewer runs on GPT-5.6 Luna today,
that "Jev is up to 18x faster (p95) and more accurate", and that
it is "likely new default". The word is likely. Vercel's Pranit
(@fazxes) reported "~5-18x faster and more
accurate than gpt-5.6-luna", without a published dataset or further
numbers as of 17 September.
Most of these come straight from TypeSafe's launch post.
Nathan Flurry of Rivet (@NathanFlurry)
gave the framing that fits best: "jev does not replace gpt /
claude", "jev is just a really smart switch statement", "like if
2016 ml classifiers got 2026 levels of intelligence".
That tells you where Jev goes in your system. TypeSafe pitches it for places
where you "Classify, route, score, extract, or branch where
hand-written logic is too brittle", and for work that needs you to
"Score, judge, verify, guardrail, and detect jailbreaks of LLM
prompts". Vercel's changelog lists agent-shaped jobs: selecting a
tool or subagent, choosing the next action (continue, retry, ask
the user, halt), rating urgency or risk before an operation, and
validating outputs.
In an agent loop, the chat model writes and Jev picks the branch.
Maio's summary holds up: "The strongest case for Jev is
architectural rather than algorithmic".
Whether Jev's accuracy holds on your data is an open question, and
only your labelled examples can answer it. The architectural
lesson doesn't need Jev at all. Wherever an LLM's output feeds an
if, stop asking for prose and ask for typed answers instead. Do
it this week with the structured output your
current model already supports. If Jev's numbers survive your
eval, the calibrated probabilities are what you gain on top, and
the questions are already written.
Jev's pitch rests on an idea you can use with any model today. I
wrote AI That Answers to build it with regular LLMs in
TypeScript: structured output your code can branch on, and the
token cost of every call. If this post made you look twice at the
parser behind your LLM calls, start there. I also wrote the
Prompt Engineering Pocket Guide,
a short companion for when you start breaking one big prompt into
small questions.
AI in TypeScript — five books, one path from your first LLM call to agents in production:
Pocket Guides for Developers — short references you can finish in an evening:
Going deeper on tracing and evals: Observability for LLM Applications.