On 22 October 2026, OpenAI made the OpenAI Decisions API generally available: a new endpoint, built on GPT-6 Luna, that does one narrow job — answering questions with bounded answers, a probability, a choice from a fixed list, or a score on a rubric, instead of generating free text. OpenAI says it does that up to 10 times faster than calling the same model through the Responses API, at $0.10 per million input tokens with no charge for output tokens. This article explains what the API does, how its three answer types work, what it costs, and when to use it — and when not to.
What the OpenAI Decisions API is
OpenAI announced the Decisions API at DevDay on 29 September 2026, ran it in public beta from 6 October, and made it generally available on 22 October. The problem it addresses: applications and agents make many small decisions throughout a workflow — how to classify an input, where to route a request, which action to take next. Individually simple, at scale their latency and cost add up.
The Decisions API focuses Luna’s intelligence on questions with bounded answers, for near real-time decisions from text, images and structured inputs. OpenAI already uses it internally: its dots team to reduce response times, Personal Finance to categorise transaction descriptions, and Communications to classify coverage and score whether it reinforces or challenges key narratives.
To be precise about what kind of product this is: the Decisions API is an endpoint, not a model. Requests go to POST /v1/decisions using gpt-6-luna, currently the only supported model. The endpoint does not write essays, extract fields into a schema, or call tools. It reads the evidence you send, scores only the answers you allow, and returns the result. That narrowness is the point: the output space is closed, so the model cannot answer outside the list, and no text is generated, so the response comes back fast.
How it works: three kinds of answers
A request has three parts: model, input (the shared evidence — a text string, or an ordered array of messages, tool calls and tool outputs), and questions (what to evaluate — each with a unique name, a type, and instructions). The response contains an answers array, each answer keyed by its question’s name.
There are three question types, and choosing between them is the main design decision a developer makes:
- Predicate. Estimate the probability that a condition is true, as a number from 0 to 1. Checking a product photo for visible damage is the canonical example: the answer might be 0.92, and the application sets its own threshold for flagging the photo.
- Choice. Select one of the developer’s predefined options; the answer includes the chosen value, a probabilities array for every option, and a
confidencefield. Routing a customer complaint to a department is the typical use. - Score. Rate an input against 2 to 10 ordered levels in a rubric, such as issue severity. The returned score is the probability-weighted average of the level indices, so it can fall between levels — as an illustration, probabilities of 0.1, 0.7 and 0.2 across levels 0, 1 and 2 give a score of 1.1.
An illustrative sketch of a choice request — the values are made up to show the shape, not a recorded API payload — looks like this:
{
"model": "gpt-6-luna",
"input": "I was charged twice for my order.",
"questions": [{
"type": "choice",
"name": "department",
"instructions": "Which department should handle this complaint?",
"choices": ["billing", "technical", "shipping", "other"]
}]
}And the answer, again as an illustrative sketch, comes back as a typed result, not text:
{
"answers": [
{
"type": "choice",
"name": "department",
"choice": "billing",
"probabilities": ["<a probability for each supplied value>"],
"confidence": 0.93
}
]
}A few working rules follow from the design. Give choices distinct values and descriptions that explain when each one applies, and include a fallback option such as "other" so uncovered inputs can go to a general review queue. Write questions around observable criteria, separate different concerns into different questions, and define score levels so adjacent levels have distinct criteria. Independent questions can share one request. Where one decision depends on an earlier answer, a natural design is to send separate requests and use the first result to shape the second. Inputs can be text, images and native JSON, and conversation history including tool calls and outputs can be passed as evidence.
How fast and how cheap
The headline number is speed: OpenAI says the Decisions API answers about 10 times faster than GPT-6 Luna through the Responses API. One independent launch summary put the typical figure at about 150 milliseconds against 1.6 seconds for a standard Luna call — but that is a secondary report, and OpenAI has not disclosed how the 10x claim was measured. Treat it as the vendor’s claim until independent benchmarks exist, not as a measured fact.
Pricing is straightforward: $0.10 per million input tokens, $0.01 per million for cached input, and no output-token charges — you only pay for input tokens. Prompt caching reuses shared input at a discount, with 30-minute and 12-hour cached writes. Regional processing is offered in the US and EU, and Zero Data Retention is available to eligible customers; secondary reporting also mentions HIPAA eligibility. Since the public beta, the limit has doubled from 200 to 400 questions per request, and the API has gained native JSON input, hosted image inputs, conversation history, organisation usage reporting and Private Link.
Two pieces of context help place the price. OpenAI has simplified its API usage tiers from five to three — Build, Launch and Grow — with monthly limits of $500, $5,000 and $200,000. And the launch arrives in an active market: TypeSafe’s Jev, a typed decision model released in mid-September 2026, is the obvious rival, and one independent comparison priced a million classifications of 500 tokens at $21 for Jev against $50 for the Decisions API. The Decisions API is not the cheapest endpoint on that measure — its case rests on being inside OpenAI’s platform, on one model, with one API.
What teams are doing with it
OpenAI’s announcement leads with five customer examples. They show where a fast decision endpoint earns its keep — but they are all vendor-published, so the numbers are customers’ claims rather than independent measurements.
Box uses the API with Box Extract to classify business documents and route them to the next step. Biswaroop Palit, VP of Product Management for Platform and Integrations at Box, says it delivered about five times faster route selection on 30 certificate-of-insurance cases, with the same accuracy as the Responses API, while lower-confidence cases go to reviewers. Note the sample size: 30 cases is a pilot evaluation, not a production benchmark.
“With Box Extract and the Decisions API, we classify business documents and route them to the right next step. In our evaluation, the Decisions API delivered ~5x faster route selection on 30 certificate of insurance cases, with the same accuracy as the Responses API—automating routine work and sending lower-confidence cases to reviewers.” — Biswaroop Palit, VP, Product Management Platform and Integrations, Box
Datadog puts the API in the hot path of an automated remediation, scoring the risk of agent-generated shell commands before executing them. AJ Stuyvenberg, Staff Engineer at Datadog, reports 40 times faster p95 latency with comparable accuracy — a figure that matters because the check runs before the remediation command executes.
“The Decisions API is helping us score the risk of agent-generated rshell commands before executing them to autonomously remediate issues. Compared with available frontier models, it delivered 40x faster p95 with comparable accuracy—making it possible to place Decisions in the hot path of a remediation action.” — AJ Stuyvenberg, Staff Engineer, Datadog
Ramp uses it to attribute AI costs to the actual work, reporting 4 times faster attribution at 30% lower cost than GPT-6 Luna. Sierra uses it to choose the next action in live customer conversations, at under 280 milliseconds p95 — about 3 times faster and 90% lower cost per call, with no drop in customer outcomes. Speak, the language-learning company, reports the most dramatic figure: its GPT-Live integration cut the time to next action by over 90%, from 1.4 seconds to 0.13 seconds.
What the five examples have in common is bounded work — classification, scoring and next-action selection — with customer-reported latency or cost gains.
Decisions in live voice with GPT-Live
The newest capability is the native GPT-Live integration: a voice session can call Decisions directly as the user speaks. A customer support agent can decide in real time whether to clarify, route or escalate, and an avatar can adjust its facial expressions as a user speaks — choosing a reaction from the speaker’s latest words and responding with a wink or a smile.
It works through a decision.event emitted by the live session: the application adds a decisions configuration to session.triggers and reads the selected reaction from the event to animate the character. Speak’s result is the clearest demonstration of why this matters: in voice, a decision that takes over a second is a pause the user can feel, and one that takes a tenth of a second disappears into the conversation.
When to use Decisions instead of a full model call
OpenAI’s own guidance draws the lines clearly. Use Decisions when your application needs one of the three answer types for a bounded question, especially in a hot path where latency matters, or where the same small decision repeats at volume. Classification, request routing, prioritisation, risk scoring before a remediation command executes, and next-action selection inside an agent’s orchestration are the natural fits.
Do not use it where the answer is not bounded. If you need generated objects that follow your own JSON schema, such as extracted fields or a written explanation, OpenAI points you to Structured Outputs with the Responses API. If you need a model to request a tool call with arguments, that is function calling. And if the decision needs reasoning a user can inspect, or an explanation of why an option was chosen, a typed answer will not give it to you — the API returns which option fits best, not why.
Two operational habits matter more than the endpoint itself. First, set thresholds from labelled examples in your own application, weighing false positives against false negatives — when a probability is used to trigger an action, define and test the threshold that decides when it fires. Second, build the fallback in from the start: include an "other" choice, and send low-confidence answers to a human or a bigger model. Box’s setup is the model — automate the routine cases and route the uncertain ones to reviewers, rather than letting a fast API make a confident mistake.
How to try it
The fastest way to judge the API is to use it. The Decisions Playground at platform.openai.com/decisions lets you experiment with questions and inputs before writing code, and the developer guide at developers.openai.com/api/docs/guides/decisions walks through a first request. OpenAI’s advice is specific: start with one recurring decision your application makes often, define the question, the possible answers, and the context that distinguishes them, then test it on examples that reflect real usage.
That is also the right test for the launch as a whole. The Decisions API is a dedicated endpoint for bounded application and agent decisions, which OpenAI says answers up to 10 times faster than GPT-6 Luna through the Responses API. Whether it is worth adopting depends on how many of those judgments your application makes, and what each costs in latency and tokens — actual latency and cost benefits depend on the workload and the baseline. If the answer is “many, and too much”, the endpoint is ready to try.
