Latest in AI
OpenAI Decisions API: GA Pricing, GPT-Live Integration and Limits
OpenAI's fast decision endpoint is generally available, but its usefulness depends on how carefully you define the choices.
OpenAI made its Decisions API generally available on October 22. It uses GPT-6 Luna to classify inputs, choose among predefined actions and return scores without generating a full conversational response. The GA update raises the limit to 400 questions per request and adds caching and richer input options.
For developers, the useful question is where a small decision can replace a larger model call. A support system may need to choose a queue before composing a reply. Paying for a written explanation at that first step adds work the application may never use.
Correction, October 23: GPT-Live integration arrived on October 15, before general availability. The opening has been corrected to distinguish the two dates.
What changed from the public beta
The GA announcement adds native JSON input, images inside individual question instructions and US/EU inference residency. The question limit has doubled from 200 to 400. OpenAI also says it has improved latency and added capacity in parts of Asia.
OpenAI claims Decisions can run up to 10 times faster than GPT-6 Luna through the Responses API. That comparison concerns a focused endpoint and workload, not a claim that Luna has become ten times faster at every task. The announcement's customer results are customer-reported examples rather than a universal latency guarantee.
Decisions API pricing
The endpoint charges for input tokens, with no output-token fee. Its caching rates follow standard GPT-6 Luna pricing.
| Input category | Price per million tokens |
|---|---|
| Uncached input, short context | $0.10 |
| Cached input, short context | $0.01 |
| 30-minute cache writes, short context | $0.125 |
| 12-hour cache writes, short context | $0.25 |
These are the published base rates, not a flat price for every configuration. OpenAI's pricing page lists higher long-context rates, and the Decisions guide says regional processing premiums apply. Cache writes are charged; a cache hit and the creation of a cache entry are different billing events.
As a simple illustration, 1,000 short requests using 1,000 uncached input tokens each would contain one million input tokens and cost $0.10 at the base rate. That calculation excludes cache writes, regional uplifts and any separate model calls the application makes afterward.
How the endpoint makes a decision
Send requests to POST /v1/decisions with gpt-6-luna. The API reference defines shared input plus named questions, with answers returned in an array.
Three question types cover different jobs. A predicate estimates whether a condition is true. A choice selects from options you supply. A score evaluates ordered rubric levels and returns their probability-weighted average. A score can therefore fall between levels rather than identifying one category.
Consider the support queue again. Give billing, technical support and a fallback option distinct descriptions. The useful output is the selected queue, together with the returned probability information, rather than a paragraph about why support tickets exist.
The application still owns the consequences of that selection. A classification result should not silently become permission to refund money or change an account. Those actions need their own checks.
How the existing GPT-Live integration works
Native GPT-Live integration was added earlier, on October 15, according to the API changelog. It is available alongside the GA endpoint rather than being a new October 22 feature.
The voice integration documentation describes two paths: GPT-Live can delegate a recognized request to Decisions, or configured triggers can react to incoming and outgoing transcript updates. Native delegation removes the extra round trip in which your application receives a request and calls Decisions itself.
The application still executes the selected action and reports what actually happened. A returned choice is not proof that a tool completed successfully. For a voice interface, this distinction matters because a fast but premature confirmation can be more confusing than a slightly slower correct one.
Caching and accuracy need separate checks
The Decisions guide says caching reuses a matching prefix of shared input, with a minimum of 1,024 tokens. Question content does not count toward that threshold or belong to the reusable prefix. Repeated reference material can benefit; changing all the shared input on each call will not create the same opportunity.
Questions in one request are independent. If the second decision needs the first answer, make separate requests. For arbitrary generated JSON, written explanations or tool calls with arguments, OpenAI directs developers to the corresponding Responses API features instead.
I would evaluate routing accuracy and total workflow latency together. Record which cases reach the wrong queue, how often a fallback is needed and whether the later response improves. Saving a small model call is useful only if it does not create a more expensive repair elsewhere in the workflow.
The stronger use case is a clearly bounded decision that occurs repeatedly. As these decisions become cheap enough to insert throughout a product, defining the right choices becomes more important than generating more text.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help AI founders turn technical launches and product decisions into clear stories that developers can understand and share.