TypeSafe AI and Jev: System One Models Explained

The claim, stated plainly

On 15 September 2026 a San Francisco lab called TypeSafe AI came out of stealth with $40 million in seed funding led by DCVC and a model called Jev. The pitch is unusual for an AI launch because it starts by giving something up. Jev does not write. It does not chat, explain, summarise or produce code. You send it a state (a piece of text or a JSON object) and a set of typed questions, and it returns typed answers with probabilities: which of these options, how far along this scale, is this statement true.

TypeSafe calls this a System One Model, after Daniel Kahneman's fast, intuitive System 1 thinking, and says it is the first of a new class. The company's own summary is that Jev is "a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out."

The numbers it leads with are large: 70–500 ms end to end, $0.042 per million input tokens with output free, and "193.6× faster, 444.6× cheaper" than LLMs on its own workflow benchmarks. This article explains what the model actually does, where those numbers come from, what the company's own documentation says it cannot do, and how to decide whether it belongs in your stack.

Why a lab would build a model that cannot talk

The founder story is the argument. Diogo Almeida, TypeSafe's CEO, was an OpenAI researcher and a co-inventor of RLHF and InstructGPT, the methods that turned GPT-3 into ChatGPT. His launch post opens with the question that has clearly bothered him since: "Models have been superhuman at chat for years, so where is all the automation?"

His answer is that RLHF optimises for the wrong task if what you want is a decision inside a program. Reinforcement learning from human feedback trains a model to produce the text a human rater prefers. That made models superb at instruction-following and conversation, and it also produced what TypeSafe's primer calls the side effects: sycophancy, confident-sounding hallucination, overconfidence, and mode dropping, where the model narrows toward a preferred style and away from an honest distribution over answers. A model that does a task correctly 95% of the time but cannot tell you when it is in the other 5% cannot be left to run unattended.

TypeSafe's alternative is a third post-training path alongside RLHF and RLVR (reinforcement learning with verifiable rewards, which produced reasoning models). It calls its method Reinforcement Learning for Calibrated Decisions (RLCD). The objective is not "say what people like" but "return a probability that matches how often you are right." Across a well-calibrated model's predictions, outcomes assigned 0.8 should occur about 80% of the time. That property is what lets software act on the answer.

The company frames this in a second post, The Bitterest Lesson, as an extension of Rich Sutton's essay: compute beats clever algorithms, but choosing the right task beats compute. Its example is InstructGPT, where models 100× smaller than GPT-3 beat it on usefulness simply by being trained on the task people actually wanted.

What you send and what comes back

The whole API is one endpoint, POST https://api.typesafe.ai/v1/systemone, and three question types.

Every question in a request is evaluated against the same state, in parallel and in isolation. That last word matters more than it sounds. Because the answers do not condition on each other, adding a question does not change the others and barely changes the response time. TypeSafe's own cookbook runs a 13-question regulatory briefing over the GDPR Wikipedia article and reports that batching every question into one call is 12.2× cheaper and 10× faster than asking them one at a time, with identical answers.

