AI
Teknosfera Newsroom
AI

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.

Published
October 23, 2026
Reading time
4 min
Categories
AI

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.

Debate topics

No topics yet: start the first one.

More stories