Classify is in Beta, and its request and response contract matches the TypeSafe Classify API.
- Answers natively on
typesafe/jev-latest, and through structured outputs on a set of small chat models: see Supported models. - Does not apply PII plugins, guardrails, or evaluators yet: see Enforcement during the Beta.
- Requires an API key with the
classifypermission.
Overview
Classify answers typed questions about a piece of content in one call. Send the content asstate and one or more named questions to POST /classify on the AI Gateway base URL, https://my.orq.ai/v3/router.
The response returns one structured answer per question, so nothing has to be parsed out of free-form text. A choice or score answer also carries the probabilities behind it and a confidence for the selected option or level.
A question pairs plain-language instructions with a type that fixes the answer shape, and criteria that define the rubric:
state is not limited to text: an object or array is serialized as JSON before classification, so the same call can judge a customer message, a tool payload, or a whole record.
Several questions can be asked at once, each with its own rubric, so a request costs one round trip instead of one call per question. See Question types for the criteria each type expects.
The request is traced, priced, and rate-limited like other gateway traffic. See Enforcement during the Beta for what applies today.
Use cases
- Triage and routing. Ask
noulwhether the message reports a problem andchoicefor the topic or product, then route on the labels and escalate the rows whose confidence is low. - Building labelled data. Turn a rubric into a
choicequestion to label a corpus for Evaluators or Datasets, and useprobabilitiesto pick the rows worth human review. - Scoring open feedback. Use
scoreon survey answers, support transcripts, or review text to get an ordinal reading without writing a scoring prompt. - Gating expensive work. Use a
noulquestion on the native model, whose output tokens are free, as a pre-check, and send only the requests that pass on to a larger model. - Enriching structured records. Pass a record as
stateand ask one question per field to derive, instead of building a prompt per field. - Comparing models on one rubric. Ask the same questions against
typesafe/jev-latestand a chat model to see where they disagree. Thresholds tuned on one do not transfer, so compare answers rather than raw probabilities.
Supported models
The table lists model families. Every offering of these models, including regional and reseller variants, is in Supported models.
Chat models return the same fields with their own probabilities, which express the model’s estimate and are not calibrated, so thresholds tuned on one model do not transfer to another.
Reasoning is set to the minimum the model allows.
Any other model returns
400.
Quick start
Request
Each question has a
type and instructions, which can be a string, object, or array. The shape of criteria depends on the question type.
Question types
noul
Returns the probability that the statement in instructions is true for state. The probability is calibrated on typesafe/jev-latest and model-reported on chat models.
The optional criteria object can define what counts as true and false.
JSON
choice
Selects one option from a rubric. The required criteria object maps each option name to a description. Set a description to null when the option name is enough for the model to interpret it.
JSON
score
Returns a position on an ordered scale. Set criteria to an array with at least two level descriptions, ordered from lowest to highest. The answer index refers to this array.
JSON
Response
Two paths produceconfidence and score, and the numbers mean different things on each: typesafe/jev-latest answers natively, and a chat model answers through one structured-output call. Every field below states both.
JSON
The SDK response models for this endpoint expose
model, answers, and usage, so a caller that needs the trace identifiers reads the x-orq-trace-id and x-orq-trace-span-id response headers. The handler sets those once the request is traced, so a request rejected before that point carries neither: authentication and authorization (401, and 403 for a missing classify permission or a model that is not enabled for the workspace or shared with the project), plan and budget limits (429), and request-body validation (the 400 for a malformed body, the 422 for an invalid request). Everything rejected after tracing carries them, including the 400 for a model that does not support classify. The telemetry object itself is optional and returned by builds newer than some deployments run, so fall back to the headers when it is absent.
Chat models return the same fields, so parsing code does not change with the model, but the numbers do not mean the same thing: their probabilities are the model’s own estimates and are not calibrated, and their confidence is simply the largest of them. Compare choice and score across models, not confidence.
See the Create Classify API reference for the full request and response schema, including the fields accepted alongside the ones above.
Enforcement during the Beta
Enforced on every request:
Not applied during the Beta:
- PII plugins.
stateandinstructionsreach the provider exactly as sent, even when a redaction plugin is configured for traffic that would otherwise match. - Guardrails and evaluators. They do not run, so a matching guardrail rule cannot block a Classify request.
- Routing rules. A rule does not rewrite the model, add fallbacks, or serve from cache.
- Request-level
fallbacks,load_balancer,timeout,cache,plugins, andguardrails. They are not part of this contract. Unknown body fields are ignored rather than rejected, so sending them has no effect and returns no error.