OpenAI Decisions API: A New AI Primitive for Fast, Typed Decisions

OpenAI’s Decisions API is a dedicated low-latency interface for turning text and images into typed probabilities, fixed choices, and rubric scores that software can act on directly.

OpenAIOct 6, 2026OpenAI API12 min readOpenAI

NEWAI EngineeringIntermediate

Paper Code Project

Key takeaway

Instead of asking a general LLM to generate prose and then parsing it, Decisions lets developers define the decision space and receive a bounded answer. It currently supports predicate, choice, and score questions on gpt-6-luna, is positioned as about 10x faster than the Responses API, and charges $0.10 per 1M input tokens with no output-token charge for the endpoint.

Updated on Oct 8, 2026

Abstract

OpenAI released the Decisions API in public beta on October 6, 2026.
The endpoint is designed for applications that need a model to make a bounded decision rather than generate a long-form answer.
It evaluates text, images, or both and returns typed answers approximately 10x faster than the Responses API according to OpenAI.
The current implementation uses gpt-6-luna and exposes three question types: predicate, choice, and score.
A predicate estimates the probability that a condition is true; a choice selects one value from developer-supplied options; and a score evaluates an input against ordered levels using a probability-weighted average.
The design is useful for classification, request routing, agent-action selection, model routing, prioritization, image inspection, and human-escalation workflows.
The central architectural idea is simple: the model judges the evidence, while deterministic application code retains authority over thresholds, authorization, and actions.

Introduction

Most LLM applications still follow a generation-oriented pattern: provide context, ask the model to reason, receive text, and then parse that text into software behavior. This is often unnecessary when the actual requirement is a small decision. A support application may only need billing versus technical support. A safety workflow may only need whether escalation is required. An agent may only need to select search, database, calculator, or human review. OpenAI’s Decisions API treats these bounded judgments as a first-class interface. Instead of generating a sentence and extracting meaning from it, developers define the question and the valid answer space. The result is intended to be directly consumable by software. OpenAI’s current documentation positions Decisions for classification, routing, and prioritization, while Structured Outputs remains the better fit for generating arbitrary objects that conform to a developer-defined JSON schema.

Problem

The underlying problem is an interface mismatch. Software likes bounded values: booleans, enums, scores, rankings, and explicit states. Generative models produce token sequences. Even when a model is instructed to emit JSON, the model is still performing a generation task and the application must validate both the structure and the semantic decision. Decisions narrows the interface. The developer supplies shared evidence and one or more focused questions. Each question has a known type and, for choice or score, a known answer space. This can reduce parsing logic and makes uncertainty an explicit output instead of asking a model to write a sentence such as “I am 90% confident.” The design is especially relevant when a system performs many small judgments around one larger reasoning task. It is not intended to replace open-ended reasoning, generation, or deterministic business rules.

Background

Decision-specific AI is not a completely new research area. Traditional classifiers, cross-encoders, rerankers, learned routers, rules engines, and confidence-aware human-in-the-loop systems already make bounded decisions. Developers have also used general LLMs with Structured Outputs or function calling to produce machine-readable decisions. What is new here is the API abstraction and optimization target: OpenAI is exposing a dedicated endpoint where bounded decisions are the native output rather than a side effect of text generation. The current endpoint is powered by gpt-6-luna. OpenAI’s changelog describes the release as a beta feature that turns text and images into typed answers 10x faster than the Responses API. This positions Decisions as a specialized control-plane primitive rather than another general chatbot interface.

Methodology

Every Decisions request has three core components: model, input, and questions. The model is currently gpt-6-luna. Input is shared evidence and can be a text string or user messages containing text and images. Questions define exactly what should be evaluated. Each question should have a unique name so its answer can be identified in the response.

There are three decision types:

Predicate — estimates the probability that a condition is true.
Choice — selects one value from developer-supplied options and returns probabilities plus confidence.
Score — evaluates an ordered rubric and returns a probability-weighted score across the defined levels.