Here is the docs' own example, a support ticket asked three things at once:

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the customer appears",
      "criteria": ["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

And the response, 312 input tokens and, at published rates, about a hundredth of a cent:

{
  "model": "jev-latest",
  "answers": {
    "department": { "type": "choice", "choice": "technical",
      "probabilities": { "billing": 0.159, "technical": 0.84, "sales": 0.001 }, "confidence": 0.596 },
    "frustration": { "type": "score", "score": 1.035,
      "legend": { "0": "Calm, just stating facts", "1": "Frustrated but civil", "2": "Very angry, strong language" },
      "confidence": 0.842 },
    "is_urgent": { "type": "noul", "noul": 0.999 }
  },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}

Notice the department answer. The model is fairly sure it is technical (0.84) but the confidence is only 0.596, because billing is a plausible second reading of a failing Stripe connection. That is the product: not the label, but the honest shape of the doubt around it.

Why "zero hallucinations" is true and also not what you think

TypeSafe's homepage says "Zero Hallucinations", and its launch post says the model "can't hallucinate." Both are precise in one sense and easy to over-read in another.

The precise sense: Jev's outputs are a probability distribution over the options you defined. It is structurally impossible for it to return a fourth department, a made-up tool call, a refusal, or a paragraph of prose. TypeSafe's write-up is candid that its 0% type-error figure "is not empirical" — it is guaranteed by the design, so they simply plot it at zero. For anyone who has parsed LLM output with a regex and a prayer, that is a real property.

The over-read: it does not mean the answer is right. Jev can pick billing when it should have picked technical. What it cannot do is pick billing and tell you it is certain when it is not, at least not on average. The Register's coverage made the same point: the outputs are not natural language, so "hallucination" is the wrong frame, and structured answers can still be incorrect.

The honest version of the claim is: no type errors, ever; wrong answers, sometimes; and a calibrated confidence score that lets your code tell the two situations apart. TypeSafe's documentation suggests three bands: act automatically on high confidence, confirm or gather more on medium, and do not act on low. Where the boundaries sit depends on the stakes; its example gates a balance check loosely and a fund transfer at above 0.9.

The benchmarks, with the caveats TypeSafe itself lists

The headline figures come from four "workflow evals" TypeSafe built and published at evals.typesafe.ai: security-incident triage, agent-trace observability, invoice processing, and customer service. Each task is decomposed into a fixed compute graph of narrow questions and code; every model runs the same graph; and the reference labels are the average of GPT-6 Astra and Claude Fable 5.1.

Averaged across the four, the numbers as published on 17 September 2026:

Read that carefully. Jev is not the most accurate model on the chart; Sol and Opus 5 beat it by six to seven points. What it is, at roughly the accuracy of Terra and Sonnet 5, is 25 to 300 times faster and 75 to 400 times cheaper. "Off the Pareto frontier" is the correct description: nothing is both cheaper and as accurate, and nothing is both faster and as accurate.

TypeSafe's nuance section deserves credit for listing the ways this could flatter its model, and you should weigh them:

• The reference labels average two labs' flagships, which biases the comparison toward OpenAI and Anthropic models and likely underestimates DeepSeek.
• The workflows were written by TypeSafe's own capabilities team. They say the tasks were not built to favour Jev and are outside its training data, but "some bias could exist."
• The LLMs are run through TypeSafe's "System One wrapper," which forces them to emit decisions with probabilities. TypeSafe says that is the most accurate way to get decisions from an LLM, but it is slower and dearer than a plain prompt.
• The latency figures were measured from laptops on the US West Coast, where the service runs.
• The 193.6× and 444.6× homepage numbers are described by TypeSafe as "the higher end of real world gains."

The company also says it will not publish results on public benchmarks at all, and argues everyone should put less weight on them, "even when you're ahead." Whether that is principle or convenience, the practical consequence is the same: you have to build your own eval, which System One tasks make unusually easy because the answer space is small and typed.

What it cannot do, from the manufacturer

The most useful page on docs.typesafe.ai is the one titled Jev 1.13 jaggedness, reviewed 16 September 2026. It lists eight failure modes with fixes, and reads like a manufacturer's warning label rather than marketing. Condensed:

1. Literal reading. Jev answers the question you wrote, not the one you meant. Negations, scoping words and implied conditions are taken at face value. If you find yourself explaining what you "really meant," that explanation was the missing half of the instruction.
2. Maths and counting. It does not count reliably, cannot judge whether two hex colours are close, and its Score output should not be used to reconstruct a precise number between two levels. Keep arithmetic in code.
3. Dates. It reads dates as text, not ordered quantities. Extract the components as Choices (month, day, year, with an explicit "not stated") and compare in code.
4. Indirection. Double negatives and multi-hop questions cost accuracy. Name the field you mean.
5. Large, noisy state. Accuracy falls as irrelevant material grows. Filter first. Limits are 64k tokens for state plus all questions, and 32k for state plus the longest question.
6. Adversarial content. State is treated as data, not as hostile, so injected instructions or text that argues for its own classification can move the answer. TypeSafe says it expects to improve here.
7. Contradictory instructions and criteria. A Noul whose true means no will underperform. Align the wording.
8. Generation. It is not trained to produce text, and chaining Choices to fake it is slow and poor. Use a generative model, then let Jev pick the correct extraction.

Add the launch-day constraints: text only (no images, audio or video yet), Choice cardinality of 255 with a two-stage score-then-choose fallback above that, rate limits of 250,000 tokens per second and 1,200 requests per minute that the docs say are "adjusting dynamically" while GPU capacity lands, and early access gated by a waitlist.

Where it fits, and where it does not

TypeSafe's own use-case map groups the good fits under five headings: AI automation software that runs a million times with no co-pilot; real-time applications where 150 ms is faster than human perception (its demo is a bot playing Doom from structured game state at ten queries a second, about $7 an hour); map-reduce over large corpora; universal verification of other models' inputs, outputs and tool calls; and harness engineering, meaning model routing, context selection and guardrails around an LLM.

The architectural pattern underneath all of them is the same and is worth stating on its own, because it is the actual product: code owns control flow; the model supplies narrow judgments. Instead of asking a model to "handle this ticket," you write the policy as a workflow. Each sentence becomes either a rule for the code or a typed question for the model. TypeSafe's evals page shows this with an expense-claim policy: "can the receipt be read" becomes a Noul, "what kind of expense" a Choice, "how clearly the description matches the receipt" a four-level Score, and "a meal over $75 that does not clearly match needs a manager" stays in code. The evals also report that every LLM they tested was more accurate, cheaper and faster run inside such a workflow than given the same policy as a prompt. The pattern is good advice regardless of whether you adopt Jev.

Where it does not fit is anything that needs the model to produce something: a reply, a summary, a refactor, a plan. It also does not fit judgments that require extended reasoning. TypeSafe's rule of thumb is that a good question is one a knowledgeable person could answer in a few seconds given the right context; "analyse this and decide the best course of action" is not one question but a workflow you have not written yet.

How to evaluate it in an afternoon

Because output tokens are free and a three-question call costs about $0.00001, the cheapest way to form an opinion is to run your own data through it.

1. Take one decision your system currently makes with a regex, a keyword list, or an LLM prompt that returns JSON. Routing, triage, moderation and relevance filtering are the natural first candidates.
2. Write it as typed questions. Give every Choice an other option. Put boundary cases into the criteria descriptions. Keep every number, date comparison and count in code.
3. Replay a few hundred historical cases through the Playground or the SDK, and store the full response, probabilities included, next to what your team actually did.
4. Measure agreement, then look at the low-confidence tail rather than a random sample. That is where the calibration claim is tested: if the model's doubtful answers are wrong more often than its confident ones, the confidence score is doing its job and you can set thresholds on it.
5. Pin the versioned model ID (jev-1.13.0) in production. The jev-latest alias moves on release, and thresholds tuned against one version are not guaranteed to hold on the next.

If you use a coding agent, TypeSafe ships a skill for Claude Code and other agents (claude plugin marketplace add typesafe-ai/skills) that carries the question types and patterns; the docs' own advice is to keep questions and thresholds in a single file so a human can review the only part that matters.

Our read

The unglamorous version of what TypeSafe has shipped is a very fast, very cheap, calibrated classifier with a clean API, from a team with the credentials to have built it properly. The glamorous version, a new class of model that makes intelligence composable the way databases made storage composable, is the manifesto ("We're building prod, not God"), and it will be decided by whether the calibration holds up on other people's data rather than TypeSafe's own four workflows.

Three things would change our assessment quickly: independent evals on a public decision dataset, evidence on how the model holds up under adversarial state in production, and pricing that survives past the early-access period (TypeSafe says it cannot yet prove the price is not subsidised, and expects it to go down rather than up). Until then, treat it as what the documentation describes rather than what the homepage implies: not a model that cannot be wrong, but the first one that reliably tells you when it might be.

Common questions