OpenAI Decisions API Goes GA: Cost, Limits and Uses

On October 22, 2026 OpenAI's API changelog marked the Decisions API generally available with GPT-6 Luna, sixteen days after the public beta entry of October 6. The endpoint does one thing: given text, images or JSON and a list of typed questions, it returns a probability, a choice from your options or a score against your rubric, with no generated prose. OpenAI's own claim is that this runs up to ten times faster than asking the same model through the Responses API.

The category is not new, and we have covered it from the first router listings through the Microsoft Decision 1 comparison written against the beta. What is new is the set of production features that arrived with general availability, and three of them change the arithmetic a team did in October's first half: prompt caching on the shared evidence, native JSON input that removes a serialisation step, and a 400-question ceiling that halves the request count for a wide rubric. The rest are the ones procurement asks about: US and EU processing, a Private Link path and an organisation usage endpoint, alongside zero data retention and HIPAA support for eligible customers.

This post is written for the builder routing requests, triaging tickets, or gating an agent's next step, who skipped the beta and wants to know whether GA is the moment to adopt. It takes the changes one at a time, prices a hypothetical router with the arithmetic shown, explains how the caching rules interact with the request shape, and ends with what GA does and does not settle.

The Decisions guide opens with a "what's new since public beta" list, and the API changelog dates the pieces: the beta on October 6, the native GPT-Live integration on October 15, and GA on October 22. The table lays the additions out by what each one changes for an integration, because they are not all the same kind of change. Three move the bill, two move the request shape, and the rest move the compliance conversation.

Nothing here changed at GA, but it frames everything that did. A predicate question returns a probability from 0 to 1 that a condition holds. A choice question returns one of your supplied values, plus a probability for every option and a separate confidence field. A score question returns the probability-weighted average of your ordered level indices, so it can land between levels: the guide's example gives probabilities of 0.1, 0.7 and 0.2 across three severity levels and a score of 1.1. The guide draws the line against Structured Outputs and function calling cleanly: use Decisions when the answer is one of these three types, Structured Outputs when you need an object in your own schema, function calling when you need a tool request with arguments.

The sentence to carry into production is the one on thresholds. The guide says to use labelled examples from your own application to set them, and to choose them by the cost of false positives against false negatives. That is a statement that the probability is a model estimate, not a measured frequency. OpenAI publishes no calibration study for the endpoint. A predicate that says 0.92 for visible damage is not telling you that 92 of 100 such photos are damaged; it is telling you the model's leaning, and the threshold at which you act on it is an empirical decision made against your data. The category explainer in our decision-models primer goes further into why that distinction matters.

The pricing page gives GPT-6 Luna's standard short-context rates as $0.10 per million input tokens, $0.01 per million cached, $0.125 per million for a 30-minute cache write and $0.25 for a 12-hour write. The guide confirms Decisions uses those rates and charges nothing for output. Long-context rows double every input and cache figure, and the guide notes that regional processing premiums apply on top. Those are the inputs; here is a hypothetical to put them to work.

A support router evaluates each incoming ticket against a 2,000-token policy document, with about 300 tokens of ticket text and five questions totalling around 150 tokens. The uncached baseline uses explicit-only mode with no breakpoints, so all 2,450 tokens use the ordinary input rate and none creates a cache write. For the cached case, put an explicit breakpoint after the stable policy and leave the changing ticket outside it. The table assumes a hit on all 2,000 policy tokens; the remaining 450 tokens use the ordinary rate. The cached rows show steady-state costs before initial writes, which must be added when estimating a real bill.

Two readings of the table. The first is the obvious one: at these volumes caching lowers the small-policy example by about 73%, before initial writes, when the evidence is shared. The second is the failure case in the last row. A team that builds its prompt so the reference document comes after the ticket, or that injects a timestamp at the top of the shared input can miss the reusable prefix and pay cache-write rates on the shared input every time under implicit mode. That is the difference between $245 and about $2,553 for the same decisions, because a prefix that changes every call is written to the cache at the write rate and never read. How the prefix is assembled is now a cost decision, which section 04 takes up.

For comparison across vendors, note the unit. Open and third-party decision models in our open decision-model comparison quote per-million-input prices too, and some are lower than $0.10. The comparison is only like for like once you add the cached rate, the regional premium you need and the accuracy on your own labelled set, which none of the vendors publishes for your data.

The Decisions guide's caching section is short and specific, and every sentence in it is a rule you can get wrong. By default the API places an implicit cache breakpoint at the end of the shared input, so existing requests can benefit without changes. The reusable prefix must be at least 1,024 tokens, and question content does not count toward that threshold. Everything in the questions array, including question-specific images, sits outside the reusable prefix. The prefix must be identical across requests to be reused.

