When should you use OpenAI Decisions instead of Responses?

What did OpenAI actually ship in the Decisions API?

OpenAI’s 6 October 2026 changelog says the new Decisions API turns text and images into typed answers on a dedicated POST /v1/decisions endpoint and runs about 10 times faster than Responses for that job class. The guide then defines the boundary more tightly than most summaries did. A request has model, input, and questions; the response comes back as an answers array keyed by question name. The only question types are predicate, choice, and score, and the only model in beta is gpt-6-luna.

That matters because this is a scorer for bounded questions. OpenAI even routes readers away from it when the output needs to follow a custom JSON schema or request a tool call. One practical constraint is easy to miss in a launch skim: image inputs must be inline base64 data URLs. The guide says hosted HTTP or HTTPS image URLs and file_id image inputs are unsupported, so an existing image pipeline may need a small rewrite before a team sees any of the speed or cost benefits.

Where the Decisions surface stops

Show as text

Where the Decisions surface stops. Diagram: 7 ordered layers. Shared evidence in input, then Typed question list, then answers array with probabilities, then compare with Responses below (breakpoint), then Prompt or message input, then JSON schema or tool definitions, then Generated text or tool loop.

#	Layer	Note
1	Shared evidence in input	Text or mixed text plus inline images.
2	Typed question list	Predicate, choice, or score only.
3	answers array with probabilities	Endpoint returns typed results.
·	compare with Responses below (breakpoint)
4	Prompt or message input	Same family, broader output surface.
5	JSON schema or tool definitions	Extraction and tool use live here.
6	Generated text or tool loop	Output can be prose, JSON, or calls.

How is OpenAI Decisions different from Structured Outputs?

The cleanest split is answer shape. Decisions returns one of three built-in types: a truth estimate, a choice from your own fixed set, or a score across ordered levels. Structured Outputs on Responses does something broader. It asks the model to generate an object that conforms to your JSON schema, which is why it suits extraction, normalization, and any result that needs named fields the API does not predefine. That is a wider contract and a heavier one.

The score path is the detail worth carrying into design reviews. OpenAI defines score as the probability-weighted average of ordered level indices, so a result can land between labels. A severity score of 1.1 means the model spread probability across adjacent levels. Teams that need hard buckets should still keep the distribution or threshold band, much like the discipline described in question design for classification and in type-safe AI system one. My view is that Decisions is the better first hop when the app only needs a typed gate. The moment you need extracted fields or a written explanation, Responses has already won.

Why can Decisions be cheaper and faster than Responses?

OpenAI’s own pricing explanation gives the short answer: Decisions with gpt-6-luna charges input tokens only. The guide says there are no cache-read, cache-write, or output-token charges on /v1/decisions. By contrast, OpenAI’s pricing page lists multiple billable surfaces for gpt-6-luna on Responses, including input, cached input, cache writes, and output tokens. Even before you benchmark latency, the contract tells you why a typed scorer can be quicker and operationally simpler than a generation endpoint.

The cost story still needs discipline. Responses can earn back some of that extra surface with prompt caching, which matters in high-reuse traffic and is a big reason to keep reading work such as prompt caching economics. Decisions also gives up expressive power to get its speed. There is no written rationale for a human reviewer, no schema-shaped extraction result, and no tool loop. So the real question is not whether Decisions is cheaper in a vacuum. The question is whether the application can stop at a typed answer without paying a second request to another surface.

What GPT-6 Luna bills on the two surfaces

Show data

What GPT-6 Luna bills on the two surfaces. Bar chart. Decisions input: 0.1 USD per 1M tokens. Responses input: 0.1 USD per 1M tokens. Responses cached input: 0.01 USD per 1M tokens. Responses output: 0.5 USD per 1M tokens. Responses cache write: 0.125 USD per 1M tokens.

Item	Value (USD per 1M tokens)	Note
Decisions input	0.1	Decisions guide says input only.
Responses input	0.1	Standard short-context input rate.
Responses cached input	0.01	Applies when a cache hit exists.
Responses output	0.5	Generated output has its own rate.
Responses cache write	0.125	Prefix writes are billed separately.

Which workloads fit OpenAI Decisions best today?

The strongest fits are first-hop routing, triage, and review gating. OpenAI’s own examples are visible damage checks, department routing, and severity scoring. Those are all jobs where the application wants a bounded answer and already knows what to do next. A moderation queue can route anything above a predicate threshold to manual review. A support desk can choose a department. A bug intake service can score severity, then send only borderline tickets to a full Responses flow for explanation or follow-up.

This is also where the data-controls note matters. OpenAI says Decisions is ZDR eligible and supports HIPAA use for eligible customers, with regional processing in the United States and Europe. That makes it easier to justify for production triage pipelines than a brand-new endpoint would normally be. My opinion is that Decisions works best as a front door for a larger workflow. Full case handling belongs elsewhere. If a team keeps the boundary narrow and preserves an escalation path, it can cut cost and latency without pretending a typed score is the same thing as a reviewed decision.

When should you stay on OpenAI Responses instead?

Stay on Responses when the work product must say more than a bounded answer. OpenAI’s Decisions guide itself points readers to Structured Outputs when they need extracted fields or written explanation, and to function calling when the model must request a real action. In those workloads, the larger control surface matches the work itself. If the app needs a refund tool call, a schema-shaped claim form, or a rationale a human can audit, Responses is still the right surface even when it costs more.

There is another practical reason to stay put: migration friction. Teams with existing image pipelines on hosted URLs or file_id inputs cannot drop those requests straight onto Decisions because the guide requires inline base64 image data. That conversion may be fine for a hot path and annoying for a batch path. My view is simple. Use Decisions for high-volume gates where the next action is already determined by the answer type. Use Responses everywhere the answer still needs to explain itself, extract a richer object, or touch the outside world.