# He Says He Co-Invented ChatGPT. His New AI, Jev, Won't Write a Word > Source: > Published: 2026-09-17 08:41:49+00:00 On 15 September, Diogo Almeida opened a launch post on [X](https://x.com/CompleteSkeptic) with this: "After co-inventing ChatGPT, I kept asking myself: why have superhuman chat models not led to AGI?" [The Register](https://www.theregister.com/ai-and-ml/2026/09/16/typesafe-ai-debuts-model-for-machines-that-plays-doom/5296711) 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](https://typesafe.ai/) calls Jev the "first public System One Model, optimized for automation". The [launch post](https://typesafe.ai/blog/introducing-system-one-models-and-jev) 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](https://docs.typesafe.ai/introduction) 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 [changelog](https://vercel.com/changelog/typesafe-ai-jev-now-available-on-ai-gateway) 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 [provider docs](https://ai-sdk.dev/providers/ai-sdk-providers/typesafe-ai) field for field. ``` js 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 [skeptical write-up](https://anthonymaio.substack.com/p/jev-the-language-model-that-wont): 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](https://evals.typesafe.ai/) 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](https://x.com/rauchg) 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](https://x.com/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](https://x.com/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](https://www.amazon.com/dp/B0GX38N645), 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](https://www.amazon.de/-/en/dp/B0GXNNMKVF).