Overview
POST /v1/decisions serves TypeSafe’s Jev model, a System One model. Unlike the Responses or Chat Completions APIs, it doesn’t generate text. You send it your application’s state and a map of typed questions, and it returns a calibrated probability for each one.
Use this when your code needs a number it can branch on, such as “how likely is this support ticket to be a bug report” or “which of these three categories does this transaction belong to,” rather than a paragraph it has to parse.
The request and response shapes are identical to TypeSafe’s System One API and OpenRouter’s Decisions API, so a client written against either works here by pointing it at
/v1/decisions. Fields this endpoint doesn’t implement, including OpenRouter’s routing, are ignored rather than rejected: Jev is the only model behind the endpoint, so there’s nothing to route between.Request
string
required
The model to use. See Model and aliases.
string | object | array
required
The application state the questions are judged against. Accepts a plain string, a JSON object, or a JSON array.
object
required
A map of caller-chosen question ids to question objects. Must contain at least one question. Each question has a
type of noul, choice, or score, plus instructions and (depending on type) criteria. Both instructions and criteria accept structured JSON, not only strings: a string, an object, or an array, with any JSON values inside that object or array.Question types
noul
A yes/no judgment. Returns a probability between 0 and 1 that the answer is yes. criteria is optional, and may carry true and false descriptions to sharpen the judgment.
choice
Selects one option from a required map of option name to description. Returns the chosen option, a probability distribution over all options, and a confidence value.
A description can be null when the option name is self-explanatory and needs no further explanation, for example { "shipping": null, "technical": null, "other": null }.
score
A position on ordered levels, described by a required array of one to ten level descriptions, ordered from lowest to highest. Two or more is what makes the position meaningful. Returns a probability-weighted value, the levels as a legend, a distribution, and a confidence value.
Response
id identifies the request; it’s the Response ID the logs page shows, so quote it when you contact support. answers is keyed by the same question ids you sent in the request. model is returned in canonical provider/model form, for example typesafe/jev-1.13.0. usage.output_tokens is the count TypeSafe reports; output tokens aren’t charged.
Each answer’s shape depends on its type, which matches the question that produced it:
noul—{ "type": "noul", "noul": 0.87 }. The singlenoulfield is the probability of yes. There’s noconfidencefield, because the probability is the answer.choice—{ "type": "choice", "choice": "shipping", "confidence": 0.91, "probabilities": { "shipping": 0.91, "technical": 0.06, "account": 0.03 } }.confidenceandprobabilitiesare both optional.score—{ "type": "score", "score": 2.4, "confidence": 0.78, "probabilities": { "Low": 0.05, "Medium": 0.2, "High": 0.75 }, "legend": { "Low": "Low: no action needed soon", "Medium": "Medium: should be addressed within a few days", "High": "High: needs a response today" } }.confidence,probabilitiesandlegendare all optional.legendmaps each level back to the description you supplied, so you can render the answer without holding onto the original request.
choice and score answers, confidence summarizes how concentrated the probability distribution is. It isn’t a statement that the chosen answer is correct: several genuinely acceptable options will spread probability across them and lower confidence even when the model is judging soundly.
Fields that TypeSafe returns beyond what’s documented here are forwarded to you rather than stripped. If you’re writing a strict client-side schema, allow for unknown fields on the response and on individual answers.
Redaction, ZDR and HIPAA
Keys with redaction enabled can’t use this endpoint: the request is refused with a400 before anything is sent upstream. Redaction runs on chat bodies, and a Decisions request has no chat body, so accepting it would send your state to TypeSafe unredacted. Use a key without redaction enabled for Decisions traffic.
TypeSafe offers neither zero data retention nor a Business Associate Agreement, so keys with ZDR or HIPAA mode enabled are refused with a 422, exactly as the chat endpoints refuse a provider that can’t meet the policy.
Model and aliases
The current model isjev-1.13.0. The following aliases resolve to it:
jev-latestjev-previewjevjev-1.13(the slug OpenRouter publishes astypesafe/jev-1.13)
provider/ prefix is accepted: typesafe/jev-1.13.0 and typesafe/jev-1.13 both work. A prefix that isn’t a provider of the model, such as openai/jev-1.13.0, is a 400.
Aliases move when TypeSafe ships a new release, so the answers behind
jev-latest can change without a change on your side. The response’s model field reports the versioned ID that answered. If you’ve tuned confidence thresholds against a version, pin its ID (jev-1.13.0) and move on your own schedule.Limits
Decisions requests share your key’s token rate-limit windows with every other endpoint. During the beta there’s no per-request limit beyond that, but all Concentrate traffic to TypeSafe shares one account limit of 1,200 requests per minute; if you plan a sustained high-volume workload, contact us first.
Errors
See Error Handling for the general error response format.
Related Documentation
Writing questions
TypeSafe’s guide to state, instructions and criteria
Jev 1.13 jaggedness
Known failure modes and what to do instead
Create Response
Generate text with the Responses API
Error Handling
Understand error responses across the API

