OpenAI's Decisions API Is Now a Public Beta — and Its Price Is Not What Launch Coverage Guessed

Eight days after the vendor showed the Decisions API at DevDay, it stopped being a thing you had to be invited to. The endpoint went into public beta on October 6, 2026, alongside a documentation page, a Playground link, and the first published price for the service. Two details in that release matter more than the rest. The first is that GPT-6 Luna is the only model the endpoint will accept — so the API's capabilities and its ceiling are, for now, the same thing. The second is that the launch-day arithmetic almost everyone did, including ours, was wrong in a way worth correcting: the first wave of coverage inferred the per-call cost by pointing at the Luna token rate card, and that inference turns out to understate the discount by a factor of five.

None of what follows is speculation. It is all readable today on OpenAI's own developer documentation, which is the change: on September 30 there was no documentation page for this endpoint anywhere in OpenAI's docs, no changelog entry, no rate, and no stated request shape. There is now all four.

What shipped, precisely

The beta is a dedicated endpoint — POST /v1/decisions — and it is not a mode on the Responses API, which is the thing it is measured against. A request carries three fields:

• model — currently gpt-6-luna and nothing else
• input — the shared evidence: a text string, or user messages containing text and images
• questions — one or more questions, each with a type, instructions, and any allowed options

The response is an answers array, one entry per question, keyed by whatever name you gave each one. That is the whole contract, and the interesting engineering is in the three question types rather than in the plumbing.

• predicate — returns a probability from 0 to 1 that a stated condition holds. "Does this product photo show visible damage?" The example in the docs returns 0.92 and tells you to compare it against a threshold you chose.
• choice — returns one value from a set you supply, plus a probability distribution across all the options and a separate confidence field. The docs' example routes a billing complaint into billing at 0.95.
• score — returns a probability-weighted average across ordered levels. Feed it three severity levels — cosmetic, workaround available, fully blocked — and probabilities of 0.1, 0.7 and 0.2 come back as a score of 1.1, which sits deliberately between two levels rather than snapping to one.

The price is lower than the obvious guess, and the billing shape is different

Here is the correction. When the Decisions API was in limited preview, the honest position was that no price existed and that anyone quoting one was inferring it. The natural inference was Luna's token rates: $0.10 per million input tokens and $0.50 per million output. That is not how the endpoint bills.

The documented rate for /v1/decisions with gpt-6-luna is $0.10 per million input tokens, with no output charge at all, and no cache-read or cache-write charge either. You pay for the evidence you send, not for the answer that comes back. Read against the model's own rate card — where output is five times the input price and cache reads are a tenth of it — that is a materially different cost profile, and it is a better one for exactly the workload the endpoint is aimed at, where the input is a paragraph or an image and the output is a single token's worth of decision.

Two caveats sit on top of that figure and both are stated by OpenAI rather than inferred: regional processing premiums and long-context input multipliers still apply, and the static $0.10 is specifically the /v1/decisions rate — other requests using gpt-6-luna follow the ordinary model and processing-tier pricing.

If you were sizing this against the Luna rate card on the assumption that a decision costs an input plus an output, re-run the number. It is roughly a fifth of what that model implies, before the long-context tier is considered.

The latency claim, restated

The other thing that changed is the phrasing of the central performance claim, and the change is subtle enough to be worth flagging because it shifts what is being compared.

OpenAI's launch copy said the Decisions API makes decisions "up to 10x faster than GPT-6 Luna through the Responses API." The documentation now leads with: the API "evaluates text, images, or both and returns typed answers about 10x faster than the Responses API."

Those are not the same sentence. The first compares a constrained-decision endpoint against a full generative call and credits the difference to the endpoint. The second compares the endpoint against the Responses API generally. Either way the number remains vendor-stated and unreproduced — no distribution, no region, no input size, no concurrency level, no service-level agreement — and a single median is still the wrong figure to build a deadline around. If your decision sits between a click and a payment, measure your own p95 and p99 with your own images.

What genuinely improved is that the question is now answerable at all. In preview you could not test this without access. In public beta you can.

Where it runs, and the one thing to keep beside it

Two operational notes from the docs that are easy to skim past. The endpoint supports Zero Data Retention and HIPAA use for eligible customers, and data residency is offered in the United States and Europe — specifically the EEA plus Switzerland. Those are eligibility-gated rather than defaults, so read the data-controls page before you assume either applies to your account.

There is also a companion guide for wiring the endpoint to the Live API, so a voice request can be turned into a chosen action whose result is then reported back to the speaker. That is the most interesting second-order use of the primitive: not "classify this ticket" but "decide what the agent should do next, out loud, in a conversation."

The API is OpenAI's own packaging and we do not route it; if you want this specific endpoint, OpenAI is where it lives. The model underneath is a different matter — GPT-6 Luna is a live route on OrcaRouter at OpenAI's list price with zero markup passed through, and because the endpoint's own limits can move during a beta, the sensible shape for a production rollout is a constrained decision on the critical path with a prompt-based fallback already warm behind it. Keeping that fallback on the same key as everything else means no second contract and no rewrite of the fallback path when a preview changes its limits.

What to do this week, and what is still missing

The honest summary of the state of things: two of the four blanks from launch have been filled and two have not. Price is published, the request shape is published, the three question types are documented with worked examples, and the data-handling story is at least stated. What is still absent is any published limit on how many candidate answers a single request can carry, any statement on whether you can tune the thing on your own labelled data, and — because it is a beta by OpenAI's own description — any commitment that the rate you are reading today survives to general availability.

That makes the calculus straightforward rather than dramatic. If your problem is classification or routing at volume, where a wrong branch is cheap and reversible, public beta is now genuinely buildable and the input-only pricing makes the arithmetic unusually forgiving. If your decision authorises money or messages a customer, the endpoint has stopped being unknowable but it has not yet stopped being a beta, and the difference between those two things is the difference between a prototype and a load-bearing dependency.