Jev model is the first product from TypeSafe AI, a San Francisco lab founded by Diogo Almeida, one of the researchers behind the instruction-following work that turned a language model into ChatGPT. It does not chat. It does not write code. It does not generate a single word of prose. Given a piece of state and a list of typed questions, it returns typed answers with calibrated probabilities attached, and it returns them in a few hundred milliseconds.
TypeSafe came out of stealth this week with $40 million in seed funding led by DCVC and a set of performance claims that are unusually specific: 193.6 times faster, 444.6 times cheaper, $0.042 per million input tokens, and output tokens billed at nothing at all. Those numbers are real in the sense that the company published them. What they measure is a separate question, and it is the question most of the launch coverage skipped.
This article works through what the Jev model is, how the architecture differs from an autoregressive language model, what the three output primitives actually return, where every headline figure comes from, and what the one independent test published so far found when it ran the model against Claude Fable 5.1. If you build software that already leans on artificial intelligence for classification and routing, this is a genuinely different shape of tool, and the places where the claims thin out matter more than the places where they hold.
Table of contents
- What the Jev Model Actually Is
- Who Built the Jev Model, and Why He Calls ChatGPT a Detour
- Inside the Jev Model’s Three Primitives
- The Speed and Cost Claims, Traced to Their Sources
- What the Jev Model Cannot Do
- Where the Benchmarks Are Agreement, Not Accuracy
- An Independent Test of the Jev Model
- Calibration Is the Load-Bearing Claim
- What the Jev Model Replaces in a Production Stack
- Where the Sources Disagree About the Launch
- What Engineering Teams Should Do About It
- What to Watch Over the Next Two Quarters
- References
What the Jev Model Actually Is
TypeSafe calls its category System One Models, a deliberate nod to fast, automatic, low-effort cognition as opposed to slow deliberate reasoning. The naming is doing real work here. A frontier language model is asked to think out loud and is billed for every token of that thinking. The Jev model is asked to make a judgment and return it, with no explanation, no chain of thought, and no text.
The mechanical difference is that Jev does not generate tokens one after another. It takes an unstructured state and a set of typed questions, and it produces every answer in a single parallel query. Because the output schema is fixed in advance by the caller, the model cannot return a malformed value, a missing field, or a key that was never asked for.
The state can be almost anything
The input state is whatever your code already has in memory: a support ticket, a log line, an email body, a paragraph of user-generated copy, a JSON blob of game coordinates. The Jev model is not parsing it into a structure for you. It is reading it and answering questions about it.
The output is a value, not a string
This is the part that changes how the calling code looks. A language model returns a string that your application has to parse, validate, and defend against. The Jev model returns a choice from a set you supplied, a score on a rubric you defined, or a probability between zero and one, each carrying a confidence figure. There is nothing to parse and nothing to retry when the JSON comes back truncated.
The token budget is small on purpose
The state and the questions share a budget of roughly 32,000 tokens, which TypeSafe documents as around 150,000 characters of English text. Against a frontier model advertising a million-token context, that is about a thirtieth of the room. For the workloads the Jev model targets, a single ticket or a single passage, it is not a constraint anyone will notice.
| Dimension | Frontier LLM | Jev model |
|---|---|---|
| Generation method | Autoregressive, token by token | Parallel sampling, one pass |
| Output | Free-form text you must parse | Typed value plus confidence |
| Explanations | Yes, and you pay for them | None, by design |
| Image input | Usually supported | Not supported |
| Chat interface | Central to the product | Does not exist |
| Context budget | Up to ~1M tokens | ~32K tokens, shared with questions |
| Output token billing | $12 per million (OpenAI list) | Not metered |
Who Built the Jev Model, and Why He Calls ChatGPT a Detour
TypeSafe AI was founded in 2024 by Diogo Almeida, Erik Gafni and Sasha Sheng, and is headquartered in San Francisco. Almeida is the chief executive. Before TypeSafe he was a researcher on OpenAI’s post-training team and a co-author of the 2022 InstructGPT paper, the work that combined human demonstrations, preference rankings and reinforcement learning to make a model follow instructions. That paper is the direct ancestor of ChatGPT, which is why almost every headline about this launch calls him a ChatGPT pioneer or co-inventor. Earlier still, he was a researcher at Google Brain.
His framing of the last four years is blunter than a founder announcement usually allows. Almeida has described the ChatGPT era as “a weird detour” from the field’s original automation goals, and the argument behind that phrase is the whole thesis of the company.
The argument against the human in the loop
Almeida’s position is that today’s models require supervision because supervision is what they were optimised for. “Today’s AI was designed for assistance through optimizing for human preference,” he has said, and more pointedly: “Why do all LLMs require a human in the loop? The simple answer is we literally put them in the loop.”
The consequence he draws from that is uncomfortable for anyone selling confidence in model output. Preference optimisation rewards answers that look right to a reader, which means, in his words, “no matter how wrong the models are, they will look right.” Overpromising, he argues, “is a feature. This is by design.”
What machine-native means in practice
The alternative TypeSafe is pursuing is what Almeida calls machine-native AI. “TypeSafe was founded to pursue an alternative path for AI research, focused on machine-native AI,” he said at launch, and elsewhere: “Most intelligence should eventually live inside software, running quietly in the background.” A Jev model output is not written for a person to read. It is written for an if statement to branch on.
The name is an economics joke
Jev is named after Jevons paradox, the observation that improving the efficiency of a resource tends to increase rather than reduce total consumption of it. The implied bet is that making a decision cost a rounding error will not save anyone money; it will cause them to make vastly more decisions.
| Item | Detail |
|---|---|
| Company | TypeSafe AI, San Francisco, founded 2024 |
| Founders | Diogo Almeida (CEO), Erik Gafni, Sasha Sheng |
| Seed round | $40 million, led by DCVC |
| First product | Jev, a System One Model |
| Training method | Reinforcement Learning for Calibrated Decisions |
| Availability | Early access, waitlist onboarding |
| Disclosed customers | None named at launch |
DCVC’s James Hardiman framed the investment around the integration problem rather than the intelligence one: “TypeSafe is approaching one of the biggest remaining challenges in AI: turning increasingly capable models into technology that developers can reliably build into products at scale.”
Inside the Jev Model's Three Primitives
The API surface is deliberately tiny. There are three question types, and the documentation is explicit that each question should ask “one specific, well-scoped thing.” Complex logic is meant to be decomposed into atomic questions and recombined in your own code, not pushed into the model as a reasoning task.
Choice, Score and Noul
| Primitive | Question shape | Returns | Typical use |
|---|---|---|---|
| Choice | Which of these options? | choice, probabilities, confidence | Routing, categorisation, triage |
| Score | Which level on this rubric? | score, legend, probabilities, confidence | Quality grading, severity, priority |
| Noul | Is this true? | a single value from 0 to 1 | Guardrails, flags, gating |
Noul is the odd one out and the most revealing. It answers a yes-or-no question, but it deliberately does not return a boolean. It returns a probability: near 1 means a strong yes, near 0 a strong no, and around 0.5 means the Jev model does not know. A conventional classifier hands you true and leaves you to discover later that it was a coin flip. Noul hands you the coin flip.
Confidence is a shape, not a vibe
The confidence field is defined as how peaked the probability distribution is. A flat distribution across five options is low confidence regardless of which option won. That is the hook the whole Jev model pitch hangs on: your code can branch on confidence < 0.6 and escalate to a human or to a slower, more expensive model, without any prompt engineering to coax a self-assessment out of a chatbot.
Composition happens in your language, not in a prompt
Because each Jev model question is atomic and every answer is typed, multi-step logic is written as ordinary control flow. A ticket can be scored for severity, checked for a policy breach and routed to a queue in one round trip, with three typed answers coming back together. This is the part of the pitch that will land with teams already running workflow automation pipelines where a language model sits in the middle producing JSON that sometimes parses.
The Speed and Cost Claims, Traced to Their Sources
TypeSafe published a headline range for the Jev model and a peak figure, and different outlets picked up different ones, which is why the numbers in the coverage vary so widely. The headline range is 20 to 200 times faster and 40 to 400 times cheaper. The peak figures, from the company’s own workflow evaluations, are 193.6 times faster and 444.6 times cheaper. End-to-end response time is given as 70 to 500 milliseconds against 3 to 329 seconds for frontier models on the equivalent task.
The pricing is the most checkable number
Jev model input is $0.042 per million tokens. Output is not metered at all, which TypeSafe describes as too cheap to meter and which follows from the architecture: there is no long generated string to bill for. The company states this is 238 times lower than Claude Fable 5.1, which implies a Fable input price of about $10 per million tokens, since 0.042 multiplied by 238 is 9.996.
Against the OpenAI list price of $2.00 per million input tokens quoted in the launch coverage, the Jev model is 47.6 times cheaper on input alone, before the free output tokens are counted. On a workload that generates long structured responses, the output side is where the multiple stretches from 47 to the several-hundred figures TypeSafe advertises.
The latency demo, and one arithmetic check
The launch demo showed a single query returning in 0.114 seconds against 8.566 seconds for GPT-5.6 Terra on the same task. That is 75.1 times faster, which sits inside the advertised 20 to 200 range but well below the 193.6 headline, a reminder that the peak figure comes from a specific multi-step branching workload rather than a typical call.
The Doom bot is a throughput proof, not a stunt
TypeSafe’s more memorable demonstration is a bot that plays Doom by feeding game state to the Jev model at ten queries per second, at an operating cost of roughly $7 an hour. Ten queries a second is 36,000 an hour, which works out at about $0.000194 per decision. A second demo has the model playing Wikiracing, choosing which encyclopedia link to follow next. Neither is a product. Both are arguments that the price and the latency are low enough to put a model inside a loop that previously could not have contained one.
What the Jev Model Cannot Do
The Jev model limitations are not buried. TypeSafe lists them, and they are severe enough that this is a complement to a language model rather than a replacement for one in most stacks.
No text, no code, no images
The Jev model cannot generate text. It cannot write code. It cannot summarise, rewrite, translate or explain. It does not accept image input, and there is no chat interface of any kind. In TypeSafe’s own framing, the model “gives up string generation” as the price of everything else. Anything that needs prose still needs a language model behind it.
No reasoning trace
There is no chain of thought to inspect. When a decision looks wrong, there is nothing to read that explains why the model reached it, only a probability distribution over the options you offered. For regulated workflows where an auditable rationale is part of the requirement, that absence is a hard blocker rather than an inconvenience.
The hallucination claim is architectural, not epistemic
This is the single most important caveat in the launch and the one most widely misreported. TypeSafe says hallucinations are prevented by design. What that means precisely is that schema matching is guaranteed: the Jev model cannot return a value outside the set you defined, and it cannot emit malformed output. It does not mean the judgment is correct. A model that must pick one of five categories cannot invent a sixth, but it can still pick the wrong one of the five. The company’s own materials acknowledge the claim rests on structural guarantees rather than empirical accuracy data.
Where the Benchmarks Are Agreement, Not Accuracy
Here is the methodological detail that reframes the entire benchmark table, and it comes from TypeSafe’s own disclosures. The workflow evaluations use the average of GPT-6 Astra and Claude Fable 5.1 as the reference answer. There is no independent ground truth. The scores therefore measure how closely the Jev model agrees with two frontier language models, not how often it is right.
The score that is easy to miss
On TypeSafe’s own dashboard the Jev model scores 67.8%, against 74.1% for the top comparators. That is a gap of 6.3 percentage points, or put differently, Jev reaches about 91.5% of the comparator score on the company’s own chosen measure. No published figure anywhere shows the Jev model being more accurate than the frontier models it is priced against.
The workflows were written in-house
TypeSafe also discloses that the Jev model workflow examples were created by its own model capabilities team, which introduces an obvious selection effect, and that the speed comparisons use simplified queries that emphasise the architecture’s strengths. Disclosing all three of these things is more than most launches manage. It still means the benchmark table is a description of a favourable case, not a neutral measurement.
An Independent Test of the Jev Model
The most useful outside data point so far comes from Every, whose head of evals ran the Jev model over 27 published articles plus 10 deliberately AI-styled imitations, asking 21 questions of all 37 documents at once.
What 777 judgments in 0.7 seconds costs
The run returned 777 judgments in under 0.7 seconds for an estimated quarter of a cent. That is roughly 1,110 judgments per second and about $0.0000032 per judgment. Across eleven scenarios the same tester produced 1,709 judgments for under one cent in total. Whatever else is in dispute, the throughput and the price are not.
The head-to-head is more instructive
The sharper test was 12 synthetic passages with four writing checks each, run against Claude Fable 5.1 at high effort. The Jev model returned a median 0.35 seconds per passage against 8.83 seconds for Fable, about 25 times faster at roughly one five-hundred-and-eightieth of the cost. On accuracy, Jev caught six of the seven planted defects. Fable caught all seven.
The miss is worth naming because it illustrates the boundary. Jev failed, across three separate runs, to flag an unexplained action in a passage proposing “a shared appointment calendar that parents and staff teach together.” That is a judgment requiring a reader to notice that a claim does not follow, which is exactly the slow deliberate work a System One model is not built for.
| Claim | Source | What it actually measures |
|---|---|---|
| 193.6x faster, 444.6x cheaper | TypeSafe workflow evals | Peak on in-house workflows, simplified queries |
| 67.8% vs 74.1% | TypeSafe dashboard | Agreement with GPT-6 Astra and Fable 5.1 average |
| 75.1x on the launch demo | 0.114s vs 8.566s, TypeSafe | One query against GPT-5.6 Terra |
| 25x faster, ~580x cheaper | Every, independent | 12 passages, 4 checks, vs Fable 5.1 high effort |
| 6 of 7 defects caught | Every, independent | Real accuracy on a small planted-defect set |
| Zero hallucinations | TypeSafe | Schema validity only, not judgment correctness |
Calibration Is the Load-Bearing Claim
Strip away the speed and the pricing and the interesting claim is calibration. RLCD, the training method, stands for Reinforcement Learning for Calibrated Decisions, and TypeSafe positions it explicitly against RLHF: where RLHF optimises for human preference, RLCD optimises for what Almeida calls epistemically honest probabilities.
What calibration would mean if it holds
A calibrated Jev model answer that says it is 70% confident should be right about 70% of the time it says that, across the whole distribution of cases. That property, not raw accuracy, is what makes automated escalation possible. An uncalibrated classifier at 85% accuracy gives you no reliable way to find the 15%. A calibrated one at 70% lets you route the uncertain cases somewhere else and keep the confident ones.
Why you have to verify it yourself
Calibration is a property of a model on a distribution, and your data is not TypeSafe’s. The published figures do not include reliability curves on any external dataset, so the only responsible path is to run a few hundred labelled examples of your own through the Jev model, bucket the outputs by stated confidence, and check whether the hit rate in each bucket matches the number on the tin. That is a day of work and it is the difference between a genuine automation gain and a fast way to be wrong.
What the Jev Model Replaces in a Production Stack
The realistic Jev model deployment is not ripping out a language model. It is moving the high-volume, low-judgment calls off it.
Classification and routing at volume
Support ticket triage, content tagging, lead qualification, spam and abuse flagging, sentiment bucketing. These are calls where a frontier model is being asked to do something a well-tuned classifier could do, and is being billed for a paragraph of explanation nobody reads. Teams running intelligent automation at scale usually have hundreds of thousands of these a month.
Guardrails on other models’ output
A cheap, fast, typed verification pass over a language model’s response is arguably the strongest fit. The expensive model writes; the Jev model checks whether the output breaks a policy, contradicts the source, or needs a human. At a third of a thousandth of a cent per judgment, you can afford to run five checks on every response.
Real-time loops that could not afford a model before
The Doom demo is the argument here. Any loop running at tens of decisions a second, whether that is game state, fraud scoring, bidding or live moderation, was previously priced and latency-bound out of using a model at all. Teams building autonomous AI agents that need dozens of small judgments per step are in the same position.
What stays on the language model
Anything generative, anything requiring an explanation, anything with a multi-step reasoning dependency, and anything where a regulator will ask why. The honest framing of this launch is a two-tier stack, not a migration.
Where the Sources Disagree About the Launch
Three small inconsistencies are worth pinning down, because they propagate through the coverage.
The launch date
The Register reported the Jev model unveiling on Tuesday, which is 15 September 2026, and several outlets date the launch to 15 September. TypeSafe’s own materials and the trade coverage put early developer access opening on 16 September. Both are defensible: the announcement and the access opening appear to be a day apart.
The speed multiple
You will see 20x, 40x, 100x, 193x and 200x in different headlines. The range TypeSafe advertises is 20 to 200 times faster and 40 to 400 times cheaper; 193.6 and 444.6 are workload-specific peaks; 100x appears in the funding coverage as a round-number summary. They are not contradictory, they are different points on the same distribution, but a headline that quotes only the peak is quoting the best case.
Customers and revenue
No production customers have been named and no revenue figures disclosed. The company is in early access with a waitlist. Any coverage implying deployed enterprise usage is ahead of the evidence.
What Engineering Teams Should Do About It
If your systems already send a high volume of small classification calls to a frontier model, the Jev model deserves an evaluation this quarter. If they do not, this is a launch to watch rather than act on.
Four questions to answer before you commit
First, what fraction of your model calls are actually decisions rather than generation? If it is under a fifth, the savings will not justify a second vendor. Second, do you have labelled data to test calibration on, and if not, can you produce a few hundred examples? Third, what is your fallback when confidence is low, and is a human or a bigger model on the other end of that branch? Fourth, does anything in your compliance posture require an explanation for an automated decision, because there is not one available.
The counterweight
This is a seed-stage company with one model, no named customers, a 32,000-token budget, and benchmarks scored against other models’ answers. The architecture is genuinely different and the independent numbers on speed and cost held up under outside testing. The accuracy question did not get a clean answer, and it is the one that decides whether any of the rest matters for your workload.
What to Watch Over the Next Two Quarters
Whether an external accuracy benchmark appears
The missing Jev model artefact is a reliability diagram on a public dataset with real ground truth. If RLCD does what TypeSafe says, that chart is the easiest possible proof and its continued absence would be informative.
Whether the frontier labs ship a structured-output mode
Constrained decoding and typed outputs already exist as features on the major APIs. The defensible part of the Jev model is the calibration training and the parallel architecture, not the type safety. Watch whether the incumbents close the price gap on small classification calls.
Whether named customers go on the record
Early access with a waitlist is the right posture for a two-week-old product. By the second quarter of availability, a company claiming two orders of magnitude of savings should have a customer willing to say so publicly.
Whether the token budget grows
A 32,000-token ceiling is fine for a ticket and awkward for a contract. If TypeSafe extends it without losing the latency profile, the addressable set of workloads widens considerably.
References
Introducing System One Models and Jev
ChatGPT pioneer launches Jev model for programmatic logic
TypeSafe AI debuts model for machines that plays Doom
Mini-Vibe Check: TypeSafe’s Jev Judged Everything I’ve Written in 0.7 Seconds
TypeSafe AI emerges from stealth with $40M
Training language models to follow instructions with human feedback
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.