TypeSafe AI Launches System One Models and Jev: Turning Probabilistic Decisions into Function Calls

Language models have been superhuman at chat for years, yet widespread automation hasn’t happened. Diogo Almeida, founder of TypeSafe, helped build the methods at OpenAI that made language models useful at following instructions and conversing with people. That work became the research behind ChatGPT. At the time, he thought chat models might lead to AGI, but it soon became obvious that something big was missing. After two years in stealth, countless technical challenges, and research breakthroughs, TypeSafe AI is releasing its first System One Model, along with a companion model called Jev.

Jev’s core idea can be summed up in one sentence: it’s a frontier-intelligence function call. Unstructured state in, typed probabilistic decisions out. The model gives up string generation, is optimized for structured outputs, cannot hallucinate, and never makes type errors.

What Makes System One Models and Jev Different?

TypeSafe breaks down the differences between existing LLMs and System One models across eight dimensions.

Existing LLMs System One + Jev
Optimized with Reinforcement Learning with Human Feedback (RLHF) / Reinforcement Learning with Verifiable Rewards (RLVR) Reinforcement Learning for Calibrated Decisions (RLCD)
Optimizes for Human preference: writeups and chat responses that human raters prefer. Verifiable rewards: outputs that can be programmatically verified. Calibrated decisions: answers with epistemically honest probabilities on System One tasks.
Inputs Unstructured data (e.g. text) with an emphasis on sequential messages. Unstructured data (e.g. text) with an emphasis on structured program state.
Outputs Strings / generated text. Strings are flexible and can be anything: chat responses, code, hallucinations, refusals, or even type-safe structured values. To be used by software, responses need to be parsed and validated. There is also always some risk that the AI goes off the rails. Type-safe structured values. Possible outputs and structure are defined in advance. The model never makes type errors. All answers are accompanied with calibrated probabilities and confidence scores.
Sampling Sequential. Generates one token at a time, each conditioned on the last. Parallel. Generates all outputs in a single query. Incredibly efficient and hardware-aware.
Cost Input tokens: from 10 / MTok. Output tokens: ~5x more expensive than input tokens. Input tokens: 42 per billion tokens). Output tokens: FREE (too cheap to meter).
Speed End-to-end response time is 3 to 329 seconds for frontier models. Fast enough for interfacing with humans, but a big bottleneck when integrated in code. End-to-end response time is 70ms-500ms for TypeSafe. This can range from 40x-200x faster for the same levels of frontier intelligence for System One shaped queries.
Confidence Even if prompted for a confidence estimate, models tend to be overconfident and inconsistent. If a model can do a task 95% of the time but doesn’t say when it’s in the 5%, it can’t automate that task. Always communicates confidence and uncertainty with every output. Calibrated: higher confidence means higher accuracy. More consistent: returns similar answers for similar inputs.
Use cases Human-in-the-loop tasks (chatbots, copilots, coding agents). General and powerful, but requires human oversight because their freedom also means they might go off the rails. Verifiable problems (math proofs, kernel optimization). When correctness can be checked cheaply and automatically, LLMs can generate, test, and iterate until they find something that works. Demos. The flexibility of strings allows it to be incredible for quickly making prototypes that only work sometimes. AI-Powered Workflows / smart if-statements. Structured outputs slot into ordinary software as fuzzy decision rules: classify, route, score, extract, or branch where hand-written logic is too brittle. The surrounding code constrains their freedom, making them easier to compose into reliable systems. Map-reducing over big data. Turn petabytes of data into features and insights. Real-time applications. 100ms speeds means you can use AI in your applications where UX is critical. Verify everything. Score, judge, verify, guardrail, and detect jailbreaks of LLM prompts, reasoning traces, and/or outputs.

The most important differences are sampling and output type. Existing LLMs generate one token at a time, each conditioned on the last. This sequential sampling makes it hard to push end-to-end response time below one second. Jev generates all outputs in a single query, with end-to-end response times between 70ms and 500ms. For System One shaped queries, this is 40x to 200x faster at the same level of frontier intelligence.

Output type matters just as much. LLMs output strings. Strings can be anything: chat responses, code, hallucinations, refusals, or even type-safe structured values. Software must parse and validate these outputs, and there is always a risk the model goes off the rails. Jev’s output structure and value ranges are defined in advance. The model never makes type errors, and every answer comes with calibrated probabilities and confidence scores.

