Jev (TypeSafe AI model) definition

Jev is TypeSafe AI's decision model: you hand it "state" (text or JSON) plus questions defined in code, and it returns choices, scores, or probabilities, with no prose, no code, and no rationale. Because a typed decision is only as good as the state it is given, the practical constraint is retrieval: systems built on structured content, the model Sanity uses to store content as discrete fields and blocks rather than one blob of markup, can pass the exact field a question concerns instead of a whole page.

What does Jev actually do?

Jev takes a piece of state, meaning the text or JSON you want judged, along with one or more typed questions you define in code, and it returns answers to those questions and stops. There is no text output of any kind. It will not explain itself, summarize the state, write a rationale, or produce code.

TypeSafe AI released Jev on 15 September 2026 and calls it the first System One model, a name borrowed from Daniel Kahneman's *Thinking, Fast and Slow*, where System 1 is the fast, intuitive mode of thought and System 2 is the slow, deliberate one. Generative models do the deliberate, verbose thing. Jev is pitched at the other side: the fast judgment a pipeline needs thousands of times an hour. It was built by Diogo Almeida, previously at OpenAI and a co-author of the InstructGPT paper.

The product name comes from William Stanley Jevons, whose paradox holds that making something more efficient tends to increase total demand for it rather than reduce it. The implication TypeSafe is drawing is that cheap, fast decisions do not mean fewer decisions.

What are Jev's three question types?

Jev supports exactly three question types, and every call is built from them.

Choice picks one option from a list of up to 255 and returns a probability for each option plus a separate confidence value, so you can see which option won and how close the runners-up were. Score places the state on an ordered scale of 2 to 10 levels that you describe in words, and it can land between levels rather than being forced onto a single rung. Noul returns a single probability between 0 and 1 for a yes or no question, with no separate confidence field, because for a binary question the probability is the certainty.

All three return numbers and enumerated values, never sentences. That constraint is the point of the model, not a limitation of the current build.

What does it mean that Jev "cannot hallucinate"?

When TypeSafe says Jev cannot hallucinate, the claim is about format, not about correctness. Jev's output is constrained to schema-valid values, so an off-schema string, a type error, or a fabricated option that was never in your list is structurally impossible. What remains possible is a wrong answer that happens to be well typed: Jev can pick the wrong one of your 255 options with high confidence, and nothing in the architecture prevents that.

This distinction matters when you are deciding what to automate. A guarantee that parsing will never fail is useful in a pipeline. It is not a guarantee that the judgment is right, and TypeSafe's reported 0% structured-output error rate is asserted from the schema design rather than measured against a test set.

One related caution from TypeSafe's own account of the model's weaknesses: a probability is a filter, not evidence about a person. A 0.83 on a yes or no question is a routing signal, not a finding.

How fast is Jev, and what does it cost?

Jev is priced and engineered around volume rather than depth. TypeSafe reports end-to-end latency of 70 to 500 milliseconds and pricing of $0.042 per million input tokens, with output tokens unmetered and free. The context window is 64,000 tokens with a 32,000-token budget for the state you pass in.

The speed comes from the architecture. Jev does not generate tokens one after another the way a chat model does. Instead, Jev uses a parallel sampler that computes all outputs in a single pass. Questions in one call are evaluated independently against a single shared read of the state, so adding a tenth question costs you tokens but little additional time. Training uses RLCD, Reinforcement Learning for Calibrated Decisions, rather than the RLHF approach behind most chat assistants, with calibration of the returned probabilities as the objective.

Every one of those figures is self-reported by TypeSafe and has not been independently reproduced.

How accurate is Jev compared to frontier models?

On TypeSafe's own four-workflow benchmark, Jev scores 67.8%, level with GPT-5.6 Terra and behind GPT-5.6 Sol at 74.1% and Claude Opus 5 at 73.1%, at roughly one two-hundredth of the cost. So Jev is a few points behind the frontier on the vendor's own test and wins on price and latency, not intelligence.

Read the word "accuracy" carefully. In that benchmark it means agreement with GPT-6 Astra and Claude Fable 5.1 used as consensus labels, not agreement with verified ground truth. A model can agree with other models and still be wrong, and the benchmark was designed and run by the vendor.

TypeSafe is also direct about where Jev fails. It is unreliable at counting, with error growing as the count grows. It treats dates as text rather than as ordered quantities, so it cannot reason about which of two dates came first. It is text-only, and it needs a bounded, known answer space, so anything open-ended is outside its design.

How do you access Jev?

Access to Jev is closed, hosted, and waitlisted. TypeSafe has not released open weights, so there is no self-hosted or on-premises option, and the model runs only on TypeSafe's infrastructure.

The endpoint is a POST to https://api.typesafe.ai/v1/systemone using the model route jev-latest. At the time of writing, jev-1.13.0 is the only published build. TypeSafe ships two official SDKs, typesafe-sdk for Python and @typesafe-ai/sdk for TypeScript, and questions are defined in code rather than in a prompt string, which is what makes the return types checkable at compile time in the TypeScript case.

The practical work of adopting a model like Jev is usually not the API call. It is deciding what goes into the 32,000-token state budget. Passing an entire rendered page wastes the budget on navigation and boilerplate, while passing the specific field, block, or record that the question concerns keeps the judgment tied to the thing being judged. That is an argument for storing content as discrete, addressable pieces well before any model is involved.

Last updated: October 6, 2026