Multiple independent questions can share the same input. If one decision depends on another, use separate requests so the application can explicitly control the dependency.

Python implementation

The basic flow is to install the current OpenAI SDK, create a client, provide the evidence, define a bounded question, and consume the typed answer.

PYTHON
from openai import OpenAI

client = OpenAI()

decision = client.decisions.create(
    model="gpt-6-luna",
    input="The customer says the package arrived with a broken screen.",
    questions=[
        {
            "type": "predicate",
            "name": "damaged",
            "instructions": "Does the customer report a damaged item?"
        }
    ]
)

answer = decision.answers[0]

if answer.type == "predicate":
    if answer.probability >= 0.90:
        print("Escalate for damage handling")
    else:
        print("Continue normal support flow")

Choice example

Use choice when the output must come from a fixed set.

PYTHON
decision = client.decisions.create(
    model="gpt-6-luna",
    input="I was charged twice for the same order.",
    questions=[
        {
            "type": "choice",
            "name": "department",
            "instructions": "Which support department should handle this request?",
            "choices": [
                {"value": "billing", "description": "Payments, charges, refunds"},
                {"value": "technical", "description": "Product or technical problems"},
                {"value": "shipping", "description": "Delivery and shipment problems"},
                {"value": "other", "description": "Anything outside these categories"}
            ]
        }
    ]
)

answer = decision.answers[0]
print(answer.choice, answer.confidence)

Score example

Use score when the levels have a meaningful order, such as severity.

PYTHON
decision = client.decisions.create(
    model="gpt-6-luna",
    input="Checkout is failing for every customer and no workaround is available.",
    questions=[
        {
            "type": "score",
            "name": "severity",
            "instructions": "How severe is this issue?",
            "levels": [
                {"label": "Cosmetic", "description": "Appearance only; no lost functionality."},
                {"label": "Workaround available", "description": "A task fails, but another way works."},
                {"label": "Fully blocked", "description": "A task fails with no workaround."}
            ]
        }
    ]
)

answer = decision.answers[0]
print(answer.score, answer.confidence)

Production implementation pattern

Use the model for the judgment and deterministic code for policy:

Evidence → Decisions API → Typed Decision → Threshold/Policy → Action

Do not automatically authorize an action merely because a predicate probability is high. Apply application-specific thresholds, permissions, fallbacks, logging, and human escalation in deterministic code.

The API also supports refusal answers, so production code should handle refusal explicitly rather than assuming every question returns the requested answer type.

The current official documentation supports text and inline base64 images as input; external HTTP/HTTPS image URLs and file IDs are not supported by this endpoint.

OpenAI Decisions API flow from evidence to typed predicate, choice, or score decision and downstream action — OpenAI Decisions API architecture
Evidence flows into a dedicated Decisions API that returns typed Predicate, Choice, or Score decisions before deterministic policy and application actions.

Architecture

A useful production architecture is Evidence → Decision → Policy → Action. Evidence may include a customer message, conversation state, retrieved documents, structured application state, or images. The Decisions API evaluates that evidence against bounded questions. Deterministic application code then applies thresholds, permissions, fallbacks, and business rules before performing an action. For agents, this creates a clean separation between reasoning and control. A general model can propose a plan or tool call; Decisions can evaluate whether the proposed action is allowed, which tool should be used, how severe the situation is, or whether human review is required. The same pattern can be used as a model router: a fast decision selects a cheaper model for simple requests and a stronger reasoning model for complex requests. The key architectural rule is that a valid typed decision is not automatically an authorized action.

Results

The current public product facts are concrete. The Decisions API is in public beta, gpt-6-luna is the only supported model, and the endpoint is POST /v1/decisions. OpenAI positions it as approximately 10x faster than the Responses API for decision workloads. Pricing is $0.10 per 1 million input tokens for gpt-6-luna on Decisions, with no output-token charge and no cache-read or cache-write charge for the endpoint; regional-processing premiums and long-context multipliers can apply. The API is available in supported regions, with regional processing supported in the United States and Europe (EEA + Switzerland). OpenAI’s data-controls documentation also states that eligible customers can use Zero Data Retention and HIPAA support under the applicable requirements. These are current platform facts and should be distinguished from independent benchmarks or business outcomes.

