OpenRouter added GPT-6 Luna Decisions on October 8, extending access to OpenAI's new interface for classification, scoring and action selection. OpenAI had introduced the underlying Decisions API in public beta two days earlier. The listing widens distribution, not the evidence that its probability outputs are calibrated well enough to control a production system.
OpenAI says Decisions can answer decision questions up to ten times faster than GPT-6 Luna through the Responses API. That is a vendor comparison between two access patterns in the same model family, not an independently established advantage over all classifiers, rules engines or workloads. A clean typed answer is easier to parse; it is not automatically a correct judgment or permission to execute an action.
What is being distributed
OpenRouter's listing identifies OpenAI as the provider. This is not a separately trained OpenRouter model: OpenAI still supplies the inference. Existing OpenRouter users gain another endpoint alongside their model portfolio, with potentially simpler procurement, accounting and experimentation. They still need to verify the supported request shape, error behavior, regional availability, observability and parity with OpenAI's direct service.
The direct Decisions interface uses a dedicated endpoint rather than Responses, with GPT-6 Luna the only supported model during the reported public beta. It accepts evidence and constrained questions rather than asking for an open-ended paragraph. A predicate estimates whether a condition is true; a choice selects from developer-specified options; a score evaluates an input against ordered rubric levels.
Inputs can be text or a message combining text and an inline image; JSON describing application state can be supplied as text. Outputs have named answers, allowing several independent questions to assess the same evidence in one request. The endpoint can classify a document before indexing, select a model or flag a case for escalation. It does not independently carry out the selected action.
These boundaries distinguish it from related interfaces. OpenAI recommends Structured Outputs through Responses for custom JSON objects and function calling when a model should propose a tool with arguments. General Responses remains suitable for open-ended content, explanations, extraction and broader tool workflows. Decisions narrows the contract when an observable predicate, known option list or meaningful ordered rubric actually fits the task.
Why a narrow decision can change the critical path
A support application may need only billing, technical support, shipping or another department, not a generated explanation. A moderation system can ask whether an image violates policy, while sales qualification can apply a rubric. In modular applications, moderation, intent, retrieval, model selection, tool selection and output checking may each require a decision without a written response.
The same mechanism could choose web search, internal retrieval, code execution or a stronger reasoning model, or exclude irrelevant documents before they consume context. OpenAI's voice-delegation example selects an action from current application state before another component reports its result. Visual examples include product-photo damage, media flagged for review and image classification before document extraction. These are possible workflows, not published cross-domain accuracy results.
Constraining outputs can reduce unnecessary generation and parsing work. It also means the developer must supply useful boundaries: actual departments, approved actions, observable conditions and scoring levels with operational meaning. Fixed choices can prevent invented tool names, but cannot establish that the chosen tool is appropriate or authorized.
The “up to ten times” claim describes a best case, not a guaranteed multiplier. Input length, image size, number of questions, network location and provider routing affect latency. OpenRouter adds a service boundary of its own. A router must be cheaper and faster than the work it avoids; sending everything through an extra decision hop can otherwise erase the benefit.
That hop creates an availability dependency too. Developers may call OpenRouter for a model that selects the model receiving the next call; if the decision service fails, downstream work may never start. A deterministic rule, default model or direct-provider path can provide a fallback. Exact file extensions, account entitlements and regional restrictions usually belong in ordinary code; probabilistic judgment is more useful for ambiguity than for replacing exact policy.
A probability needs an interpretation and a test
Typed output does not make a judgment deterministic or a probability calibrated. A number might reflect real-world frequency, relative preference among options or confidence under a particular prompt. Teams cannot safely assume these meanings coincide. Calibration requires checking whether similar predicted confidence corresponds to comparable observed accuracy.
Early community discussion illustrates questions, not settled performance rankings. One participant reported a competing decision model doing better on several hundred game-related tests while explicitly warning that the sample was narrow, not a general benchmark. Another reported different predicate and choice behavior in a synthetic loaded-coin test, with choice probability more concentrated than expected. Neither anecdote establishes a formal, broadly applicable evaluation.
Error costs also differ by task. In moderation, false positives and false negatives carry different consequences, and calibration may shift across languages, image categories or policy changes. In routing, sending complex work to a cheap model can lower quality; sending every easy request to a large model can destroy savings. Thresholds must reflect downstream outcomes, not router accuracy alone.
Rare urgent support cases can be lost inside an impressive aggregate accuracy score. Evaluations should separately cover predicate, choice and score, confidence ranges, important subgroups, latency distributions and the cost of wrong actions. Inputs outside the provided options need an abstention strategy. Adding “other” is possible, but its actual use must be tested rather than assumed reliable.
Choosing an action is not authorizing it
A result such as “search internal knowledge” rather than “send email” can form one element of an application's control plane. Separate code must still verify identity, permissions, user consent, business policy and confirmation requirements before a tool runs. A confident classification does not supply any of those authorizations, especially for actions with external consequences.
Recording input state, allowed choices, returned probabilities, thresholds and final actions helps distinguish a model error from a threshold or execution-layer error. Responses can support similar logging, but a narrower interface encourages isolating one choice and testing it independently when a workflow changes. This is an architectural distinction, not a contest between OpenAI and its distributor.
Input, billing and data-path limits remain material
The reported Decisions documentation describes input-only billing, but the initial release did not advertise cached-input treatment. That is an unresolved design consideration, not a claim that caching can never be added. Repeatedly sending the same long policy, catalog or application state can accumulate token and transfer overhead even when a single call looks efficient.
Batching independent questions against shared evidence reduces repeated inputs. It does not support a later question depending on an earlier answer inside that same batch. A sequence that first detects damage and then classifies its type needs separate calls, adding latency and another place for uncertainty to propagate.
The documented image path requires inline base64 data URLs, not hosted image links or existing file identifiers. Media-library integrations must account for payload size and transfer. OpenRouter users need to determine which limitations and capabilities carry through unchanged; request limits, error codes, retries and observability depend on exact endpoint behavior rather than a marketplace summary.
OpenAI says the direct endpoint supports eligible Zero Data Retention and regulated-healthcare configurations, and its data-controls documentation describes supported processing and residency regions. These are conditional capabilities. An OpenRouter integration adds an intermediary and a different data path: its logging, provider routing and applicable contractual controls require separate confirmation. Underlying model eligibility does not automatically extend to every intermediary.
A marketplace category still has to earn production use
A common account and interface lowers switching friction, but comparable decision-model metadata remains limited. Coding or reasoning benchmarks do not substitute for calibration, abstention, latency and consequence-weighted error tests. OpenRouter could eventually add decision-focused telemetry, evaluations or fallback comparisons; those are potential developments, not capabilities established by the listing.
Provider substitution also needs more than normalized syntax. Confidence, rubric scores and refusal behavior can differ semantically, requiring a stable internal contract and provider-specific validation. Other labs, small models and open-weight systems can compete on speed, calibration or local control. A trained conventional classifier may outperform a language model on a stable, well-labeled task, while rules remain appropriate for exact logic.
Decisions occupies the space of zero-shot or prompt-defined judgment without a separate training pipeline, particularly where categories change or language and images mix. Its convenience may shrink as a mature task accumulates labels and a dedicated classifier offers predictable latency and lower complexity. OpenAI offers control of the model, native endpoint, SDKs and enterprise data options; OpenRouter offers consolidated access and model choice. Neither distribution route eliminates evaluation.
Three developments would clarify durability: independent task-specific results; retained production workloads with stable availability and consistent requests after teams account for mistakes and operations; and changes before general availability. More supported models, caching improvements, image handling, SDK behavior and calibration guidance remain worth watching. A rapid beta progression was a company expectation, not a promised release date; early playground field/request-shape mismatches were community feedback, not proof that every integration fails.
Interfaces, quotas and behavior can change during beta. A reversible deployment alongside the existing router can compare the same labeled traffic against Responses, simple rules and existing classifiers. Records of probability, threshold, outcome and downstream cost should separate false positives from false negatives and include adversarial, ambiguous and out-of-distribution cases; examples and policy history can be kept with evaluation results.
Medium-confidence cases may go to a larger model or a human, while high-risk actions retain explicit authorization even when confidence is high. If specialized endpoints reliably improve both decisions and end-to-end cost, more modular stacks may follow; weak calibration or observability could instead favor structured Responses, established classifiers or rules. OpenRouter makes the experiment easier to run. It does not decide its outcome.
Sources and related reading
OpenRouter announcement · Model listing · Decisions interface documentation · Public-beta notice and discussion · Voice delegation guide · Data controls · Related reading: personal and team knowledge bases