OpenAI Decisions API Goes GA: 400 Questions per Call, Native JSON and Real-Time Voice Decisions

Scope note: This article covers ONLY the October 22, 2026 general availability (GA) event and what changed relative to the public beta. It does not re-litigate the beta basics at length. The Decisions API entered public beta on October 6, 2026, and VibeFix already covered that beta in a separate article (slug: openai-decisions-api-october-2026); read that piece first if you need the beta backstory. This piece assumes you know what the API is and answers one question: what is actually new in GA, what does it cost, and is it ready for production?

The short version: from usable to production-ready

On October 22, 2026, OpenAI announced in its developer community that the Decisions API is out of beta and generally available. Its core positioning has not changed: it is not a general-purpose generator, but a decision endpoint that returns bounded answers — classification, scoring and routing decisions on text, images and structured data — without generating a full model response. What GA changes is the set of missing pieces for production: twice as many questions per request, native JSON inputs, prompt caching, native voice integration and US/EU inference residency. For indie developers and small teams, that turns a decision layer that worked in a demo into one you can budget for, keep compliant and keep fast.

GA does not mean everyone must migrate. If you only run occasional classifications, or a rules engine already handles your logic, GA changes little for you overnight. Its value concentrates in three kinds of workload: high-frequency decisions, repeated decisions over long shared context, and real-time decisions that directly drive the next action. The rest of this article follows four threads: what changed, what it costs, what it cannot do, and how to use it.

What changed since beta: five additions, one comparison table

OpenAI's announcement lists five new capabilities; a secondary cross-check adds inference residency and regional capacity. Read together, the upgrade logic is clear: fewer format conversions, less repeat billing, less waiting.

Dimension	Public beta (October 6, 2026)	GA (October 22, 2026)
Questions per request	200	400, doubled
Structured input	App data had to be rendered as text or messages	Native JSON inputs, structured app data passed directly
Caching	Not highlighted as a GA feature	Prompt caching for reused shared-input prefixes
Voice integration	No native integration	Native GPT-Live integration, voice apps react as people speak
Images in question instructions	Images existed as inputs; instruction-level images are new	Images inside individual question instructions, multiple images compared against a shared reference
Inference residency	Not emphasised	US and EU inference residency, plus added inference capacity in several Asian regions

1. Up to 400 questions: batch decisions in a single call

Doubling the limit changes how batch jobs are organised. Reviewing 300 pieces of user feedback, product photos or support tickets previously meant splitting across two requests, two billing boundaries and two retry surfaces; now one call can return the full answers array. For vibe projects the most direct win is a moderation back office: score the whole pending queue in one pass, auto-approve high-confidence items, and send only low-confidence ones to a human. The human workload does not fall linearly — it is cut by the high-confidence auto-approval slice. But 400 is a ceiling, not a target: larger requests have a larger failure surface. A pragmatic split is 50 to 100 items per business batch, balancing batch pricing against the cost of retrying a whole batch after a network hiccup.

2. Native JSON inputs: one fewer translation layer, one fewer bug class

Feeding orders, tickets, forms or analytics events to a model used to mean rendering them as prose first, which loses precision as soon as field counts grow. GA lets developers pass structured data directly through an input_json content part in a user message, so the model sees the structure itself rather than your paraphrase of it. For vibe developers this is concrete: data structures your backend already has no longer need a second “translate to prompt” glue layer, and field names, enum values and numeric ranges arrive intact. Structured input is not a substitute for cleaning, though — dirty fields, missing values and inconsistent units still reach the model, so validation before the call still matters.

3. Prompt caching: the cost switch for high-reuse workloads

GA adds prompt caching: reused shared-input prefixes are billed at the cached rate. The official price table lists $0.10 per million non-cached input tokens and $0.01 per million cached input tokens — an order of magnitude apart. The cross-check adds a crucial detail: a reusable prefix must be at least 1,024 tokens long, question content (including question-specific images) sits outside the reusable prefix, and an implicit cache breakpoint is placed at the end of shared input by default, with caller-provided cache keys or explicit breakpoints also supported. Caching therefore has to be designed, not just switched on: put stable content — system instructions, classification criteria, rubric definitions, few-shot examples — up front and keep it unchanged, and put the varying item to be judged afterwards. Workloads that rewrite the prompt on every call will see no caching benefit. Budgeting should also allow for cache-write pricing, regional processing premiums and long-context multipliers; do not build a budget on $0.01 alone.

