By Tsuky 
An AI agent may make dozens of small decisions before completing a single task.
It must determine which tool to use, whether information is relevant, how risky an operation appears and which service should handle a particular request.
Those decisions do not always require lengthy reasoning or a complete written response.
Nevertheless, many applications rely on general-purpose conversational models to handle these intermediate steps.
Each model call introduces latency and consumes computing resources.
OpenAI wants to change that architecture with the Decisions API.
The service became generally available on October 22, following an initial introduction at DevDay and a public beta launched on October 6.
Its central idea is to use GPT-6 Luna to produce an answer selected from predefined possibilities rather than generating unrestricted prose.
The model still evaluates the supplied context. The difference lies in the response format and the optimization of the decision process.
An API for choosing rather than writing
The Responses API can generate explanations, code, detailed analysis and structured information.
It also supports sophisticated tool use.
The Decisions API is designed for narrower questions.
A developer defines what needs to be decided, supplies the permitted answers and provides relevant context.
That context can include text, images and native JSON data.
The API returns a bounded result that the application can use directly.
Consider a company receiving thousands of support messages.
Each request may need to be routed to billing, technical support, shipping or another department.
A conversational model could generate a written explanation for every message.
But if the application only needs a category, producing additional prose is unnecessary.
With Decisions, the developer defines the available categories and receives the selected one.
The application then determines what action to perform.
Separating contextual analysis from unrestricted text generation is the foundation of the new interface.
Three decision types cover different tasks
OpenAI supports three types of Decisions API responses.
The first, predicate, estimates the probability that a condition is true.
A retailer might use it to analyze a product photograph and estimate whether the item has visible damage.
The result is a probability between zero and one.
This represents the model's estimate, not mathematical certainty.
The second type, choice, selects one answer from a predefined set of options.
This is useful for classifying content, routing requests and selecting the next step in a workflow.
The third type, score, evaluates an input against ordered levels.
A developer might define different incident severity levels, ranging from a cosmetic issue to a complete service outage.
The API calculates a score using the probabilities assigned to those levels.
The result can fall between two levels rather than matching a single category exactly.
These response types cover many common operations.
They are not a replacement for generating documents or arbitrary JSON structures.
Why OpenAI claims up to ten times faster decisions
OpenAI says its Decisions API can make certain choices up to ten times faster than GPT-6 Luna through the Responses API.
The comparison concerns two ways of using the same model family.
It does not mean GPT-6 Luna has become ten times more intelligent.
Conventional conversational output may require generating many successive tokens.
When the application expects only a category, score or probability, a specialized interface can avoid some of the work associated with producing a complete response.
This matters especially when an agent makes many decisions sequentially.
A delay of a few hundred milliseconds may be difficult to notice in isolation.
Repeated across dozens of operations, it can substantially affect total execution time.
However, OpenAI's tenfold improvement represents an upper-end comparison rather than a universal guarantee.
Actual latency depends on context length, input type, question count and processing conditions.
Developers should benchmark the API against their own workloads before assuming equivalent gains.
Pricing begins at $0.10 per million input tokens
Cost is another major part of the announcement.
OpenAI lists standard Decisions API pricing at $0.10 per million input tokens.
Cached input reads cost $0.01 per million tokens under the announced standard pricing.
There are no output-token charges.
This structure reflects the API's emphasis on bounded responses rather than extended generated text.
It does not make every request free.
Input processing remains billable, and regional processing or particular caching options may involve additional pricing conditions.
The cost of Decisions is also separate from the cost of other components in an agent workflow.
If an application uses Decisions to select a tool and then calls another model to generate a detailed explanation, that second call follows its own pricing.
Overall savings depend on how many tasks can genuinely be moved to the specialized interface.
Developers can ask up to 400 questions per request
The general availability release also expands the API's capabilities.
A single request can now contain up to 400 questions, compared with 200 previously.
Those questions can share the same input context.
For example, an application analyzing a product photo could check for visible damage, classify the item and evaluate several quality criteria.
Rather than repeatedly transmitting the same context through independent requests, a developer can combine relevant evaluations.
This can make batch processing more practical.
There is an important limitation.
OpenAI recommends grouping questions that are independent of one another.
When the answer to one question determines whether another question should be asked, separate requests are appropriate.
A system might first establish whether a product is damaged and then choose a repair category only when the initial decision warrants it.
The ability to ask 400 questions does not mean the API automatically executes a workflow containing 400 dependent actions.
Native GPT-Live integration targets voice applications
OpenAI has added native integration between Decisions and GPT-Live.
The aim is to let voice applications choose actions while a user is speaking or while an assistant is responding.
Conversational responsiveness depends heavily on how quickly a system determines what should happen next.
Requiring a general-purpose model call for every simple decision can introduce cumulative delays.
Decisions can help select the next action, classify a request or determine which workflow step should follow.
OpenAI highlights results from Speak, a language-learning application.
According to Speak CTO Andrew Hsu, the Decisions integration reduced the time to the next action from 1.4 seconds to 0.13 seconds in the company's testing.
That represents a reduction of more than 90% in the measured scenario.
The figure comes from Speak's evaluation.
It should not be interpreted as a guaranteed latency improvement for every GPT-Live application.
The integration nevertheless illustrates how faster intermediate decisions can improve the flow of interactive voice experiences.
Box, Datadog and Ramp report early results
OpenAI's launch announcement includes examples from early customers.
Box uses the Decisions API to classify business documents and route them through workflows.
In a test involving 30 certificates of insurance, Box reported route selection approximately five times faster than its Responses API approach, with comparable accuracy.
That result applies to a limited sample and a specific task.
Datadog is using Decisions to assess the risk of certain commands generated by agents before those commands are executed during remediation workflows.
The company reports p95 latency forty times lower than the frontier models it compared against, while maintaining comparable accuracy.
That comparison was provided by Datadog for OpenAI's announcement and should not be treated as a comprehensive independent benchmark.
Ramp has tested Decisions for attributing AI expenditure to the work that generated it.
The company says its approach became four times faster and 30% cheaper than its previous implementation using GPT-6 Luna, without a loss of accuracy in the evaluation.
These examples demonstrate the range of applications.
They also show why performance claims must be interpreted carefully.
Each company measured a different task, using different conditions and baselines.
Sierra uses Decisions in live customer conversations
Sierra provides another example.
The company uses the Decisions API to select actions during parts of live customer conversations.
According to its reported evaluation, those decisions complete in under 280 milliseconds at the 95th percentile.
Sierra also reports approximately three times faster processing and a 90% reduction in cost per call compared with its previous approach.
The company says it observed no decline in customer outcomes during the comparison.
These figures describe Sierra's own environment.
They do not mean every conversational agent will become 90% cheaper.
The savings depend on the particular operations assigned to the Decisions API.
Applications dominated by long-form response generation will still require other model capabilities.
Intermediate routing and classification tasks are the more natural fit.
Model confidence is not the same as correctness
Decisions responses can include probabilities and confidence indicators.
These signals are useful for deciding which cases should be escalated to human review.
They should not be treated as guarantees of accuracy.
A model can make an incorrect decision while assigning it high confidence.
Conversely, uncertainty may be acceptable for tasks where an error has limited consequences.
OpenAI recommends using representative labeled examples to set decision thresholds.
For routine document classification, a company may tolerate some mistakes that can be corrected later.
For a decision authorizing a command on a production server, the acceptable error rate may need to be much lower.
The consequences of false positives and false negatives should inform system design.
A faster API does not remove the need for testing, evaluation and independent safeguards.
Fast decisions are not a substitute for authorization
Decisions could become an important component of agent infrastructure.
However, the API is not a complete authorization or security system.
A result indicating that an action appears acceptable does not replace permissions enforced by the operating environment.
An application using Decisions to select a command must still verify whether that command is allowed under the user's permissions.
Financial transactions, sensitive data changes and irreversible operations may also require explicit human confirmation.
The speed of automated decisions makes these distinctions more important.
An agent making several decisions in rapid succession can propagate errors quickly if its execution permissions are too broad.
Logging, rate limits and access controls remain essential.
Decisions estimates or selects an answer. It does not independently determine the legal or technical authority to carry out the resulting action.
Regional processing expands to the US and Europe
OpenAI has also introduced regional inference processing in the United States and Europe.
This may be relevant to companies with specific geographic requirements for handling information.
Additional capacity in several Asian regions is intended to improve latency for local workloads.
OpenAI also states that eligible customers can use Decisions with Zero Data Retention.
That does not mean every account automatically receives identical residency or retention conditions.
Developers need to review their account settings, contractual requirements and available processing options.
European processing availability is not, by itself, proof that every application using the API satisfies all applicable regulatory obligations.
Compliance also depends on the nature of the data, the purpose of processing and other systems involved.
Decisions and Responses serve complementary purposes
The launch does not mean OpenAI is replacing the Responses API.
The two interfaces are intended for different kinds of work.
Responses remains appropriate for unrestricted generation, complex explanations and advanced tool interactions.
It also supports Structured Outputs when applications need JSON objects following custom schemas.
Decisions focuses on bounded answers: probabilities, choices and scores.
An agent can use both.
It might call Decisions to select the next tool and then use Responses to carry out a more complex analysis or write a user-facing explanation.
This specialization could improve the efficiency of agent architectures.
It also requires developers to design workflows more carefully.
They must identify which tasks genuinely need a general-purpose model and which can be resolved through a specialized decision.
That may introduce architectural complexity, but it can provide a better balance between latency, cost and capability.
Intermediate decisions are becoming their own AI market
The strategic significance of the Decisions API extends beyond document classification.
As more software incorporates agents, intermediate choices account for an increasing portion of automated workflows.
Agents need to decide when to ask for confirmation, which model to use, what information to retrieve and whether a problem should be escalated.
Many of those operations are simpler than the final task.
Using a full conversational model for every decision can increase latency and expense.
OpenAI is proposing a separation between producing complex content and selecting actions quickly.
That addresses a practical difficulty in the emerging agent economy.
The cost of an agent depends not only on the answers it generates but also on the number of operations required to reach those answers.
Reducing the cost and time of intermediate decisions could improve the economics of many applications.
Actual benefits will depend on workload characteristics and decision quality.
General availability is confirmed, but results will vary
As of October 23, 2026, the Decisions API is generally available with GPT-6 Luna.
Developers can access it through the dedicated endpoint and experiment in the Decisions Playground.
The release adds GPT-Live integration, context caching, native JSON input, image support and up to 400 questions per request.
OpenAI claims performance up to ten times faster than Luna through the Responses API.
The customer results shared by Box, Datadog, Ramp, Sierra and Speak suggest significant gains in selected environments, but they do not constitute a universal independent benchmark.
The practical test will be whether developers can move suitable tasks to Decisions without weakening accuracy or application safeguards.
The broader lesson is that making AI agents more useful increasingly depends not only on improving model intelligence but also on reducing the time and cost of the individual decisions required to get work done.