Limitations

Decisions is a specialized interface, not a replacement for general reasoning. A typed answer can still be wrong. A high probability is not authorization, and thresholds must be validated against application-specific costs. Calibration can degrade under distribution shift. The current endpoint also has important input constraints: image inputs are supplied as inline base64 data URLs; external HTTP or HTTPS image URLs and file IDs are not supported by the Decisions endpoint. The API currently supports text and images but should not be assumed to be a general audio, video, or arbitrary-file processing endpoint. The service is in public beta, so the API contract and supported capabilities may evolve. Production systems need timeouts, retries, monitoring, model/version tracking, fallbacks, and human escalation for high-impact decisions. Finally, the absence of free-form output is a feature, not proof of “zero hallucinations”: a model can select the wrong value while still producing a perfectly valid typed response.

Conclusion

OpenAI’s Decisions API is best understood as a new interface between model intelligence and software control flow. Instead of treating every AI request as text generation, developers can define bounded questions and receive probabilities, fixed choices, or ordered scores that software can consume directly. The most useful pattern is Evidence → Decision → Policy → Action. This fits agent routing, tool selection, model routing, triage, prioritization, image inspection, guardrails, human escalation, and high-volume classification. The strongest implementations will keep the responsibilities separate: use a general reasoning model for open-ended thought, use Decisions for repeated bounded judgments, and keep authorization, thresholds, auditability, and final business actions in deterministic application code. The current release is promising because it makes a common production problem explicit, fast, and typed. Its real value should ultimately be judged on representative workloads rather than on the API abstraction alone.

References

OpenAI, Decisions API guide: https://developers.openai.com/api/docs/guides/decisions
OpenAI, Decisions API reference: https://developers.openai.com/api/reference/resources/decisions/methods/create
OpenAI, API changelog, October 6, 2026: https://developers.openai.com/api/docs/changelog
OpenAI, API data controls: https://developers.openai.com/api/docs/guides/your-data
OpenAI, release notes, Decisions API with GPT-6 Luna: https://openai.com/products/release-notes/
Aishwarya Srinivasan, OpenAI Decision Models Explained: https://aishwaryasrinivasan.substack.com/p/openai-decision-models-explained
Sanity, OpenAI Decisions API glossary: https://www.sanity.io/glossary/openai-decisions-api
OpenAI Developer Community, Decisions API public beta announcement: https://community.openai.com/t/decisions-api-is-now-available-in-public-beta/

Source trail

Primary papers, implementation pages, and external source records used to ground this explainer.

Ref 01

Decisions API guide

OpenAI. Decisions. OpenAI API documentation. 2026.

Primary technical specification for the endpoint, question types, examples, limitations, pricing and guidance.

Ref 02

Create a decision API reference

OpenAI. Create a decision. OpenAI API Reference. 2026.

Endpoint schema and response examples.

Ref 03

API changelog

OpenAI. API Changelog. October 6, 2026 entry.

Confirms the beta release of gpt-6-luna and v1/decisions.

Ref 04

OpenAI Decision Models Explained

Srinivasan. OpenAI Decision Models Explained. 2026.

Secondary explanation used for context and comparison; current official documentation supersedes older preview-era details.

Ref 05

OpenAI Decisions API glossary

Sanity. OpenAI Decisions API glossary. 2026.

Secondary explanation of the decision-model concept and application architecture.

01OpenAI Decisions API guide 02OpenAI Decisions API reference 03OpenAI API changelog 04OpenAI data controls 05Aishwarya Srinivasan — OpenAI Decision Models Explained 06Sanity — OpenAI Decisions API

Related research

AI Engineering

Decisions API vs Jev

OpenAI Decisions API and TypeSafe AI’s Jev both target structured, software-consumable decisions, but differ in model approach, input support, and ecosystem.

Browse all research