Three controls exist for teams that need more than the default. A caller-supplied cache key partitions reuse, so two tenants sharing a policy document do not share a cache entry if you do not want them to. An explicit mode lets you mark breakpoints yourself on text or image parts in the shared input, and in that mode a request with no marked boundary uses no caching at all. Breakpoints are not supported inside question instructions. The usage object reports cached and cache-write token counts, and the guide warns that both are already included in the input total: adding them again double-counts.

The general prompt-caching guide adds the write economics: a 30-minute write costs 1.25 times the uncached rate and a 12-hour write 2.5 times, as total rates rather than surcharges. For a router that runs all day on one policy document, a 12-hour lifetime can reduce repeat writes. Reads still depend on prefix matching and cache availability, so a lifetime setting is not a guarantee of a hit. For a batch job that runs once a night with a different document each time, caching buys nothing and a 12-hour write costs more than not caching. Decide the lifetime by how often the prefix really repeats, not by habit.

The ceiling doubled from 200 to 400 questions per request, and the guide's rule for using it is clear. Independent questions go in one array against shared input: a product photo can be checked for damage and classified by category in one call, and each question can use a different type. Questions that depend on an earlier answer go in separate requests: check for damage first, then decide on a repair category only if it is damaged. The endpoint does not chain; your code does.

Where 400 pays off is a wide rubric over a long document. A content-moderation policy with 300 distinct criteria, a compliance checklist, a quality rubric with many ordered scales: one request, one cached prefix, one round trip. The usage endpoint counts requests rather than questions, so a 400-question request is one entry in the organisation's usage report, which is worth knowing when you attribute cost per project.

The failure case is the tempting one. A team encodes a decision tree as 40 questions in a single request, with instructions like "if the previous answer was yes, then…". The model answers every question independently against the evidence; it has no earlier answer to condition on, so you cannot rely on the dependent questions to enforce your intended branch. Plausible-looking answers do not prove that the decision tree was followed. Split the tree into requests at every branch, and keep the 400 for genuinely parallel questions.

The October 15 addition is the one that opens a new class of use. The voice integration guide describes two patterns. With native delegation, a GPT-Live session calls Decisions directly when it recognises a request your app can handle, choosing among actions you define, with no round trip through your server. With triggers, Decisions runs as transcript deltas arrive, on what the user says or on what Live replies, and your app receives a decision event. The guide's examples are a car assistant that adjusts cabin temperature from "I feel a little cold" and an avatar that picks an expression as the user speaks.

For a customer-support voice agent the practical uses are routing and escalation: decide whether to ask a clarifying question, hand off to a human or continue, while the caller is still talking, so the agent's next turn is already shaped. The guide notes that questions can be changed mid-session with a session update, but the delegation type is fixed when the session is created. The failure case is acting on a partial transcript: a trigger that fires on every delta will see "I want to cancel" before it sees "…my upgrade, not my account". Trigger on turn boundaries for anything consequential and reserve delta triggers for reversible reactions like an avatar's face.

Beta status was a legitimate reason to wait, and the reasons are now mostly gone. The guide states that the Decisions API supports zero data retention and HIPAA use for eligible customers, that data residency is available in all supported API regions, and that regional processing is supported in the United States and Europe, meaning the EEA plus Switzerland. Private Link is listed for teams that need a private connection. The usage endpoint lets an admin key report Decisions token usage and request counts by project, key or model. Those are the items a security review asks for; the guide's what's-new list and the launch post mark Private Link, usage reporting and US and EU processing as additions since the beta.

What GA does not settle is the model question. The guide is explicit that gpt-6-luna is the only supported model, so a team that wants a larger model behind a typed answer has no option on this endpoint. It also does not settle accuracy: no calibration data, no benchmark, and the guide's advice to threshold on your own labelled examples is the whole of the guidance. Our earlier comparison with Microsoft Decision 1 was written against the beta as documented on October 11; the evaluation design it describes, a labelled set and a cost-weighted threshold, remains necessary when deciding whether to use the GA endpoint.

The launch post's own advice for a first integration is sound: start with one recurring decision the application already makes often, define the question, the answers and the evidence that distinguishes them, and test on examples that reflect real usage. The place this most often pays is the gate in front of an agent's expensive step: should this ticket go to the model that drafts a reply at all, is this tool result enough to stop, does this request need a human. A cheap typed answer in front of an expensive generation is the pattern, and it is the one our AI transformation team reaches for first when an agent's bill is dominated by calls that should never have been made.