Cost differences are even more direct. LLM input tokens cost between 10 per million tokens, with output tokens about 5x more expensive. Jev’s input tokens cost $0.042 per million tokens, and output tokens are free. TypeSafe says output tokens are too cheap to meter.

Evidence for Speed, Cost, and Type Safety

TypeSafe separates verifiable claims from those that need more evidence.

On speed, they acknowledge their published evals are generally run from laptops on the West Coast, where their service is currently based. On cost, they can’t prove it isn’t subsidized; they’ll need the long term to prove the sustainability of their pricing, which they expect to go down, not up. On type safety, they point out this would be easy to falsify with a single counter-example, but it is mathematically impossible.

For their bolder claims, TypeSafe provides more nuance. They built a side-by-side demo showing a key difference between their models and LLMs: Jev outputs all probabilities in parallel instead of autoregressively generating by token. Strings are extremely powerful and general, but costly. “Giving up” strings actually gives them a lot of superpowers.

The query in this demo is highly simplified. The questions were chosen to have descriptive, human-readable keys so the output is understandable on screen. The state is a short, dense, and detailed paragraph to emphasize the difference in sampling methodology. The relatively shorter input paints their model in an advantageous light. In the recorded run, the only disagreement with GPT-5.6 Terra is on “Churn likelihood level.” TypeSafe believes the actual answer is genuinely ambiguous. They used GPT-5.6 Terra with default reasoning because they’ve found it to be the most comparable at intelligence to Jev on average.

Real-World Gaps in Workflow Evaluations

TypeSafe created a new type of evaluation to measure how well AI works within code. They don’t optimize for a ground truth classification or allow the harness and model to change (which could allow for overfitting via harness engineering). Instead, they assume there is a correct compute graph (a “workflow” represented in code) and use the predictions of the largest, smartest, and most expensive external models as reference probabilities. Every model gets the same workflow. They test how they compare to the average of the smartest models (in this case, Astra and Fable).

Jev is off the charts, owning the Pareto frontier for almost 2 orders of magnitude. They also compare to models with a generated prompt doing all the logic in their chain-of-thought, but this tends to do significantly worse than using the workflow itself.

The calls here are significantly more complex than the side-by-side demonstration above. That’s because they’re more representative of the types of production workloads needed for true business automation. Below is the simplest of the 4 workflows they’re publishing:

The most reliable real-world workflows tend to have many independent, decomposed questions, with fine-grained behavior that’s dependent on probabilities instead of discrete decisions. The end result is discrete branching, but how we get to a final answer involves a lot of domain-specific engineering that needs to be done highly consistently.

See our workflow evals site for all the details: examples, disagreements, full queries, and each workflow.

The claims of 193.6x faster and 444.6x cheaper on their home page come from this. TypeSafe expects these are on the higher end of real-world gains. The contents of these workflows were not deliberately chosen nor constructed to make their model look good, and are not in their training distribution. However, they were made by individuals on their model capabilities team, so some bias could exist. They use the average of GPT-6 Astra and Fable 5.1 as the reference answer, which biases answers towards OpenAI and Anthropic’s models. They likely underestimate the relative performance of their model and DeepSeek’s models. The LLMs use their System One LLM wrapper, which constrains LLMs to output structured decisions compatible with their API. They have found this to be the most accurate way to get decisions from LLMs, but this tends to be slower and more expensive than giving decisions without probabilities.

Hallucination and Type Safety Are Two Sides of the Same Coin

TypeSafe believes hallucination and type safety are intrinsically related, and type safety is table stakes for automation. A hallucinated tool call is inconvenient in an agent, but it’s an absolute deal-breaker if it’s part of a system with latency guarantees or if it’s buried several layers deep in a dependency chain. Existing models, no matter how smart, still hallucinate and have type errors.

The numbers for LLMs are from OpenRouter, so there almost certainly is bias here: more complex queries might be routed to better models. TypeSafe’s number is not empirical. Schema matching is guaranteed, so they can confidently add 0% into the plots.

Two Fun Demos

Perhaps the most exciting part of their work is enabling new use cases. Here are a couple of the team’s favorites.

Doom

