OpenAI has released a new Decisions API in public beta, giving developers a separate endpoint for typed decisions rather than full text generation. The beta arrived on October 6 with support for GPT-6 Luna and is positioned for workloads where the output space is known in advance: predicates, choices, and scores.
That sounds narrow, but it matters. A large share of production AI traffic is not open-ended writing. It is classification, routing, moderation-adjacent policy checks, intent detection, tool selection, and guardrail logic. Those calls often ask a model to produce a small structured answer, then force the application to parse or validate it. OpenAI is now treating that pattern as its own API surface.
What changed
The Decisions API turns text and images into typed answers. OpenAI says it can be up to 10 times faster than the Responses API for supported decision workloads. In the public beta, developers can define decision outputs as predicates, choices, or scores, rather than prompting a model to generate arbitrary text and then constraining the result after the fact.
The pricing model is also different. OpenAI lists GPT-6 Luna usage for the Decisions API at $0.10 per 1 million input tokens, with no cache-read, cache-write, or output-token charges. That makes the unit economics easier to model for high-volume decision layers because the bill is tied only to input volume.
The release does not replace chat, Responses, or agent-oriented APIs. It creates a more specialized path for cases where the application needs a reliable typed answer, not a paragraph. For teams already splitting workloads across model sizes, latency tiers, and provider routes, this adds another category to the architecture: decision calls.
Why developers should care
Many AI applications already use small model calls as internal control logic. A support assistant may classify a ticket before choosing a workflow. A coding agent may decide which tool to call next. A document processing system may score whether a record meets a policy threshold. A customer-facing product may route requests between cheaper and more capable models.
Until now, those patterns were often implemented as normal generation calls with strict prompts, JSON schemas, retries, and validation layers. That approach works, but it carries overhead. Developers pay for output tokens, manage parsing failures, and often accept more latency than the decision itself should require.
A typed decision endpoint changes that tradeoff. If the output can be represented as a boolean, a bounded choice, or a score, teams can move the call out of a general generative path. That may reduce latency and simplify application code. It may also reduce ambiguity in logs and analytics because the call’s purpose is explicit.
The most immediate use cases are likely to be high-frequency internal checks: request routing, content eligibility gates, escalation rules, tool-selection steps, and model-selection policies. In those places, small improvements in latency and cost can matter because the decision call may happen before every larger model request.
Cost and governance implications
The input-only price is the commercial detail to watch. For teams running large volumes of agent guardrails or routing decisions, eliminating output-token billing changes the comparison with small chat models, rules engines, and provider-specific classifier endpoints. It also makes cost forecasts less sensitive to output verbosity or schema retries.
That does not mean every classifier should move to the Decisions API. Deterministic rules will still be cheaper and easier to audit when the logic is simple. Existing embedding, search, or database filters may be more appropriate for some routing problems. But where a model is already being used to interpret messy text or images into a bounded answer, the new API gives teams a cleaner procurement and engineering option.
For platform teams, the larger issue is taxonomy. If all AI calls are treated as chat completions or generic responses in internal dashboards, decision workloads will be hard to manage. They have different latency expectations, billing behavior, and failure modes. Organizations with mature LLM cost management programs will need to separate decision traffic from generation traffic so routing, budgets, and alerts reflect how the workload actually behaves.
The same applies to gateways. A multi-model AI API gateway that only normalizes chat-style calls may not be enough if providers continue carving out specialized endpoints for decisions, tools, batches, live audio, and agents. B2B LLM platforms and internal AI control planes may need first-class endpoint categories for typed decisions rather than forcing everything through a chat abstraction.
Who is affected
Application developers get the most direct benefit if they maintain prompt-heavy classification or routing code. The new API may let them replace brittle prompt-and-parse flows with typed outputs that better match the application’s internal state machine.
AI platform teams are affected because they will need to decide whether the Decisions API is exposed as a separate approved capability, how it is logged, and which teams can use it. Security and compliance reviewers will want to know whether decision outputs are being used for access control, user eligibility, healthcare workflows, hiring, financial decisions, or other sensitive processes.
Finance and operations teams should also pay attention. Decision calls can be invisible in executive reporting if they are bundled into broader model usage. Once applications begin using model calls as control-plane logic, not just user-facing generation, LLM API cost attribution needs to capture the business function of the call, not only the model name.
What remains uncertain
The beta announcement establishes the basic shape of the API, but important production details still need validation. OpenAI has not provided independent benchmark evidence for the “up to 10x faster” claim across real enterprise workloads. Developers will need to test latency with their own input sizes, image payloads, regions, and concurrency patterns.
It is also unclear how stable the beta interface will be, how rate limits will compare with other OpenAI API surfaces, and how the Decisions API will evolve alongside Responses and future agent APIs. The pricing is attractive for high-volume decision layers, but beta pricing and endpoint behavior should not be treated as permanent without contract review.
The strategic signal is clear, though: OpenAI is unbundling another common LLM application pattern from general-purpose generation. For businesses, that means AI architecture is becoming less about choosing one model endpoint and more about matching each workload to the right API primitive.