OpenAI Decisions API: Public Beta Pricing and How It Works

OpenAI opened its Decisions API to public beta on October 6, 2026, giving every developer access to a dedicated endpoint that answers fixed-shape questions about text and images instead of generating free-form text. The endpoint, POST /v1/decisions, runs only on GPT-6 Luna, charges solely for input tokens at $0.10 per 1M tokens, and returns one of three typed answers per question: a predicate probability, a choice from a fixed list, or a score against ordered levels. OpenAI's own documentation says the endpoint is roughly 10 times faster than the Responses API for this kind of task, though the company has not published the benchmark methodology behind that figure.

What OpenAI launched

The Decisions API is a new, narrower sibling to the Responses API. Instead of asking a model to write a reply, a developer sends it a piece of evidence — a text string, or a message containing text and an image — plus an array of named questions, and the model answers each question in a fixed, machine-readable shape rather than free text. OpenAI's Decisions API guide describes the tool as a way to "get the probability that a condition is true, a choice from a fixed set, or a score against a rubric," positioning it for application logic such as content classification, support-ticket routing, and work prioritization rather than conversational output.

According to OpenAI's own API changelog, the feature shipped as a dated entry on October 6, 2026: "Released the Decisions API in beta with gpt-6-luna. Turn text and images into typed answers 10x faster than the Responses API." Multiple outlets reported that OpenAI had shown a narrower version of the same capability to a limited set of developers at its DevDay event in late September 2026 before the public beta opened; OpenAI's changelog itself does not carry a separate dated entry for that earlier preview, so that detail rests on secondary reporting rather than something we could confirm directly on OpenAI's site.

How a Decisions API request is structured

Every request to /v1/decisions has three parts, per OpenAI's documentation:

The response comes back as an answers array, with the API echoing back the unique name assigned to each question so an application can match answers to the questions it asked. A single request can carry multiple independent questions against the same input — for example, checking a product photo for visible damage and classifying its category in one call — but OpenAI's guide recommends sending separate requests when one answer should depend on another, such as checking for damage first and only then deciding whether to request a repair category.

The three answer types: predicate, choice, score

OpenAI's documentation defines three question types, each producing a different kind of typed answer:

In OpenAI's own illustrative example, a severity question with three levels (cosmetic, workaround available, fully blocked) returns level probabilities of 0.1, 0.7, and 0.2, which average out to a score of 1.1 — a number between "workaround available" and "fully blocked" that a routing rule could act on directly. Choice and score answers both include a confidence field in addition to the full probability distribution, which OpenAI suggests using with labeled examples from your own application to set thresholds for routing, filtering, or escalation to human review.

Image support and input limits

The beta accepts images as part of the shared input, combined with input_text and input_image parts in a user message — for instance, pairing a product photo with instructions to look for a crack, tear, or dent. One real constraint worth flagging for developers: OpenAI's guide states plainly that "images must be inline base64 data URLs," and that hosted HTTP or HTTPS image URLs and file_id references — both of which work elsewhere in OpenAI's APIs — are not supported by the Decisions endpoint. That means an application that already stores images in cloud storage has to fetch and re-encode them before calling the endpoint, rather than simply passing a URL.

Pricing: input-only, no output charge

OpenAI's Decisions API guide sets pricing at $0.10 per 1 million input tokens for GPT-6 Luna, with no charge at all for output tokens, cached input reads, or cache writes — "you pay only for input tokens." Regional processing premiums and long-context pricing multipliers still apply on top of that base rate.

Worth noting for budgeting purposes: $0.10 per 1M input tokens is identical to GPT-6 Luna's standard short-context input price on the ordinary Responses API, according to OpenAI's API pricing page. The Decisions API isn't a discounted rate on inputs — the savings instead come from never billing for output tokens (GPT-6 Luna's standard output price is $0.50 per 1M tokens on the Responses API) and from skipping the extra generation step a normal chat-style call would need to produce a structured answer.

Why GPT-6 Luna, and only GPT-6 Luna

GPT-6 Luna is currently the sole model available on the Decisions endpoint; OpenAI's guide does not name a timeline for adding other models. Luna is the smaller, lower-cost member of the GPT-6 family that OpenAI has also used for cost-sensitive chat scenarios — Pandromeda has previously covered how GPT-6 Luna's pricing and benchmarks compare with Anthropic's Claude Haiku 5.5. Restricting the Decisions API to a single, smaller model is consistent with the endpoint's design goal: fast, cheap, narrowly-scoped evaluation calls rather than open-ended generation, which is also how OpenAI frames GPT-6 Luna's role elsewhere, including in the model that underpins ChatGPT's interactive-answers UI.

The "10x faster" claim — what we could and couldn't verify