They love how this demo demonstrates real-time intelligence and what can be done with code + AI. The engineer behind it was worried about making 10 queries a second, which ends up costing ~$7/hour, but the rest of the team agreed that was lower than expected. TypeSafe intends to release an in-depth walkthrough and host events to hack on this. The demo is on structured state as a data structure with text, not on images (yet). A non-AI Doom bot could play better, but they wanted a bot that was reactive to different representations of game state, and most importantly, following instructions was cool as heck.

Wikiracing

The objective of the game is to start on one Wikipedia page and reach a specific other Wikipedia page using only links you come across while traversing. Each step can mean choosing between hundreds to thousands of links. It’s a great playground for demonstrating not just intelligence-per-second, but also the compounding benefits of not hallucinating with high-cardinality choices.

As far as TypeSafe knows, it was completely random that both the 2nd and 3rd challenges started with “Rubber Duck.” The author only noticed when the team pointed it out. Their speedups here tend to be a lot less than in previous demos. That’s because this is against the non-reasoning modes of the models (except Astra, which was set to the lowest reasoning setting). This is also why Jev tended to finish in fewer steps, a sign of greater intelligence. This was to make the demo more bearable to watch. The LLMs look much worse at this task than with reasoning enabled. Jev supports a cardinality up to 255. For the higher cardinality choices, they do a 2-stage system of scoring independently then making an explicit choice, hence the occasional slowdown.

What’s Next

Jev is still in its early days. TypeSafe has a lot more in the pipeline and is excited to keep shipping. Today, they are opening early access and bringing developers off the waitlist as quickly as they can. They want to hear which decisions you need to automate, where Jev works, and where it falls short.

TypeSafe started because they believe AI needs an interface software can depend on. They can’t wait to see new use cases continuously diffuse through the community and economy.

FAQ

Where do the names “System One Models” and “Jev” come from?

They were inspired by Daniel Kahneman’s Thinking, Fast and Slow. The model class name draws on the distinction between fast, intuitive System 1 thinking and slow, deliberate System 2 reasoning. “System 1 thinking” has also implied error-prone. For reasons they will get into in the future, they believe System One Models can be made more reliable than its alternatives. They named Jev after William Stanley Jevons. They expect machine intelligence to follow a similar path to coal, after steam-engine efficiency led to an increase in demand. Every order of magnitude drop in the cost of intelligence unlocks orders of magnitude more use cases.

Why was a new training algorithm needed?

The blog doesn’t provide a detailed explanation. It only says this is the core of their training method, called Reinforcement Learning for Calibrated Decisions.

What use cases is Jev good for?

AI-powered workflows and smart if-statements are the main scenarios. Structured outputs slot into ordinary software as fuzzy decision rules: classify, route, score, extract, or branch where hand-written logic is too brittle. The surrounding code constrains their freedom, making them easier to compose into reliable systems. Other scenarios include map-reducing over big data, turning petabytes of data into features and insights, and real-time applications where 100ms speeds let AI be used in UX-critical applications. Verification is also a key scenario: score, judge, verify, guardrail, and detect jailbreaks of LLM prompts, reasoning traces, and/or outputs.

Is Jev just a smaller LLM?

No. Jev uses a new model architecture, a parallel sampler, and the RLCD training method. Its output type is type-safe structured values, not strings. It gives up string generation in exchange for speed, efficiency, and type safety.

How does Jev perform against public benchmarks?

The blog doesn’t provide public benchmark comparisons. It provides its own workflow evaluations, using the average predictions of the smartest models as reference probabilities.

Where does the training data come from?

The blog doesn’t say.

These results seem crazy. How is it possible?

The blog doesn’t give technical details. It only says they use a new architecture, a parallel sampler, and RLCD.

Action Checklist

  • Visit typesafe.ai to request early access; the waitlist is being brought off as quickly as possible.
  • Check docs.typesafe.ai to understand how output structures are defined.
  • Use the workflow evals site to see full queries, examples, and disagreements for all four workflows.
  • If you need to compare with LLMs, use the System One LLM wrapper to constrain output structure.
  • For real-time applications, design around 70ms to 500ms response times.
  • For high-cardinality choices, note that Jev supports up to 255. Higher cardinality requires a two-stage process.
  • Cost is $0.042 per million input tokens; output tokens are free.
  • The Doom demo costs about $7/hour at 10 queries per second, which can serve as a reference for real-time scenarios.