OpenAI's Decisions API Puts a Typed Endpoint on gpt-6-luna

On October 6, OpenAI moved its Decisions API into public beta after showing a limited preview at DevDay in late September. It's a dedicated endpoint at POST https://api.openai.com/v1/decisions. For now it runs exactly one model: gpt-6-luna.

You define questions over text or image input and get typed answers back. A predicate returns the probability that a statement is true. A choice picks one option from a fixed set and attaches a confidence score. A score gives a probability-weighted rating against ordered levels you define. OpenAI's list of intended uses is classifying content, routing requests, prioritizing work, checking conditions and selecting an agent's next action.

Pricing is $0.10 per million input tokens. Output tokens are free, as are cache reads and writes. OpenAI says it's up to 10x faster than calling gpt-6-luna through the standard Responses API. I've also seen one report put it at about 150ms against roughly 1.6s for a normal call, but OpenAI didn't publish that figure in those terms and I wouldn't repeat it as fact. These are vendor numbers. Benchmark them on your own traffic.

Where it differs from Jev

The timing is hard to miss. TypeSafe AI released Jev on September 15 and opened this category, typed questions in and probabilities out. Three weeks later OpenAI has a public beta of the same product shape. Plenty of coverage reads it as a direct response. I haven't found OpenAI saying that, so I'll stick to the dates and the overlap.

What I find more interesting is that the two get there by different routes. Jev is non-generative at the architecture level. Its parallel sampler never produces tokens, which is why it structurally can't return an option you didn't give it.

The Decisions API runs on gpt-6-luna, which is a generative model. OpenAI puts it behind a separate endpoint that returns its output as predicates, choices and scores. I don't know how that constraint is implemented. It might be constrained decoding over your option set or a scoring head on top of the model. OpenAI hasn't said. I'd rather admit that than guess.

That gap matters for the guarantee I cared about in the Jev post. With Jev, "it can't hallucinate a fifth answer" is a property of the architecture. With the Decisions API you also get typed, probabilistic answers back, but I can't tell you the same property holds for the same reason. It may well behave identically in practice. I'd still want OpenAI to document it before I deleted any validation code.

Picking one now

OpenAI's advantage is distribution. If your stack already runs on their platform, this is one more endpoint on an account you already have. TypeSafe has a head start and a more specific architectural guarantee, which is the thing I'd weigh most for a gatekeeper sitting in front of tool calls.

The Decisions API is also still a beta. OpenAI said general availability was expected in the coming weeks. As of my last check there's no GA entry in their changelog. One supported model behind a beta endpoint is fine for a prototype. I'd be slower to put it on a hot path.

Whichever one I picked, the integration would look the same. A cheap typed decision runs in front of the expensive generative call. A confidence threshold sends unsure cases to a human or a bigger model. I'd write that layer against my own interface so swapping the backend is a config change. Behind that interface I'd keep checking the returned option against the allowed set no matter which vendor answers, because only one of them has explained why the check is unnecessary.