OpenAI states directly on its own documentation page, in large type at the top of the Decisions guide, that the API turns text and images into typed answers "about 10x faster than the Responses API," and the company's API changelog entry for October 6 repeats the same "10x faster" line. That much is confirmed as OpenAI's own stated claim. What we could not verify on OpenAI's own site is the methodology behind it: the public docs we reviewed do not publish latency numbers in milliseconds, a test harness, or a description of what request sizes or regions the comparison used. Some secondary coverage has cited specific millisecond figures (for example, one report attributed an approximate 150ms-versus-1.6-second comparison to the company), but we were not able to confirm those exact numbers on openai.com or in OpenAI's developer documentation, so we're not repeating them as fact here. Treat the 10x figure as OpenAI's own vendor claim rather than an independently benchmarked result until OpenAI publishes supporting numbers.

Decisions API vs. Structured Outputs vs. function calling

OpenAI's guide is explicit about when to reach for the Decisions API instead of its other structured-response tools. Use Structured Outputs with the Responses API when you need the model to generate an object that follows your own JSON schema — extracted fields, a written explanation, or any payload whose content isn't known in advance. Use function calling when you need the model to request a tool call with specific arguments. Use the Decisions API specifically when your application needs one of the three fixed answer types — a probability, a choice from options you define, or a score against levels you define — and doesn't need the model to produce any other generated content alongside it.

How developers are expected to use it

Based on the worked examples in OpenAI's own documentation, the Decisions API is aimed at exactly the kind of high-volume, narrow-judgment calls that sit inside larger application logic rather than user-facing chat:

• Routing support tickets — a choice question picks which department (billing, technical, shipping) should handle an incoming complaint, with per-option probabilities an application can use to auto-route high-confidence cases and queue ambiguous ones for review.
• Visual inspection — a predicate question checks a product photo for visible damage such as a crack, tear, or dent, returning a single probability an app can threshold against.
• Severity triage — a score question rates a bug report or support issue against ordered severity levels (for example, cosmetic, workaround available, fully blocked), producing a number that can fall between levels for finer-grained prioritization.
• Document classification — a choice question distinguishes between document types, such as an invoice, a receipt, or a contract, from an image of the document.
• Multi-agent orchestration — OpenAI's docs note the endpoint can also be paired with its Live API so that voice-driven agents can choose actions from spoken requests and report results back to the user.

In each case, the model is answering a question the developer already defined — it is not writing new prose, which is part of why OpenAI positions the endpoint as both faster and more directly actionable in application code than parsing a generated chat response would be.

How it compares to other fixed-choice tools in the market

Developers searching for the Decisions API have also been comparing it informally to other vendors' fixed-choice or classification-style endpoints, including a product called Jev from a company called TypeSafe. We have not found a controlled, apples-to-apples benchmark between the two from either company, and the comparisons circulating in developer forums and social posts appear to be informal, single-user tests rather than published methodology — so we're not citing specific numbers from that comparison here. What can be said from OpenAI's own materials is that the Decisions API's differentiators are tight integration with the rest of the OpenAI model lineup, GPT-6 Luna as the backing model, and input-only pricing; how it stacks up against any individual competitor on latency or cost for a specific workload is something developers will need to benchmark themselves against their own data.

Availability, compliance, and SDK requirements

OpenAI's guide states the Decisions API supports Zero Data Retention (ZDR) and HIPAA use for eligible customers, with data residency and regional processing available in the United States and in Europe (the EEA plus Switzerland); eligibility requirements and required agreements are covered in OpenAI's data controls documentation. To use the SDK examples OpenAI publishes for the endpoint, the company specifies minimum client versions: Python 3.26.0, JavaScript 7.30.0, Go 3.73.0, Ruby 0.101.0, and Java 4.78.0, or later. OpenAI also offers a Playground environment for testing questions and inputs against the endpoint before writing integration code.

What's next

OpenAI's own documentation says it expects to move the Decisions API to general availability "in the coming weeks," though no firm date has been published. Developers evaluating it now should expect beta-level caveats: OpenAI notes that limits and pricing, like the rest of its beta features, may change before GA. For teams that already build classification, routing, or moderation logic on top of chat-style completions, the endpoint is worth testing specifically for workloads where a single probability, category, or score is the only output needed — and for comparing its real-world latency against the Responses API directly, given that OpenAI has not yet published the benchmark details behind its own 10x claim. Developers building broader autonomous workflows may also want to track how Decisions calls interact with other agentic tooling, an area Pandromeda has covered in the context of how AI coding agents choose between terminal and IDE-native approaches.

Written byTheo Park

Theo Park runs the AI desk at Pandromeda. He follows model launches from the frontier labs and the open-weight community, tracks the assistants and developer tools built on them, and explains what each release changes on pricing, capability and safety. His reporting leans on primary sources: model cards, technical reports, API documentation and the companies' own announcements.

More from Theo ParkAll AI coverage