Jev is TypeSafe’s flagship model, and the first model in their System One line: built to answer questions that code, not a person, has to act on. That distinction is worth sitting with before looking at the request shape.
What Jev returns
Most large language models are built to write text a person reads next. Left to generate free-form prose, one asked to classify a ticket hands back a paragraph you then have to parse, hoping the format holds up call after call. TypeSafe’s own introduction names the underlying mismatch: you are coercing a system built to generate text into producing a structured decision.
Jev skips that step. You send it a state, the material to evaluate, and one or more typed questions, and it hands back typed answers your code can use immediately. There are three question types. Choice picks one option from a set you define and returns that option plus the full probability distribution across every option. Score rates the state against an ordered rubric and returns a probability-weighted position on that scale. Noul answers a yes-or-no question with a single probability, from 0 (no) to 1 (yes). Choice and Score also carry a confidence value, a single number summarizing how concentrated the probability is. Noul does not; there is nothing left to summarize beyond the number itself.
Say you are triaging a message like “My export has failed three times today and I cannot send the report.” A Noul question asking whether this needs immediate attention might come back at 0.91. That is a number your code can branch on directly. No regex, no asking the model to “please respond only in JSON.”
Where it fits in an application
The request itself is one HTTP call, POST https://api.typesafe.ai/v1/systemone, with model, state, and a map of questions in the body, authenticated with a bearer key kept on your server. Every question in that map runs against the same state, in parallel, without seeing each other’s answers. That is a deliberate design choice: each judgment stays isolated, so a bad answer to one question does not quietly poison another. Mix a Choice, a Score, and two Nouls in one call and you get four independent answers back, keyed by whatever IDs you chose (Jev never sees the IDs, only the instructions attached to each question).
That shape maps neatly onto a classification-and-routing layer sitting in front of your real logic. A support inbox is the obvious example: one call can decide which team a ticket belongs to, whether it is urgent, and how disruptive it is to the customer, and your code routes from there, deterministic logic for the easy branches, a specialist model or a person for the rest. I walk through exactly that example in the next article.
Typed answers can still be wrong
Here is the part that is easy to skip past: a typed answer is not a correct answer. Constraining the output format does not constrain the judgment behind it. Confidence tells you how concentrated the model’s probability mass is. It says nothing about whether the model actually got your case right.
Two specific traps are worth knowing before building anything. First, Score is not a 0-to-1 scale by default. It runs 0 to n minus 1, where n is however many levels you defined, so three levels means 0 to 2. Divide by n minus 1 yourself if you want a normalized fraction; the API will not do it for you. Second, the model behind your call is a specific pinned version. On 21 September 2026, that version is jev-1.13.0, and the jev-latest and jev-preview aliases both point to it, but aliases move when a new release ships, and thresholds tuned against one version are not guaranteed to transfer to the next. TypeSafe’s own list of known limits, what they call jaggedness, calls out literal reading, weak arithmetic and counting, unreliable date comparison, and sensitivity to adversarial or contradictory instructions. None of that shows up in the response schema. It shows up when you test with real, messy input.
What I would try first
If I were wiring this into something today, I would start with one narrow judgment instead of a five-question kitchen sink, and keep anything resembling arithmetic in my own code rather than asking Jev to compute it. I would pin the model version explicitly instead of trusting an alias, log which version actually answered each call, and write down, honestly, what “tested” means for my integration before calling it done. Offline against fixtures is a real and useful status. It is a different status from validated against the live model on real traffic.
Confidence is the tool for deciding what happens next. It is not a guarantee of correctness. The next two articles work through that in code: a support-triage example gated on confidence and probability thresholds, then a plan for measuring whether the thresholds you picked actually hold up.