Updated October 23, 2026. OpenAI took the Decisions API out of beta on October 22. The article below describes the October 6 beta as it stood, with a note wherever a statement has since changed; the update section at the end covers the GA changes, including the cache that is now priced, the 12-hour cache option added on October 20 and the GPT-Live integration.
OpenAI put the Decisions API into public beta on October 6, a week after announcing it at DevDay as a limited preview. It is a separate endpoint, POST /v1/decisions, that runs only on gpt-6-luna and returns typed answers rather than text: a probability that a condition holds, one choice from a list you supply, or a score against ordered levels. At the time OpenAI said it expected general availability “in the coming weeks”; it came on October 22, and the update below covers it. Decisions guide API changelog Our DevDay article listed the missing model ID, endpoint, schema and price as items to watch; the guide now supplies all four.
The price is the part that changes a cost model. Input is $0.10 per million tokens, the same as Luna on the Responses API, and during the beta there was no charge at all for output, cache reads or cache writes. (Output is still free at GA; cache reads and writes are now priced, see the update.) For work where the model only has to pick, that removes the output side of the bill. It does not make every classifier cheaper, and the cases where it loses are worth knowing before anything gets rewritten. S5 Labs has not run the endpoint; the speed and pricing figures below are OpenAI’s, and the cost examples are arithmetic on list rates.
What a decision call looks like
A request has three parts: the model, an input that is either a string or user messages mixing text and images, and a questions array. Each question has a type, a name, instructions, and for two of the types a list of allowed answers. The response is an answers array keyed by the same names, so one request can carry several independent questions over the same input. Decisions guide
| Type | What it returns | Use it for |
|---|---|---|
predicate | probability, 0 to 1, that the condition is true | Damage visible in a photo, passage relevant to a query, message is a cancellation |
choice | choice from your values, plus probabilities over all of them and a confidence | Department routing, content category, document type |
score | score, the probability-weighted average of the level indices, plus probabilities and confidence | Severity, urgency, any ordered rubric |
OpenAI’s routing example sends a one-line complaint and four departments:
curl https://api.openai.com/v1/decisions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"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": [
{"value": "billing", "description": "Payments, invoices, and refunds."},
{"value": "technical", "description": "Problems using the product."},
{"value": "shipping", "description": "Delivery and tracking."},
{"value": "other", "description": "Requests outside these categories."}
]
}]
}'The illustrative answer is billing with a confidence of 0.93. The score type behaves differently from a plain label: in OpenAI’s severity example, probabilities of 0.1, 0.7 and 0.2 across cosmetic, workaround available and fully blocked produce a score of 1.1, between the second and third level. That is the point of the type: a number you can sort and threshold rather than a bucket, with the per-level probabilities showing how spread the model’s view was. Decisions guide
Four rules from the guide shape how you design around it. Questions that depend on an earlier answer need a separate request, so a two-stage triage (is this damaged, then which repair category) is two calls. In the beta, images had to be inline base64 data URLs; hosted URLs and file_id references were rejected, so you re-sent the bytes every time rather than referencing an upload (the GA guide accepts public HTTP and HTTPS image URLs; see the update). OpenAI recommends a fallback option such as “other” whenever your categories might not cover every input. And the SDK examples check for an answer of type refusal before reading a result, so a classifier built on this needs a branch for the model declining to answer. Decisions guide
The guide draws its own boundary with the rest of the platform. Use Decisions when the application needs one of the three answer types. Use Structured Outputs on the Responses API when you need an object that follows your own JSON schema, such as extracted fields or a written explanation, and function calling when the model should request a tool call with arguments. Decisions guide In practice that means Decisions replaces the enum-only slice of structured output work. Anything that also pulls out a name, a date or a reason stays where it is.
The cost comparison
The beta guide’s pricing paragraph was short: with gpt-6-luna, input costs $0.10 per million tokens, and “You pay only for input tokens: there are no cache-read, cache-write, or output-token charges.” (The GA guide replaced that sentence; the update below has the new wording.) Regional processing premiums and long-context input multipliers still apply. Decisions guide From the pricing and data-controls pages, those are a 10% uplift on regional-processing (data-residency) endpoints for models released on or after March 5, 2026, and doubled input and cache rates on prompts above 272,000 input tokens. Pricing Data controls GPT-6 Luna model page Neither page says outright whether Luna falls under the 10% uplift, so the data-residency figures below assume it does. The pricing page itself has no Decisions row yet, and the Luna model page still lists Chat Completions, Responses and Batch as its endpoints without /v1/decisions; the guide is the only place the price appears.
Take a worked example: one million support tickets, 500 input tokens each, routed to a department. That is 500 million input tokens.
| Route | Input | Output | Total |
|---|---|---|---|
| Decisions, Luna | $50 | $0 | $50 |
| Decisions, data-residency endpoint (assumes the 10% uplift applies) | $55 | $0 | $55 |
Responses + structured output, Luna, reasoning.effort: none, ~20 output tokens | $50 | $10 | $60 |
Responses + structured output, Luna, default medium effort, 200 reasoning tokens assumed | $50 | $110 | $160 |
Input is identical on both routes because the rate is the same $0.10. The difference is entirely the output side. A minimal JSON answer like {"department":"billing"} is about 20 tokens, which costs $10 per million tickets at Luna’s $0.50 output rate. Reasoning tokens are also billed as output tokens, and Luna defaults to medium effort, so a Responses call that is allowed to think before it answers can multiply that line. Reasoning guide GPT-6 Luna model page The 200-token reasoning figure in the last row is an assumption to show the shape of the cost, not a measurement; your own usage logs will give the real number. The guide does not say what effort, if any, the Decisions endpoint applies internally, and documents no parameter to set it.
On a short-input, label-only job, then, Decisions saves the cost of the output tokens: about a sixth of the bill against a Responses call with reasoning off, and much more against one with reasoning on. That is real money at scale and close to nothing at a few thousand calls a day.
The comparison turned over when the shared context was large. In the beta, Decisions had no cache, so every token in every request was billed at $0.10. (GA added a cache; the update below reworks this table.) The Responses API bills cached input to Luna at $0.01. Pricing Put a 4,000-token policy document in front of each 500-token ticket:
| Route | Shared prefix | Ticket | Output | Total per 1M tickets |
|---|---|---|---|---|
| Decisions | 4,000M × $0.10 = $400 | $50 | $0 | $450 |
| Responses, every call a cache hit, effort none | 4,000M × $0.01 = $40 | $50 | $10 | $100 |
That assumes a cache hit on every call and ignores the one-off cache write, so it is the best case for Responses. The arithmetic favors Responses from a prefix of little more than a hundred tokens, but caching only applies from 1,024 tokens on GPT-5.6 and later, and reuse needs the entire rendered prefix to match, so the practical crossover sits around that minimum. Prompt caching guide Decisions is the cheaper route when the input is mostly the thing being judged. When the input is mostly a reusable rulebook, the Responses API with caching wins, and a long rulebook is how many moderation and compliance prompts are written. The guide does not say whether the questions block, with its choice descriptions, is metered as input; assume it is, and keep the descriptions short.
The speed claim and its basis
The guide’s first sentence is the claim: the Decisions API “returns typed answers about 10x faster than the Responses API”, and the changelog entry repeats “10x faster than the Responses API”. Decisions guide API changelog Neither page says which Responses configuration it is measured against, at what effort setting or input size, or whether the comparison is time to first token or time to a complete parsed answer. Our DevDay article relayed a secondhand version, ten times faster than Luna through the regular API, from The Decoder; the published docs compare against the Responses API, and that is the wording to use.
The mechanism is plausible, since a Responses call generates the JSON token by token, possibly after hidden reasoning tokens, while a Decisions call reads the input and emits a distribution over a fixed set. A plausible mechanism is still not a measurement. For a routing step inside a latency budget, run both against the same hundred inputs and record p50 and p95 end to end, with the Responses side at none effort as well as the default, so the comparison is against the fastest configuration you would have used.
What the probabilities are good for
The guide is careful about what the probabilities are. A predicate’s probability is “the model’s estimate that the condition is true”; choice and score answers come with a distribution and a separate confidence. It makes no calibration claim. Its advice is to use labeled examples from your own application to set thresholds for routing, filtering or review, chosen on the cost of false positives against false negatives. Decisions guide
That is the right advice, and it is more work than the JSON-mode version of the same classifier, where the output is a label and the threshold is implicit. Treat the number as a ranking signal until you have checked it: run a few hundred historical tickets with known departments and watch accuracy as you move the confidence cutoff, routing everything below it to a person. If the probabilities are reasonably calibrated on your data, the score type gives you a severity queue for free. If not, you still have a usable classifier with an empirically set cutoff.
Two design notes follow from the guide’s own rules. Keep one concern per question: a damage check and a product-category check belong in the same request as two questions, but “is it damaged and is it a return” as one predicate gives you a probability of an ambiguous conjunction. And define adjacent score levels so that they have distinct criteria, because the score is an average across them and blurry levels produce a blurry number.
What else changed on the same day
The October 6 changelog carries a second entry: API usage tiers went from five to three, named Build, Launch and Grow, with an organization’s tier upgrading automatically as its cumulative credit purchases reach each threshold. API changelog Rate limits guide The rate-limits page has the thresholds and per-model limits; they are the kind of figure that moves, so check that page rather than this one. The Decisions endpoint is not mentioned there, and the guide publishes no rate limit for it.
A day earlier, October 5, OpenAI added a self-serve flow under API Organization settings > General where admins of eligible organizations can accept the standard Business Associate Agreement. API changelog That matters here because the data-controls page lists /v1/decisions as eligible for HIPAA use under an executed BAA and healthcare addendum, as ZDR-eligible with a caveat about prompt caching state, and as supported for US and EU residency and regional processing. Data controls A healthcare intake triage on this endpoint is possible on paper from day one of the beta; any residency uplift is the 10% above.
The open-weight alternatives
Cloudflare’s Clef, a 27B decision model on Workers AI, takes the same shape of request, a state plus typed questions, and returns a probability per allowed answer, at $0.24 per million input tokens with a 65,536-token context and no output price listed. Clef on Workers AI Liquid AI published d1-3B, an open-weight decision model that answers “in a single forward pass” rather than producing tokens, on October 7. Liquid AI on Hugging Face Those run where you choose, which the Decisions API cannot, and they come with published latency and benchmark figures of their own. Our open decision models comparison sets Clef, Clef-flash, Liquid d1 and TypeSafe’s Jev against this endpoint on license, price, context and input types.
What to check before moving a classifier
Start with the shape of the prompt, since that decides the bill. If the per-item input outweighs the shared instructions, Decisions is cheaper on list price. If the instructions outweigh the item and you already get cache hits on the Responses API, it probably was not, during the beta; a $0.01 cached rate is hard to beat with a $0.10 uncached one. Both routes cache since GA, which changes this test (see the update).
Then check what the step actually returns. If downstream code consumes only a label or a number, the move is clean. If it also consumes a field the model extracted or a sentence it wrote, you would be paying for two calls where one worked, and the guide itself points you back to Structured Outputs for that.
Last, test the probabilities on your own labeled data before trusting a threshold, time both routes on the same inputs rather than taking 10x on faith, and note the constraints as they stood in the beta: one model, base64 images only, no cache, no stated rate limit, and GA “in the coming weeks”. GA on October 22 cleared three of the five; the single model and the unpublished rate limit still stand (see the update). The endpoint fits high-volume routing, moderation, lead scoring and relevance filtering where the input is short and the answer is a pick. It fits less well than it first looks when a long rulebook sits in front of every call.
Update, October 23: GA, a priced cache and the 12-hour question
OpenAI took the Decisions API out of beta on October 22. The changelog entry says “The Decisions API is now generally available with gpt-6-luna,” and lists what shipped with it: prompt-cache discounts for shared input, images inside per-question instructions, and an input_json input. A request can now carry up to 400 questions, which the guide says is “up from 200 during the public beta”. API changelog Decisions guide Two things did not change: gpt-6-luna is still “the only currently supported model”, and the speed claim is still “about 10x faster than the Responses API” with no method attached.
The GA guide corrects two things in our beta coverage. Images no longer have to be base64: the guide accepts public HTTP and HTTPS URLs as well as inline data URLs. And the 200-question cap the GA guide attributes to the beta was not in the beta guide when we read it on October 7, so the statement in our open models article that the guide published no maximum was right at the time and is now superseded. We have not examined the input_json schema and do not describe it.
| Date | Change |
|---|---|
| September 22 | GPT-6 Luna released at $0.10 input, $0.01 cached, $0.50 output per million tokens |
| October 6 | Decisions API public beta |
| October 15 | Native Decisions integration in GPT-Live |
| October 20 | 12-hour prompt caching option |
| October 22 | Decisions API GA; 400 questions per request, priced cache, image URLs, input_json |
Dates from the API changelog. The October 15 entry adds a native Decisions integration to GPT-Live; the entry we read says no more about how questions are passed, so we leave it at that.
What changed on the bill
Uncached input is still $0.10 per million tokens and output tokens are still not charged. The difference is the cache. The GA guide says cache hits get discounted input pricing and cache writes are charged, where the beta text said neither existed; regional processing premiums and long-context multipliers still apply. Decisions guide The guide does not print the cache rates, but it says “Cache-read and cache-write rates match the standard gpt-6-luna prompt caching rates.” The pricing page still has no Decisions row, and the Luna model page still lists no /v1/decisions endpoint. Pricing GPT-6 Luna model page Those standard rates are $0.01 per million cached input tokens, $0.125 per million for a 30-minute cache write and $0.25 for a 12-hour write. The arithmetic in this section uses them.
The guide does say where the cache sits: “By default, Decisions places an implicit cache breakpoint at the end of shared input”, and the reusable prefix has to be at least 1,024 tokens. Decisions guide So the rulebook case that went against Decisions in the beta now reads differently. Same example as above, a 4,000-token policy document in front of each 500-token ticket, one million tickets:
| Route | Shared prefix | Ticket | Output | Total per 1M tickets |
|---|---|---|---|---|
| Decisions, beta (no cache) | 4,000M × $0.10 = $400 | $50 | $0 | $450 |
| Decisions, GA, every call a cache hit, Luna’s $0.01 rate assumed | 4,000M × $0.01 = $40 | $50 | $0 | $90 |
| Responses, every call a cache hit, effort none | 4,000M × $0.01 = $40 | $50 | $10 | $100 |
Both cached rows assume a hit on every call and ignore the one-off write. On those assumptions the shape of the prompt no longer decides between the routes, since both cache the rulebook at the same rate; what is left is the output side, and Decisions has none. The advice above to prefer Responses when the instructions outweigh the item was correct for the beta and no longer holds on list price.
The 12-hour cache and when it pays
On October 20 OpenAI added a 12-hour retention option to prompt caching, selected with prompt_cache_options.ttl on the request or prompt_cache_breakpoint.ttl on a breakpoint. The default is "30m", and an unsupported value returns a 400 invalid_request_error. Writes are priced by lifetime: the changelog says “12-hour cache writes cost 2.5x the input token price”, and the guide calls these “total write rates, not surcharges”. Reads are 0.1x the input price on most models whatever the lifetime (0.05x on GPT-6.1 Sol), and the minimum cacheable prefix is 1,024 tokens “for GPT-5.6 and later”. Prompt caching guide API changelog On Luna Standard that is $0.125 per million tokens for a 30-minute write and $0.25 for a 12-hour one, against $0.01 to read and $0.10 uncached. Pricing
Whether /v1/decisions accepts the 12-hour option is not stated anywhere we looked: the Decisions guide never mentions a TTL and the caching guide never mentions Decisions. The arithmetic below is ours, on Luna’s listed rates, for a one-million-token prefix, and it ignores whether a cache hit refreshes the window, which neither guide says.
| Use of the same prefix within 12 hours | 30-minute cache | 12-hour cache | No cache |
|---|---|---|---|
| Twice, under 30 minutes apart | $0.135 | $0.26 | $0.20 |
| Twice, more than 30 minutes apart | $0.25 | $0.26 | $0.20 |
| Three times, two gaps over 30 minutes | $0.375 | $0.27 | $0.30 |
The 12-hour write costs $0.125 more than a 30-minute write, and each 30-minute expiry it prevents saves one rewrite, also $0.125, less the $0.01 read that replaces it. One avoided expiry therefore leaves the 12-hour option a cent behind; it only wins when the 30-minute cache would have expired at least twice inside the window. Steady traffic that touches the prefix at least every half hour never expires it, so the 30-minute cache is strictly cheaper there, and the 12-hour option is for prefixes used a few times a day with long gaps between. Against no cache at all, a 12-hour write plus n reads costs $0.25 + $0.01n against $0.10(n + 1) uncached; the two are equal at about 1.67 reads after the write, so the 12-hour cache beats paying full price from the third use of the prefix. The 30-minute cache clears the same bar sooner: a write and one read, $0.135, already beats two uncached passes at $0.20.
Rate limits, tiers and what the docs still do not say
The Decisions guide publishes no rate limit and the rate-limits guide does not mention Decisions, so the endpoint’s limits are still unpublished at GA. For Luna on the Standard tier the rate-limits guide lists Build at 5,000 requests and 2 million tokens per minute, Launch at 10,000 and 10 million, and Grow at 30,000 and 180 million; whether /v1/decisions shares those or has its own is not stated. Rate limits guide One discrepancy with the section above: the rate-limits guide we read on October 23 lists four usage tiers, Free, Build, Launch and Grow, where the October 6 changelog described three. We have not worked out whether Free was added since or sat outside the changelog’s count, so take the tier names from the guide, not from this article.
Also unstated: whether Decisions can use Luna’s Batch, Flex or Fast tiers (Batch and Flex list input at $0.05 and cached input at $0.005, half the Standard rates), and whether the 10% regional-processing uplift applies to Luna, which the pricing page ties to models released on or after March 5, 2026 without naming Luna. Luna’s September 22 release date makes the uplift likely, but that is our inference, not a line on the page. Pricing
For a team that built on the beta, the practical changes are these: requests that were split to stay under the question count can carry up to 400 questions; images can be referenced by URL instead of re-sent as bytes; the rulebook cost comparison needs re-running with the cache, which now favors Decisions on list price; and the Responses fallback is still worth keeping wired up until the rate limits are published. On the open side, two more Apache 2.0 decision models arrived since October 7, vLLM Semantic Router’s d3 and Perplexity’s pplx-decider, both now on Ollama; the October 23 update to our open decision models comparison covers them, and Granite Switch 4.1 covers IBM’s decision adapters.
Key details
| Item | Detail |
|---|---|
| Endpoint | POST /v1/decisions, public beta from October 6, 2026; generally available from October 22, 2026 |
| Model | gpt-6-luna only (beta and GA) |
| Question types | predicate (probability), choice (choice, probabilities, confidence), score (weighted average of level indices, probabilities, confidence) |
| Input | Beta: text, or user messages with text and base64 image data URLs; no hosted image URLs, no file_id. GA: public HTTP/HTTPS image URLs accepted, images allowed in per-question instructions, input_json added |
| Questions per request | GA guide: up to 400, “up from 200 during the public beta” |
| Price | $0.10 per million uncached input tokens; no output charge. Beta: no cache-read or cache-write charges. GA: cache hits discounted, cache writes charged (rates not printed; the guide says they match Luna’s standard prompt-caching rates). 10% data-residency uplift for models released on or after March 5, 2026 (not confirmed for Luna); long-context multiplier above 272K input tokens |
| Speed | OpenAI: “about 10x faster than the Responses API”; no method published |
| Data controls | ZDR and HIPAA for eligible customers; US and EU (EEA + Switzerland) residency |
| Same-day changes | Usage tiers reduced to Build, Launch and Grow (Oct 6); self-serve BAA acceptance in Organization settings (Oct 5) |
| SDK minimums | Python 3.26.0, JavaScript 7.30.0, Go 3.73.0, Ruby 0.101.0, Java 4.78.0 |
Sources
- Decisions API guide — OpenAI Developers
- API changelog — OpenAI Developers
- Pricing — OpenAI Developers
- GPT-6 Luna model page — OpenAI Developers
- Reasoning guide — OpenAI Developers
- Rate limits and usage tiers — OpenAI Developers
- Prompt caching guide — OpenAI Developers
- Data controls — OpenAI Developers
- Clef model page — Cloudflare Workers AI