openrouter-decisions
OpenRouter Decisions
A decision model reads application state and answers typed questions with probabilities, never text. The model judges, code computes. Code owns the workflow and every deterministic step, and the model fills in the judgments code cannot make. It is not a chat model, a coding agent, or a replacement for the LLM that drives one.
Every decision model on OpenRouter speaks the same Decisions API and the same three primitives, evaluated independently and in parallel within one request.
| Need | Primitive | Returns |
|---|---|---|
| One option from a defined set | choice |
choice, probabilities per option, confidence |
| Whether a condition holds | noul |
noul, the probability of yes |
| Degree along ordered levels | score |
score (probability-weighted position), probabilities per level, confidence |
Read references/decisions-api.md when writing a request or reading a response. Read references/models.md when picking between the decision models the live catalog returns. Read references/decision-model-limits.md whenever a question involves quantities, dates, negation, indirection, or untrusted text, since those are the things a decision model does not do.
Steps
-
Find the decision points. Read the code path and list every place that turns unstructured input into a bounded outcome. The usual forms: a chat-completion call parsed into a label, boolean, or number, a keyword, regex, token-overlap, or embedding-similarity heuristic standing in for a judgment, a retrieval step whose similarity threshold decides whether the top result is relevant (retrieval stays in code, relevance is the judgment), an if-chain over free text, a human review queue that mostly confirms the obvious, and a step that picks or reranks candidates. A spot fits when the answer is bounded, needs judgment rather than computation, and a probability would let code act, defer, or escalate. It does not fit when the step must produce text, values, or code, or when the answer is already in a field code can read. Done when each candidate has a one-line description of the judgment and the action code takes on the answer.
-
Split judgment from computation. Arithmetic, counting, date ordering, string and pattern matching, lookups, and threshold comparisons stay in code, and a value code already holds is never re-asked of the model. When code-side facts settle the action for an input (a path rule, a hard policy, an amount over a cap, an empty input), code returns that action and skips the model for that input. When code parses a value out of free text before comparing it, write the parser against the formats in real inputs and treat a parse miss as its own outcome. Generation goes to a generative model, and a decision model can then pick among its candidates. Done when every remaining item is a judgment that fits one primitive.