OpenAI’s Decisions API: what developers can verify today

OpenAI announced a Decisions API at DevDay on September 29. Its official recap describes a narrow task: developers provide text or image context, ask their own questions with a finite set of predefined answers, and receive answers for classification, request routing or an agent’s next action. OpenAI says the service focuses GPT-6 Luna’s intelligence on those questions.

That description gives application builders a reason to pay attention. It does not yet give them a public integration contract. The recap calls the service a limited preview and says broader release is planned “in the coming days.” At our September 30 check, the OpenAI API changelog had no Decisions API entry. We found no official public request path, request or response schema, SDK example or Decisions API price in the materials checked. BIG CHANGE has not called the service.

The decision is the product boundary

In an application, a classification can matter because it determines what happens next. OpenAI’s examples cover selecting a category, routing a request and choosing an agent action. The announced interface puts the developer’s question and allowed answers at the center of that exchange. A returned answer could be useful to software that already knows what each choice means.

The finite answer set also makes the intended behavior easier to specify than an open-ended reply. A builder can define the choices that are meaningful to the application and then assess whether the selected answer is correct for representative inputs. That is an analysis of the announced design, not a finding about the preview’s accuracy. A choice constrained to valid labels can still be the wrong label. The application remains responsible for deciding whether a label is enough to act, whether it needs review, and how to recover from an error.

The difference is clearest when a model selects an agent’s next action. OpenAI says that is a use for Decisions API; it has not published the action-execution behavior of this preview. Selecting a next step and carrying it out are separate operations. Permissions, the action itself and a check on its result belong to the surrounding workflow unless OpenAI documents otherwise.

What existing APIs already document

Developers who need a bounded output today have a documented route through the Responses API and Structured Outputs. Structured Outputs can require a model response to match a supplied JSON schema, including a field whose allowed values are a fixed set. The documentation says schema adherence does not eliminate mistakes in the returned values. That makes it useful for enforcing the shape of a classification result, while task-specific evaluation remains necessary to judge the classification itself. OpenAI has not said whether Decisions API uses Structured Outputs or shares its implementation.

Function calling addresses another part of the workflow. An application defines functions and their arguments; the model can request a function call, and application code executes it and sends back the result. This is relevant when a selected next step should invoke a tool. The developer still controls which functions exist and whether a requested operation is allowed. The documented function-calling flow says nothing about the Decisions API’s endpoint or how its answers are represented.

Moderation is a specialized classifier for potentially harmful text and images. Its documented results support an application’s content policy, including review or intervention. It is the appropriate comparison when the question is about harmful-content categories. OpenAI’s Decisions API announcement instead describes developer-defined questions and answer choices. The recap does not claim that Decisions API replaces the Moderation endpoint or provides its safety categories.

These distinctions matter in procurement as well as code. The GPT-6 Luna model page and API pricing page publish standard model rates. The recap’s reference to Luna does not establish that Decisions API calls use those rates. Neither the recap nor the public changelog checked September 30 states a separate Decisions API charge. Budget comparisons should wait for an explicit price and billing unit.

The big change

OpenAI has announced a service expressly framed around finite, developer-defined decisions from text or images. The immediate opportunity is a clearer boundary between a model’s answer and the application that uses it. For now, that is a product description at limited-preview stage. The missing public contract prevents a reliable implementation guide or a measured comparison with existing APIs.

Our DevDay launch guide places Decisions API among the event’s releases and previews. This follow-up concentrates on the decision interface and what a developer can verify. BIG CHANGE’s Jev overview and Jev demonstrations cover TypeSafe AI’s separate product. Similar decision-oriented language is no evidence of shared architecture, training or API behavior.

What to check before adopting the preview

The practical next step is to specify one real classification or routing task, its permitted answers, the evidence for a correct answer and the consequence of a wrong one. An existing documented API can be evaluated against that task now. For Decisions API, developers with preview access need OpenAI’s actual contract before integrating: eligibility and access path; supported request and response fields; treatment of unsupported or ambiguous inputs; rate limits; data handling; pricing; and versioning. Responsiveness and error rates then need measurement on the application’s own workload. The announcement supplies none of those measurements.

OpenAI’s planned broad release is a timeline statement, not confirmation that access has opened. The API changelog and future product documentation are the places to verify the release terms when they appear. Until then, speed, confidence fields and exact call syntax described in community commentary should not be treated as an OpenAI specification.

Sources & further reading

• OpenAI, DevDay 2026 Recap — September 29 announcement of the Decisions API’s finite-answer concept, text or image context, use cases and limited-preview stage. The recap does not provide a request schema, price or benchmark.
• OpenAI API changelog — Checked September 30 for “Decisions API,” “decision layer” and “fast decision layer”; none appeared. This absence does not undo the official announcement or establish the status of private preview access.
• OpenAI API, Structured Outputs — Documented schema adherence and the warning that returned values may still be mistaken. It does not document Decisions API.
• OpenAI API, Function calling — Documented function definitions, model calls and application execution, used here to distinguish choosing an action from carrying one out.
• OpenAI API, Moderation — Harmful-content classification for text and images, with purpose-specific categories and policy uses.
• OpenAI API, GPT-6 Luna and API pricing — Standard model pricing context only; neither establishes Decisions API billing.
• Hugging Face Community Article by bna — The reader lead for this story, not an OpenAI release or API specification. Its speed and implementation claims are not used here.