4. Native GPT-Live integration: decisions during speech, not after it

This is GA's most imaginative addition. A voice application can run decisions as input or output transcripts arrive, and Live emits a decision event for the application to act on. OpenAI's example selects an avatar's facial expression from transcript updates; a support agent using the same pattern decides whether to ask a clarifying question, route a request or escalate it. In vibe-project terms, a voice assistant no longer has to wait for a full utterance and a full generated reply before deciding its next move; it can judge mid-conversation whether intent is clear, whether sentiment is escalating, or whether a human handoff is needed. The caution is symmetric: real-time decisions are more sensitive to both latency and misclassification, and a wrong route in voice costs more than one in text. Low-confidence cases need a human fallback before launch.

5. Images in question instructions: compare many images against one reference

GA lets an individual question's instructions contain images, so multiple images can be compared against a shared reference. Previously, checking “which of these photos best matches the reference standard” meant splitting requests or describing the reference in words; now the reference can appear as an image inside the question itself. That suits e-commerce quality checks, listing-photo screening, design comparisons and “does this match the standard image” moderation. One constraint to plan around: the documentation states that files, audio and item references are not supported and file_id inputs are not accepted — images must be inline base64 data URLs or publicly accessible HTTP/HTTPS URLs. Private images need a hosting or base64 plan before integration, not during it.

Three bounded answer types: probabilities, choices and scores — no prose

The API's design philosophy is that the shape of the answer is fixed in advance; the model fills it in but does not improvise. Documentation and the cross-check agree on three question types, and understanding them is the precondition for using the endpoint correctly.

Type	Returns	Good for	Vibe-project example
Predicate	A probability from 0 to 1 that a condition is true	Checking a condition	Visible damage in a product photo, abuse in a comment, urgency of a ticket
Choice	One of your predefined options, plus per-option probabilities and a confidence value	Routing and classification	Routing a ticket to support, engineering or billing; sorting feedback into bug, feature request or question
Score	A rating against 2 to 10 ordered rubric levels, returned as a probability-weighted average of level indices, so scores can fall between levels	Quality, risk and priority ranking	UGC risk scores, submission quality scores, task priority scores

Each type has its own trap. A predicate probability is the likelihood that the condition is true, not a measure of how sure the model is in some abstract sense — moving an “is this urgent” threshold from 0.5 to 0.8 changes human-review volume completely. A choice result must be read with its distribution: if the top option scores 0.4 and the rest split 0.3 each, the winner is not stable, and the right move is to flag it for human confirmation rather than auto-executing it. A score that lands between rubric levels is normal; use it for ranking, but state qualitative conclusions in level ranges rather than treating a rounded integer as a precise measurement.

One more design constraint: decisions that depend on an earlier answer require separate requests. The API does not do chained reasoning inside one call — a second question cannot reference the first question's answer. Multi-step flows must be orchestrated in your own code: send the first batch, decide the second batch from its results, and so on. That looks inconvenient, but it keeps flow control — and therefore debuggability — in your hands rather than inside a black-box chain.

Pricing and deployment: input tokens only, but do not budget on $0.10 alone

GA runs on GPT-6 Luna. The official table is clean: $0.10 per million non-cached input tokens, $0.01 per million cached input tokens, input tokens only, no output-token charges. That is structurally favourable for decision workloads: in a traditional generation call, output tokens are often the expensive part, whereas a decision's output is inherently short — so charging only for input removes the expensive side of the bill. A short ticket classification may need only a few hundred input tokens, costing well under a cent per call.

But a real budget needs more than $0.10. The cross-check flags regional processing premiums, long-context input multipliers and standard Luna cache-read/write rates. A workable costing method: first compute the no-cache ceiling at $0.10, then discount by your expected cache-hit rate, then keep a 20–30% buffer for premiums and retries. Only if that number is still clearly below your current cost of doing the same decisions through the Responses API is migration a money win; if the two are close, the gain is latency and structured answers, not savings.

On deployment, regional processing is supported in the United States and Europe (the EEA plus Switzerland), data residency is available in all supported API regions, and Zero Data Retention and HIPAA use are available to eligible customers. One easily overlooked operations feature is the organisation usage endpoint, GET /v1/organization/usage/decisions, which requires an admin API key with the api.usage.read permission and returns token usage and request counts filterable or groupable by project, API key or model. For an indie developer that is cost attribution; for a small team it is per-project billing — and it should be wired up at launch, not when the invoice arrives.

What Decisions is NOT: do not use it as a generator

