OpenAI's Decisions API answers yes, no or pick one, and charges only for input. Lead and ticket routing just got simpler

When the job is a label, you should not be paying for a paragraph. OpenAI now agrees.

What happened

OpenAI released the Decisions API in public beta, with general availability expected in the coming weeks according to its docs. It evaluates text, images or both and returns typed answers about 10 times faster than the Responses API.

There are three question types. A predicate returns the probability that a condition is true. A choice picks one option from a fixed set, such as a department. A score rates an input against ordered levels, such as issue severity. You can put several independent questions in one request against the same input.

The only model so far is gpt-6-luna, at $0.10 per million input tokens. There are no output, cache read or cache write charges. Images must be sent as inline base64, not hosted URLs. OpenAI says it supports Zero Data Retention and HIPAA use for eligible customers, with data residency in the US and Europe.

The Decoder calls it OpenAI's response to the decision model trend Jev started in September. Simon Willison notes the API shape is very close to Jev's, with image input as the main difference, and that Jev charges 4.2 cents per million input tokens.

My take

A lot of the AI in real business workflows is routing. Is this inbound lead a fit? Which team owns this ticket? How urgent is this complaint? Is there damage in this photo from the field?

Most teams solve that with a general chat model and a prompt that says reply with one word, then parse the answer and hope. A typed probability is better in two ways:

• You can set thresholds. Auto route above 0.85, send to a human between 0.5 and 0.85, ignore below. OpenAI's own docs recommend picking thresholds from labelled examples and the cost of each kind of mistake.
• You can log the score next to the CRM record, so when a route is wrong you can see how confident the system was.

Before switching, build a small set of real past leads or tickets with known answers and test against it. The docs also say to write questions around observable criteria and give each choice a distinct meaning. That is plain good intake design, and it is where most routing bugs I fix actually come from.