Skip to main content
Beta FeatureThe Decisions API is currently in beta.

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 single noul field is the probability of yes. There’s no confidence field, because the probability is the answer.
  • choice — { "type": "choice", "choice": "shipping", "confidence": 0.91, "probabilities": { "shipping": 0.91, "technical": 0.06, "account": 0.03 } }. confidence and probabilities are 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, probabilities and legend are all optional. legend maps each level back to the description you supplied, so you can render the answer without holding onto the original request.
On 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 a 400 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 is jev-1.13.0. The following aliases resolve to it:
  • jev-latest
  • jev-preview
  • jev
  • jev-1.13 (the slug OpenRouter publishes as typesafe/jev-1.13)
A 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.

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
Last modified on September 29, 2026