Summary
OpenAI made its Decisions API generally available on October 22, 2026, for bounded tasks such as classification, routing and selecting a next action. Developers specify questions and permitted answers; the API returns probabilities, fixed choices with probabilities and confidence, or rubric scores, with up to 400 questions per request. OpenAI says it can be up to 10x faster than GPT-6 Luna through the Responses API, but provides no independent benchmark or general performance guarantee.
What happened
The API accepts text, images or native JSON and is designed for decisions with a defined answer space rather than open-ended conversation. Its outputs include predicate probabilities, selections from supplied values with probabilities and confidence, and scores against ordered rubric levels. The release also adds native GPT-Live integration and inference residency in the US and EU. In GPT-Live, an application can delegate a decision or trigger one as transcript deltas arrive. That documents an integration path, not proof of real-time performance: the supplied documentation does not establish latency, implementation limits or production results. OpenAI’s speed claim compares Decisions with using GPT-6 Luna through the Responses API; customer examples are not independent benchmarks or a guarantee that results transfer.
What the archive adds
The dossier points to availability on Vercel AI Gateway, according to its archived changelog finding. That is an integration signal, not evidence of adoption. The dossier’s API-guide finding describes the typed-answer design and request capacity; it provides context for the product’s bounded-decision framing, not evidence of comparative quality or performance. No relevant archive evidence establishes how widely developers will use the API.
Trend signal
A model’s short label or route used to be treated as a small output from a general-purpose conversation. Decisions makes that choice space explicit at the API boundary. The benefit is a result that applications can consume without interpreting free-form prose; the corresponding obligation is that developers define the allowed answers, decide what to do with ambiguity and measure whether the outputs are right. This is a shift toward treating model decisions as application contracts, not merely prompts.
Why now
Three factors make this launch timely, though they do not establish OpenAI’s motive. The primary announcement targets repeated bounded decisions inside applications and agents, where typed outputs may be easier to consume than prose. According to the dossier’s API-guide finding (d3), the product returns typed answers and supports requests with up to 400 questions, making batching and explicit decision formats part of its design. According to the dossier’s Vercel changelog finding (d1), the API is available through Vercel AI Gateway, an integration signal that may lower friction for some developers but does not establish adoption.
Connections to other events
The non-obvious consequence is that a closed answer set transfers design work to the application team. If a route is missing, an input is ambiguous, or the rubric is poorly defined, a neatly typed response can still be the wrong decision. GPT-Live makes the responsibility visible: the documentation says an application can trigger Decisions as transcript deltas arrive, so a team could route an interaction before the user has finished speaking. That is a plausible workflow, not a demonstrated latency or reliability result. Teams would need to test partial, changing and out-of-scope inputs, not just completed utterances.
Why it matters
Builders should treat each use of Decisions as a decision contract: define the permitted outputs, fallback behavior and evaluation criteria before connecting it to downstream actions. For buyers, the relevant comparison is end-to-end performance on their own workload—correctness, handling of ambiguity, latency and full cost—not the headline speed claim alone. Confidence values may help structure review, but the evidence pack does not show that they are calibrated for any particular domain. The API may simplify integration while making answer-space design and decision-level monitoring more important.
What happens next
- Within six months, at least one public third-party implementation or technical write-up will report a Decisions workload with an explicit evaluation set, rather than merely repeating OpenAI’s speed claim. (6 months, 55%). Watch for: A public repository, integration guide or write-up shows representative inputs and reports decision-quality results for a defined task.
- Within six months, developers building GPT-Live applications will publish examples or discussions that distinguish transcript-delta triggering from decisions made after a complete utterance. (6 months, 55%). Watch for: A public example or developer discussion documents when the call is triggered and how partial or changing transcript inputs are handled.
- Within 12 months, public comparisons of Decisions with general-purpose model calls will include workload-specific quality measures alongside latency. (12 months, 60%). Watch for: A reproducible benchmark or technical report specifies a task, test inputs and both decision quality and latency for the compared approaches.
Limits and uncertainty
The announcement gives no independent benchmark, full pricing or general guarantee for customer-reported results. “Up to 10x faster” is specifically a comparison with GPT-6 Luna through the Responses API and should not be read as a workload-independent expectation. The GPT-Live guide documents delegation and transcript-delta options but does not establish their availability, latency limits or production behavior. The evidence also cannot show how well confidence values are calibrated, whether closed sets cover real inputs, or whether developers will prefer this API over existing approaches.
Skill to build now
Build the practice of writing decision contracts. First exercise: choose one existing model-driven route, list every allowed output, define a fallback for ambiguity, and assemble representative plus edge-case inputs. Run both the current implementation and Decisions against that set, recording correctness and end-to-end latency before deciding whether to change the workflow.
Reader takeaway
This week, pick one classifier or router in your application and write down its complete allowed answer set, including an explicit fallback for ambiguous or out-of-scope cases. Build a small test set with ordinary and edge-case inputs, then compare the current path with Decisions for decision quality, end-to-end latency and total cost. If you are considering transcript-driven use, include partial utterances in the test. Treat the speed claim as something to verify, not a deployment assumption.
Open question
Will developers treat returned probabilities and confidence as actionable signals for automated routing, or keep them advisory until they can demonstrate calibration and safe fallback behavior on their own data?