Choice

They can. The page says option names and descriptions are both sent to the model, and its example shows an ambiguous ticket reading returns at 0.61 against billing at 0.35 with confidence 0.42 — use null when a name speaks for itself.

Yes. The page says they run in parallel and response time barely changes, so a fan-out of questions is cheaper than separate calls. For deep hierarchies, chain choices level by level as the hierarchical classification cookbook shows.

Use Choice when the answer is one of a fixed set of options, such as which team handles a ticket, which category a product belongs to, or which language a snippet is written in. If the answer is a position on a spectrum, use a Score, and if it is a yes or no, use a Noul. The docs carry a separate page that compares all three question types.

The POST body has three top-level fields: state, the content to evaluate; model; and questions, a map from ids you choose to question objects. Each Choice question sets type to choice, instructions to the question, and criteria to a map whose keys are option names and whose values are descriptions. Use the system_one method or the https://api.typesafe.ai/v1/systemone endpoint to call a System One model.

One entry per question under the ids you sent. Each has type, choice holding the option with the highest probability, probabilities holding the full distribution across every option which sums to 1, and a confidence value from 0 to 1. The worked example returns model jev-1.13.0 with department set to returns at confidence 1.0, probabilities of shipping 0.0, returns 1.0 and billing 0.0, and usage of 328 input and 34 output tokens.

Confidence is computed from how the probabilities are spread: a flat shape across several options means low confidence, a single peak means high. The easy wrong-size ticket puts all mass on returns at 1.0, while a ticket mentioning both a wrong size and a missing refund splits probability and drops confidence. A Choice accepts up to 255 options and each option costs a few tokens, so send the full list rather than a shortlist, and include an other or none of the above option for inputs the list may not cover.

For a flat set, send everything in one request. For deep hierarchies the guidance flips: chain choices level by level, as the hierarchical classification cookbook shows, so each level's candidate set is decided once the level above it is known rather than enumerating the cross product of options up front. The tradeoff is latency across sequential calls against a much smaller criteria block per call.