--- title: How does Jev by TypeSafe AI actually work? url: https://deepthinkingai.org/how-jev-works/ published: 2026-09-21 author: Shekhar Singh topic: Models & Benchmarks tags: classification, evaluation, cost, production site: DeepThinking AI --- # How does Jev by TypeSafe AI actually work? **Summary:** Jev posts state and a map of questions to one endpoint and returns typed answers carrying probabilities. TypeSafe claims 0% type errors, which is a guarantee about schema conformance rather than about correctness. A noul of 0.95 is a well-formed number that can still be wrong about the thing it scored. ## Key takeaways - Jev accepts a state blob plus a map of questions and answers all of them in a single parallel pass. - The documented guarantee is 0% type errors, which covers schema conformance and says nothing about whether an answer is correct. - Every answer carries a probability, so the calibration is the output rather than a diagnostic bolted on beside it. - TypeSafe reports 70ms to 500ms against 3 to 329 seconds for frontier models, measured on their own workflow evaluations. - Giving up string generation is the stated trade, and it is what makes the type guarantee possible at all. TypeSafe AI released [Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) on 15 September 2026, calling it a System One model. The short description in the launch post is a fair one: unstructured state in, typed probabilistic decisions out. Most of the coverage since has focused on the speed and price figures. The part worth reading closely is the shape of the call and the exact wording of the guarantee. ## What does a Jev request actually look like? One endpoint and three fields. A `POST` to [`/v1/systemone`](https://docs.typesafe.ai/api) carries `state`, `model` and `questions`, where `questions` is a map rather than a single item. The response mirrors it. You get back `model`, an `answers` map keyed by your question ids, and a `usage` object with input and output token counts. An answer for a yes or no question looks like `{"type": "noul", "noul": 0.95}`. **One Jev request, many questions** ```mermaid sequenceDiagram participant Yourservice as Your service participant Jev as Jev Yourservice->>Jev: POST /v1/systemone Jev->>Jev: Evaluate every question in parallel Jev-->>Yourservice: answers keyed by question id, plus usage Yourservice->>Yourservice: Read the probability, then decide ``` - POST /v1/systemone: Body carries state, model and a map of questions. - Evaluate every question in parallel: Adding questions barely moves latency. - Read the probability, then decide: The number is the output rather than a diagnostic. One round trip answers the whole question map. The state you send is also what you are billed on, since output tokens are free. The map is the design decision worth noticing. Questions in one request are evaluated in parallel, and LangChain's [harness write-up](https://www.langchain.com/blog/building-a-harness-with-jev) reports that adding questions barely changes the response time. Combined with input-only billing, that pushes you toward sending state once and asking everything about it at the same moment. ## What does the type guarantee actually cover? Schema conformance. TypeSafe reports **0% type errors**, and the surrounding claim in the launch post is that existing models still produce type errors regardless of capability. That is a real guarantee and a narrow one. It says the response will match the shape you asked for and that a choice will be one of the options you defined. It says nothing about whether the option picked was the right one. **What the type guarantee covers** 1. Response matches the requested schema TypeSafe reports 0% type errors. 2. Answer is one of the options you defined Choice caps at 255 options. 3. A probability accompanies every answer Noul carries it directly. --- guaranteed above, earned below --- 4. The chosen option is the correct one Nothing in the design decides this. 5. The probability is well calibrated for you Verify on your own labelled set. 6. Arithmetic, counting and dates are right Documented as unreliable. Everything above the line is structural and holds by construction. Everything below it is an empirical question about your data that you still have to answer. The distinction matters because a lot of the secondary coverage has compressed this into a claim that Jev cannot hallucinate. A noul of 0.95 on a wrong proposition is a perfectly well-typed answer. The failure mode moves from malformed output, which your parser catches, to confident wrong output, which only an evaluation set catches. ## Why does giving up text make this possible? Because the guarantee is a property of the output space. TypeSafe states the trade plainly: Jev gives up string generation in exchange for structured output. A model that emits free text has an output space of every token sequence, and any schema you impose on it is a filter applied to that space afterwards. A model whose output space is a distribution over 255 named options cannot produce something outside the set, because there is nothing outside the set to produce. This is also why the probability is the interesting artefact rather than a by-product. When the answer is a choice among known options, the distribution over those options is the natural thing to return, and it arrives without the [log-probability archaeology](/long-context-vs-retrieval/) you would otherwise do to recover it from a text model. ## Should you trust the probability? Not until you have checked it on your own data. Calibration is a claim about a distribution. A model well calibrated on the vendor's evaluation workloads can be poorly calibrated on yours, and the only way to know is to bucket your predictions by reported probability and measure how often each bucket is right. This is cheap to do and almost never done. If 0.9 turns out to mean 0.6 on your traffic, every routing threshold built on that number is quietly wrong, and nothing in the response will tell you. TypeSafe's own numbers are worth reading with their scope attached. The 70ms to 500ms latency band is reported against 3 to 329 seconds for frontier models, and the launch post notes the workflow evaluations represent the higher end of real world gains, with smaller advantages against non-reasoning modes. ## Where does this actually fit? My read is that Jev is best understood as a decision primitive rather than a model you converse with, and that the framing in LangChain's write-up is the right one: an LLM for open-ended work, Jev for the structured decisions taken along the way. The cases where that pays are narrow and real. High-volume, repeated decisions over a shared state, where the answer set is known in advance and the [per-request cost](/prompt-caching-economics/) is the thing you are fighting. Routing, gating and scoring all fit. Anything needing a sentence back does not. What I would not do is treat the type guarantee as a correctness guarantee. It removes a class of parsing failure, which is genuinely useful, and it relocates the remaining risk somewhere your tests have to look for it. ## Make your first Jev call and read the answer properly The API is small enough to learn in one sitting. The part worth slowing down on is what the returned numbers mean, because two of the three answer types report confidence and one deliberately does not. 1. **Send state and questions as separate things**: The request body carries state, model and a questions map. State is the material being judged. The question belongs in the question object rather than glued onto the state, and keeping that separation is what lets you ask many things about one payload in a single call. 2. **Batch every question you need about that state**: Questions are evaluated in parallel, so a second and third question cost far less than a second and third request. If a request already carries the state, ask everything you will want to know about it now. 3. **Read noul as a probability rather than a verdict**: A noul answer returns a number between 0 and 1 and carries no confidence field, because the probability already describes the uncertainty. Pick your own threshold and record it. The default of 0.5 in the Pydantic integration is a convention rather than a finding. 4. **Read choice and score confidence as spread rather than accuracy**: Both carry a confidence derived from the probability distribution, which describes how concentrated the answer was. A confident answer is one the model was not torn about, which leaves open whether it was right. 5. **Verify calibration on your own labelled data before trusting the number**: Bucket predictions by reported probability and check how often each bucket is actually correct. Calibration that holds on the vendor's evaluations may not hold on your distribution, and this is the one check that turns the probability into something you can route on. 6. **Keep arithmetic, counting and date logic out of the questions**: All three are documented as unreliable. Compute them in your own code and pass the result in as part of the state, which is cheaper and exact. ## Frequently asked questions ### Does Jev hallucinate? TypeSafe's own claim is narrower than the headlines around it. The documented figure is 0% type errors, which means the response always conforms to the schema you asked for. Whether the value inside that schema is right is a separate question, and nothing in the architecture answers it. A confidently wrong choice is well-typed. ### How is this different from constrained decoding on an LLM? Constrained decoding forces a language model's token stream to satisfy a grammar, so you get a valid shape out of a model that is still generating text. Jev is built to emit the decision directly, which is why it reports a probability distribution over the option set rather than a sampled string that happened to parse. ### What does it cost to add more questions? Very little in latency. Questions in one request are evaluated in parallel, and LangChain's write-up reports that adding questions barely changes response time. Pricing is charged on input tokens at $0.042 per million with output tokens free, so the state you send dominates the bill. ### What can Jev not do? Arithmetic, counting and date reasoning are documented as unreliable. It takes no images, audio, video or documents, does not stream, and rejects unsupported argument types such as strings, unbounded numbers, datetimes and dicts. It answers in one piece. ### Is this a replacement for an LLM? No, and TypeSafe does not present it as one. The model gives up string generation entirely. The pattern in the launch material and in LangChain's harness write-up is an LLM for open-ended reasoning with Jev handling the structured decisions along the way. ## Sources - [Introducing System One Models and Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev). TypeSafe AI, 2026-09-15 - [API reference](https://docs.typesafe.ai/api). TypeSafe AI - [TypeSafe (Jev) model integration](https://pydantic.dev/docs/ai/models/typesafe/). Pydantic - [Building a harness with Jev](https://www.langchain.com/blog/building-a-harness-with-jev). LangChain --- Canonical HTML: https://deepthinkingai.org/how-jev-works/