This section needs to be blunt, because misuse is the most common failure mode. Decisions does not write prose, generate shaped objects or decide tool calls for you. When you need a shaped object or prose, the documentation points elsewhere: Structured Outputs or function calling in the Responses API.

You need	Use Decisions	Use Responses / Structured Outputs
Score, classify or route content	Yes, its natural fit	Possible, but pricier and slower
Generate a reply, summary or rewrite	No, it does not generate prose	Yes
Return a custom JSON object	No, only the three bounded answers	Yes, with Structured Outputs
Let the model choose a tool call	No	Yes, with function calling
Multi-step reasoning where earlier answers shape later questions	Orchestrate multiple requests yourself	Reason continuously in-conversation
Handle files, audio or item references	No, explicitly unsupported	Use the corresponding interface

The other boundary is that a decision is not a verdict. A probability of 0.92 is not a fact, and a score of 8.5 is not a conviction. In moderation, risk and escalation workflows with real consequences, Decisions should be a triage and ranking layer, not a final judge: high confidence auto-handled, low confidence queued for humans, and extreme-consequence actions always human-confirmed. Writing a model probability straight into a database as business truth is the easiest way to bury a landmine in a vibe project.

Vendor claims, discounted: the “up to 10x faster” line

OpenAI says the Decisions API delivers answers up to 10x faster than asking GPT-6 Luna through the Responses API. That is a vendor claim, not an independently verified result, and this article does not treat it as a measured fact. The customer cases quoted in the announcement deserve the same treatment — customer self-reports, not independent verification: Box reported roughly 5x faster route selection across 30 certificate-of-insurance cases at the same accuracy as the Responses API when combined with Box Extract, sending lower-confidence cases to reviewers; Datadog reported 40x faster p95 latency than available frontier models at comparable accuracy when scoring the risk of agent-generated shell commands before execution; Ramp reported cost attribution 4x faster and 30% cheaper than using GPT-6 Luna, with no accuracy loss; Sierra reported choosing the next action in parts of live customer-conversation orchestration at under 280 milliseconds p95, about 3x faster and 90% lower cost per call than its previous approach, with no drop in customer outcomes; Speak reported that the GPT-Live integration cut time to next action by more than 90% in its testing, from 1.4 seconds to 0.13 seconds.

Even if every number is accurate, each was measured on a specific task, data distribution and baseline. Change the dataset, the threshold or the prompt, and the result can change completely. Treat these numbers as a signal that benchmarking is worthwhile, not as a promised return. Before full rollout, run your own head-to-head on real samples — latency, cost, accuracy and human-review rate, all four — and only call migration a success when all four pass. Judging on latency alone is how vendor narratives win.

A launch checklist for vibe developers

1. Fix the answer shape before writing prompts. Decide predicate, choice or score for each decision, and freeze options and rubric levels in product docs — changing them later makes historical scores incomparable.
2. Build a stable shared prefix. Criteria, rubric definitions and examples go in shared input, kept as unchanged as possible — that is the precondition for cached pricing.
3. Set thresholds and fallbacks per decision. High confidence auto-handled, low confidence human-queued, extreme-consequence actions always human-confirmed. Calibrate thresholds on real samples, not by guessing 0.5.
4. Batch by business unit, not by the 400 ceiling. Start at 50 to 100 items per batch and tune against your timeout distribution.
5. Orchestrate multi-step decisions yourself. When later questions depend on earlier answers, chain requests in code and keep flow control visible.
6. Solve image supply first. Private images need base64 or public URLs; files and audio are out of scope for this endpoint.
7. Wire up usage reporting at launch. Group costs by project so an invoice anomaly can be traced to a project and a key.
8. Run your own benchmark. Latency, cost, accuracy and human-review rate against the vendor claims, before going all-in.

Conclusion: GA's value is not novelty, it is accountability

Looked at coldly, this GA changes no model and no headline price. What it changes is the friction of running decisions in production: more questions per call, no paraphrasing step for structured data, no repeat billing for repeated context, no waiting for a full utterance in voice, and data that can stay in the US or the EU. None of those show up in a demo, but all of them show up on a production ledger. For vibe developers, the right move is not to migrate every classifier at once, but to pick one high-frequency, well-bounded, consequence-manageable decision — ticket routing, submission triage, content risk ranking — get thresholds, caching and human fallback right, and then decide whether to expand. A good decision layer lets an agent safely hand its next action to a model; a sloppy one just lets the model make mistakes faster.