OpenAI's Decisions API sells verdicts, not chat: demand audit trails first
By returning probabilities and scores instead of prose, OpenAI's Decisions API turns language models into control-flow plumbing, and plumbing needs inspection before it touches anything important.
AI-generated image
What happens when the most famous AI company stops selling you a conversation and starts selling you a number? You get the Decisions API, and in our view it is a more consequential product than another chatbot upgrade, precisely because it is so boring.
Quick recap. OpenAI announced general availability of the Decisions API, built on GPT-6 Luna. You define a question and its allowed answers, hand over text, images or JSON, and get back one of three typed answers: a probability that a condition is true, a choice from your list, or a score against a rubric. OpenAI says it is up to 10x faster than Luna through the Responses API, with up to 400 questions per request and a price of $0.10 per million input tokens, with no output-token charges.
The chatbot was the demo; this is the product
Look at the examples OpenAI itself gives: classify an input, route a request, decide whether an agent should continue, retry or ask for clarification. None of that is conversation. It is control flow, the if statements of software, now outsourced to a model. The company's own teams use it to categorize transactions and to classify press coverage, helping identify what "warrants closer review."
That is the shift. An assistant talks to a person, who can notice when it sounds off. A decision endpoint talks to code, and code does not raise an eyebrow. A probability flows into a branch and something happens. We think this is where a lot of AI's real economic weight will end up: not in the chat window, but in thousands of invisible micro-judgments per minute.
The design is smart, to be fair. Dropping the prompt-parse-retry loop removes a whole class of formatting bugs, and the documentation is explicit that your application runs any actions the answers select. That is the right division of labor.
A probability is not a guarantee, and the word "confidence" is doing a lot of work
Here is our worry. A number looks more rigorous than a paragraph. It is not necessarily so. A Firecrawl analysis quotes a Hacker News commenter making the sharp point that this kind of constraint guarantees formatting, not correctness. We agree with the spirit of that objection, even if bounding the answer space is a genuine efficiency gain.
The key question is calibration: when the model says 0.90, is it right about 90% of the time on your data? Nothing in the material we reviewed answers that. CometAPI's comparison notes that the vendor figures do not establish an accuracy winner against the rival Jev, and warns against treating an API field called confidence as if it were calibrated probability without checking its definition. The speed claim is similar: it compares OpenAI's model with itself, not with the market.
So the sensible reading is that the 10x figure is real marketing and probably real engineering, while reliability on your particular tickets, photos and refunds is an open, empirical question that only you can close.
What developers should demand before wiring this to anything that matters
First, keep authority in your code. A model can say a ticket looks like a duplicate charge; only an authorized service or a human should issue the refund. A high score must never grant a permission the system did not already hold.
Second, log everything: the question text, the answer options, the model identifier, the input evidence and the returned probabilities. Version the rubric like you version code, because changing the options changes what historical results mean. If a decision is ever disputed, you should be able to replay it.
Third, measure before trusting. Label a sample of real traffic, check calibration, set review thresholds from that data, and send uncertain cases to people. Cheap per-token pricing is tempting, but the real cost is what a misroute or a wrong auto-approval costs downstream.
Fourth, and this is our ask to OpenAI: give builders more than a number. The endpoint is designed to return no explanation, which is exactly why it is fast, and exactly why it is hard to audit. Fine for classifying coverage themes; much less fine for anything touching money, safety or people's access to services.
Our verdict
Use it. For high-volume, low-stakes routing it looks like a clear win, and competition from specialized models like Jev should keep prices honest. But treat it as a fast, fallible advisor sitting on a leash of deterministic rules, with a paper trail you control. The era of AI as decision infrastructure has arrived; the audit habits have to arrive with it, and nobody is going to ship them for you.
No topics yet: start the first one.
More stories
Sweden's chatbot ban is a reflex, not a policy, and staff will route around it
Blocking ChatGPT and Claude on Swedish government computers is understandable, but without a sanctioned, auditable alternative it risks pushing AI use out of sight.
Sovereign AI isn't a slogan: Germany just showed it's a purchasing problem
Ecosia dumping Mistral and Berlin courting Nvidia aren't betrayals. They show Europe should pick which dependencies to cut instead of chasing sovereignty from chips to apps.
China's open AI edge may become a bargaining chip, not a gift
Beijing's draft export controls would turn cheap open models into a geopolitical lever, just as Huawei and DeepSeek build a parallel stack. Plan for supply risk.
Claude Duet’s real test is whether AI can leave you in control
Anthropic’s proactive agent is more than a chat window, but its success will depend on judgment, clear approvals, and whether background automation preserves human agency.



