OpenAI opened the Decisions API to every developer on Tuesday 6 October. It is a POST /v1/decisions endpoint on gpt-6-luna that returns a probability, a choice or a score instead of text, "about 10x faster than the Responses API," at $0.10 per million input tokens with no output, cache-read or cache-write charges.
The guide says choice answers carry "probabilities over discrete options" and a confidence field it never defines. A developer on OpenAI's forum ran a coin biased to 70% heads through both question types. The predicate came back at 70% across 1,000 trials. The choice format picked heads 98% of the time, and the probabilities changed when the options were reordered.
The endpoint has no prompt caching, so it charges full price for the shared rubric that the Responses API lets you read back at a cent. For a classifier with a 4,000-token prompt per item, the output-free endpoint costs about five times more per call than Luna through Responses. It is cheaper only when your output would have exceeded 18% of your cached prefix.
What the endpoint does
A request has three fields: model, input and questions. The input is a string or user messages with input_text and input_image parts. Images must be inline base64 data URLs; hosted URLs and file_id inputs are refused. Each question has a type, a unique name that is echoed in the response, instructions, and either choices or levels.
A predicate returns a probability from 0 to 1. A choice returns one of your values plus probabilities and confidence. A score returns "the probability-weighted average of the level indices," so probabilities of 0.1, 0.7 and 0.2 across three levels produce a score of 1.1. Independent questions share one array; "dependent decisions require separate requests." A fourth answer type, refusal, can come back for one question while the others are answered.
OpenAI showed the endpoint at DevDay on 29 September as a limited preview. The guide now says "we expect to GA in the coming weeks." Luna is the only model, and its model page still lists 18 endpoints without v1/decisions. Vercel's AI Gateway files it as a separate model, openai/gpt-6-luna-decisions, with a 1,050,000-token context window and a maximum output of 0 tokens.
The coin
On 7 October a forum user called platypus posted a test built to catch a failure they had already seen in TypeSafe's Jev, the model this endpoint fast-follows and whose maker raised $870 million last week. "The predicate seems to follow more closely expected results, while choice seems to put too much probability mass on the most likely outcome."
The setup was a loaded coin that shows heads 70% of the time. Asked as a predicate across 1,000 trials, the API returned heads 70% of the time. Asked as a choice between heads and tails, it returned heads 98% of the time. An edit a few minutes later: "The plot thickens - choice order changes the probabilities." Another user, VeitB, summarised the behaviour as "optimizing for the most likely outcome" and "clearly not estimating the probability of the next flip being heads at ~70%." platypus agreed: "it's not estimating the true posterior at all." Their verdict: "don't use choice questions," with the note that "Jev isn't any better."
The documentation says nothing about calibration. The only sentence on interpretation is "Use labeled examples from your application to set thresholds for routing, filtering, or review." The guide groups choice and score together as the two types that "return probabilities over discrete options," so the question hangs over score too; the coin test covered only choice.
The confidence field is the other gap. OpenAI's guide describes it as "a separate confidence field" and stops. TypeSafe's docs define theirs: for a choice with n options and a top probability of p, confidence is (p minus 1/n) divided by (1 minus 1/n), computed from the distribution you already have. Until OpenAI publishes an equivalent, you cannot know whether a 0.9 from one vendor means what a 0.9 from the other does.
Two measurements from the same week point in different directions. Abnormal's Shrivu Shankar ran 1,985 synthetic emails through 40 models on 8 October and called the Decisions API "the standout, catching most of what luna-6-max does at a fraction of the cost and latency" at 99% precision, with the decision APIs "generally among the best calibrated." Anthus's Ryan Porter, writing on 1 October before the beta opened, ran Luna through the Responses API on 3,600 logic problems: 64% accuracy against Jev's 84%, and when Luna stated 99% or more it was right 68% of the time. Same model, different interface and task. Calibration shows up on one workload and not the other, and the endpoint promises it on neither.
Ten times faster than what
The forum announcement says "up to 10x faster than GPT-6 Luna through the Responses API." The guide says "about 10x faster." Neither gives a number, a payload size or a percentile.
The first-hand figures came from the Hacker News thread, which reached 391 points and 231 comments, and from OpenAI's forum. One developer measured 160 to 175 ms end to end, with the worst 5% at 285 ms and a worst case of 743 ms. Another, calling through OpenRouter, saw 346 ms at p50 and 860 ms at p95, slower than Jev on the same evals. A third, in multi-step conversational play, measured a median turn of 1.6 seconds against Jev's 0.3. With image inputs on a 3 Mbps connection it answered in about 0.8 seconds.
That is a tenfold spread between reports, the same ratio as the headline. Where you call from and what you send matter more than the claim. What the endpoint has that Jev lacks is image input and Luna's million-token window; Jev's docs cap a request at 64k tokens.
The bill
Luna costs $0.10 per million input tokens through this endpoint and nothing else, with "regional processing premiums and long-context input pricing multipliers" still applying, so a prompt over 272,000 tokens pays $0.20. Jev lists at $0.042 per million input with free output. Two people in the Hacker News thread who ran the same workloads on both put Luna at two to three times Jev's cost.
The sharper comparison is with Luna itself. On 7 October a forum user asked whether the missing cached-input rate was expected, and VeitB confirmed: "there's currently no caching available for the Decisions API." The reply: it "makes classification tasks economically unattractive to switch from luna responses api to decisions api."
The arithmetic bears that out. Through the Responses API, Luna charges $0.10 per million input, $0.01 for cached input and $0.50 for output. A classifier that sends a 4,000-token rubric and a 500-token item, and gets ten tokens back with reasoning off, costs about $0.000095 per call with the rubric cached. Through Decisions the same 4,500 tokens cost $0.00045. Per million items that is $95 against $450.
The output-free endpoint beats the cached one only when your output tokens exceed 18% of your cached prefix: 720 output tokens per item for a 4,000-token rubric. Classification does not produce that. The endpoint is marketed for the workload where a long shared prompt and a short answer are the norm, and that is the shape its pricing penalises. Each dependent follow-up question re-sends and re-bills the whole input too.
What to do with this
Run the coin before you run the rubric. A predicate and a choice over the same biased input, 1,000 calls each, is about 60,000 tokens and costs under a cent. Then reverse the option order and run it again. If the choice probabilities move, you have your answer about thresholds.
Prefer predicates for anything you intend to threshold. The first working example posted in the Hacker News thread used two predicates, "Is this a complaint?" and "Is this a compliment?", rather than one choice between them. That is the safer pattern until the choice distribution is explained.
Price the prefix. Count the tokens in your shared instructions and compare them with your output: Decisions wins only when the prefix is shorter than about five and a half times the output. For most routing and moderation calls, Luna through Responses with the rubric cached is the cheaper way to get the same model's answer, at the speed cost the headline describes.
Treat confidence as an opaque number until OpenAI defines it. Log it next to the top probability for a week. If the two move together you have TypeSafe's formula. If not, you have a number you cannot name, and it should not be deciding anything.