OpenAI's Decisions API gives small app judgements their own path

A useful AI interaction does not always need another paragraph. Sometimes an app needs to choose a queue, recognise that a step is complete or decide which reaction to show. OpenAI's Decisions API, made generally available on 22 October, gives those small, bounded judgements their own interface. The important distinction is not just speed: a model can supply a decision-shaped answer without taking the resulting action.

The service uses GPT-6 Luna and accepts shared evidence, followed by named questions. OpenAI positions it for responsive applications rather than open-ended conversation. Its announcement also adds native integration with GPT-Live, prompt caching and support for more questions in a request. These are supplier-described capabilities, not PING's latency measurements. OpenAI announcement

Three answers, three different jobs

A predicate estimates the probability that a stated condition is true. A choice selects from categories supplied by the developer. A score handles ordered levels and returns a probability-weighted average of their indices. That last answer can fall between levels: it is not necessarily one tidy category, and it is not a measurement taken from the physical world.

Imagine a small support operation serving customers in London and Lagos. An app might ask whether a message describes a delivery problem, then route it to one of several teams. That is our illustrative example, not an OpenAI customer deployment. The useful design work happens before the request: someone must define the categories, decide what an ambiguous message should do and name the person responsible for reviewing mistakes.

The developer guide recommends an 'other' option when the supplied choices may not cover an input. That is a practical opening for a review queue rather than a forced answer. A probability or confidence value should be tested against labelled examples from the intended workflow. The acceptable threshold depends on the cost of a wrong route or a missed case, not on an impressive-looking percentage alone. Decisions guide

The application still owns the action

This is not a universal replacement for existing API patterns. OpenAI points developers towards Responses with Structured Outputs when they need custom extracted fields or an explanation, and towards function calling when they need a tool call with arguments. Decisions is for its narrower answer types. The surrounding application still implements whatever happens next.

That boundary matters for a publisher, shop or service desk: identifying a likely category is different from authorising a refund, deleting a record or publishing a story. Our recommendation is to keep consequential actions behind explicit application rules and, where appropriate, a human approval step. A fast routing answer does not remove those responsibilities.

Batching is not a chain of reasoning

The current guide permits one to 400 independent questions over shared input. If a later question needs the answer to an earlier one, the guide says to use separate requests. For a small team evaluating the feature, that makes the distinction concrete: a batch can examine the same material in several ways, but it should not be mistaken for 400 dependent steps executed automatically.

Caching also has conditions. The guide requires a matching shared-input prefix of at least 1,024 tokens; question content does not count towards that prefix. Before estimating savings, check what actually repeats in the application. PING has not run a paid API call, benchmarked response times or tested cache behaviour.

The launch is most interesting as a design choice: let the model answer a tightly defined question, then let software and accountable people decide what that answer is allowed to change. For developers in African and UK teams alike, the next useful experiment is a small, labelled routing task with a visible fallback, not a promise of autonomous operations. Explore more coverage on PING's AI desk.