OpenAI Decisions API: What Typed AI Decisions Change for Software

TL;DR: AI software is getting a decision endpoint

OpenAI announced the Decisions API in beta on October 6, 2026. Its purpose is narrower than a general-purpose generation API: evaluate text, images, or both and return typed answers that software can use. The official guide describes three answer shapes: a predicate probability, a choice from a fixed set, or a score against ordered levels. OpenAI says these decision-shaped requests can be up to 10 times faster than using the Responses API for the same kind of work.

That does not make the endpoint a universal replacement for generation. It makes it a potentially better fit for routing, triage, moderation, prioritization, and image checks where the application needs a bounded result rather than a paragraph. Developers can start with the official Decisions API guide, while software buyers can compare adjacent tools in the BTTC software directory.

What OpenAI launched

The new endpoint is POST /v1/decisions. A request contains a model, shared input, and one or more named questions. The current public-beta guide lists gpt-6-luna as the only available model. Each question describes what the model should evaluate and, when appropriate, supplies allowed choices or ordered score levels. The response returns an answers array, so an application can identify each result by the question name.

The important product decision is the separation between evidence and output shape. A customer complaint can be routed to billing, technical support, shipping, or another queue. A product image can be evaluated for visible damage and assigned to a category. A document can be scored against a severity rubric. Those tasks do not necessarily need open-ended prose. They need an answer that a queue, rule, dashboard, or workflow can consume.

OpenAI recommends using a predicate when the question is whether a condition is true, a choice when categories have no meaningful order, and a score when levels are ordered. The guide also warns developers to keep questions independent when combining them in one request. If one answer determines the next question, send a separate request instead of hiding a multi-step dependency inside one prompt.

Why this matters for application architecture

Many AI products still treat every request as chat. That can be convenient for a prototype, but it creates extra work when production software must decide what happens next. Engineers need to parse output, guard against missing fields, define fallback behavior, and test whether a natural-language answer maps safely to an operational action.

A typed decision result can make the boundary clearer. A probability can be compared with a threshold. A choice can map to a queue identifier. A score can trigger a human review band. This is not the same as eliminating uncertainty: it moves uncertainty into an explicit value that the surrounding application can measure and govern.

The practical benefit depends on the workflow. If the user wants a written explanation, a multi-field object, a tool call with arguments, or a long answer, the Responses API with Structured Outputs or function calling may be the better fit. If the application only needs a bounded classification or ranking signal, a dedicated decision request may reduce latency and simplify downstream code.

Four checks before using it in production

1. Define observable questions

Bad questions combine several judgments: “Is this a good customer and should we prioritize the case?” Better questions separate them: “Does the message describe a billing problem?” and “Does the message include a stated deadline?” Distinct questions make the result easier to test and explain. For image inputs, describe visible criteria rather than asking for an ambiguous overall opinion.

2. Set thresholds from labeled examples

A probability is not automatically a business rule. Use representative, labeled examples to measure false positives and false negatives, then choose thresholds according to the cost of each error. A support router may prefer higher recall, while a compliance queue may prefer conservative escalation. Revisit thresholds when traffic, language, products, or abuse patterns change.

3. Keep evidence and review paths

A decision should be traceable to the input that produced it, the question definition, the model version, the threshold, and any human override. Store only what your retention policy allows, but do not build a system that cannot explain why a request was routed or rejected. OpenAI's data controls documentation says /v1/decisions has its own retention and regional-processing considerations, including support for Zero Data Retention for eligible customers. Verify the exact terms for your organization before sending sensitive data.

4. Design a failure and fallback path

Beta availability, rate limits, timeouts, malformed inputs, and ambiguous cases are normal engineering concerns. Decide what happens when the API is unavailable, the confidence is low, or the answer falls between score levels. A safe default may be human review, a slower secondary path, or a queue that does not perform an irreversible action.

Faster does not mean automatically cheaper

OpenAI's guide says input pricing for gpt-6-luna is $0.10 per 1 million tokens and that the endpoint charges only for input tokens, while regional-processing premiums and long-context multipliers can apply. A real comparison still needs more than token price. Include retries, monitoring, labeling, human review, storage, integration work, and the cost of wrong routing. A fast model that sends the wrong cases to the wrong team can be more expensive than a slower workflow with a reliable review gate.

The same principle applies to buying software around the API. Look for logs, replay tools, threshold controls, export options, permissions, and clear model availability. A polished demo is not enough if the product cannot show evidence, recover from partial failure, or let a team change providers later.

FAQ

The official documentation is the source of truth for beta behavior and supported models.

Conclusion

The Decisions API signals a useful split in AI software: generation for language-rich work, and typed decisions for bounded application logic. It may help teams build faster routing and triage paths, but only when questions are observable, thresholds are measured, evidence is retained appropriately, and failure handling is explicit. Treat it as a focused beta capability, not a shortcut around evaluation and product design.