What can you build with OpenAI Decisions API? Turning everyday language into application actions

Ask a companion in a game to scout beyond a bridge and return without fighting if enemies are present. A natural reply does not necessarily make the character cross the bridge. Receiving a request, translating it into an available action, and starting that action are separate jobs.

OpenAI announced general availability of the Decisions API on October 22, 2026. It handles the job of evaluating input and returning a decision. Conventional LLMs can already classify inputs and produce structured outputs. A dedicated API is useful where recurring decisions with predefined outcomes can be separated from writing and planning, then connected to application behavior.

What can this separation help us build, and when is it worth making? We will follow the NPC request through to completion, then extend the idea to voice, work routing, and reviewing materials. Specifications were checked on October 23. Except where identified as official examples, these application designs are LATENT proposals, not API benchmarks or verified production deployments.

OpenAI GA announcement / Official Decisions guide

Turn a conversational NPC into a companion you can give tasks to

Suppose the game already supports following the player, scouting a selected location, and waiting. A conventional menu lets the player choose Scout and click a destination on the map. Accepting everyday language introduces an interpretation step that makes those selections from the request. The new capability is an additional way to reach actions the game already supports.

The utterance alone may not identify the bridge. Input can include recent dialogue, the current location, bridges known to the character, and its current assignment. If there are riverside and castle-gate bridges, give each an application identifier and a short description. Supply the context needed to distinguish this request’s target and conditions.

Split the request into selections needed for execution: intent among scout, follow, wait, conversation, and defer; a destination among known candidates or an unresolved destination; and an engagement policy among avoid combat, permit combat, and unspecified. These are illustrative application choices. The API does not come with built-in game commands; the developer defines choices that map to the game’s actions.

An illustrative result is scout, riverside bridge, avoid combat. Before moving the character, the game checks whether the bridge is still traversable, whether another event has locked the companion, and whether the player may issue commands. Conditions established by game state can be checked in ordinary code. Interpreting language and checking authoritative state can use different tools.

After validation, the game registers scouting as the active assignment. Dialogue generation receives that confirmed result and can acknowledge the engagement restriction. If the bridge is blocked, it receives the failure instead. The aim is to reduce discrepancies between what the character promises and what the game accepted. Dialogue style and assignment registration can then be revised independently.

A conventional LLM can support this flow by returning command JSON for validation and then generating a reply from the result. A separate Decisions call becomes worth considering when command interpretation recurs without needing dialogue, is shared across interfaces, or needs independent evaluation as the dialogue model changes. Separation is one design option, not the only implementation.

Deferred interpretations reveal another useful behavior. A request to scout over there may not identify a destination. The interface can offer map candidates instead of silently choosing the nearest bridge. A correction such as do not cross the bridge can cancel the earlier request. Targeted clarification makes this design more tractable than expecting every ambiguous request to succeed in one attempt.

The scene can also change while a request is in flight. A scouting decision that arrives after combat starts may be stale. The application can associate each request with a scene version and check its validity on arrival. It keeps existing behavior while waiting and avoids registering a retried command twice. These mechanisms make a networked decision usable within the game’s flow.

The same approach can guide state changes during scouting, such as interpreting a teammate’s request for help and choosing whether to continue or report back. An explicit rule to retreat below a health threshold does not require another AI call. Restricting semantic evaluation to language and events makes each call’s purpose clearer.

Movement, aiming, and collision checks continue through the game’s frame-by-frame logic. Waiting for a cloud response to update frames would expose the controls to network variability. Here the candidate task is choosing assignments or behavior policies, which existing behavior trees and state management translate into motion. Offline play can make local rules or models the appropriate choice.

Our d1 article examined resources and latency when running a decision model alongside a game. The Strands Decider article explored a large model working with a local decision model. A cloud API raises a further question: whether reduced distribution and device support work outweigh networking and ongoing usage costs. The same scouting design can call for different implementations in different play environments.

Related: running d1 alongside a game / Related: dividing work with Strands Decider

Separate recurring decisions when a dedicated interface helps

Stepping outside the game, the user speaks freely while the application has a defined set of capabilities. An interpretation step can connect the request to those capabilities without requiring the user to know internal menu names or categories. Language understanding can affect options shown and work performed, as well as the text of a reply. That is the shared opportunity behind the uses considered here.

Existing LLMs can bridge that gap. Structured Outputs can return results following a specified JSON schema, avoiding the need to extract commands from free-form prose. Function calling can propose tools and arguments. The comparison is between keeping work within one generation flow and giving selected evaluations a separate interface.

Decisions returns a condition’s estimated probability, a selection from supplied choices, or a score over ordered levels: predicate, choice, and score. A department is an unordered choice; degree of disruption is an ordered assessment. The intended role of the answer is defined up front. The currently supported model is gpt-6-luna, whose name does not establish its internal parameter count.

Shared input contains the evidence; questions specify what to evaluate. For the NPC, conversation and state are evidence, while intent and destination are questions. Native JSON input, added for GA, accepts structures such as state or order records directly. It does not resolve an ambiguous processing status whose meaning could be payment or shipment preparation. Fields still need clear definitions.

This structure is useful when several independent aspects of one input matter. A support request could be assessed for destination, attachment readability, and missing information. Named questions help identify which evaluation failed, separately from reply fluency. A shared definition can also support the same routing process behind both chat and email intake.

GA increased the maximum from 200 to 400 questions per request. Filling that allowance is not a goal. If later work depends on an earlier answer, it belongs to a subsequent stage. Attachment readability and request category can be assessed together; composing a retake request after discovering an unreadable image happens afterward. Grouping independent evaluations is different from executing a sequence of steps.

If the application needs extracted order numbers, addresses, and an explanation together, ordinary LLM generation into a custom schema may fit better. The same applies when the available choices themselves need to be developed. Forcing a task into a constrained answer can discard information and create more work. A short answer also need not be easy: selecting one label may require understanding a long conversation.

Task characteristics matter more than model size alone. A large model can handle planning and expression while a specialist handles recurring choices, but suitability must be tested on the actual inputs. Separation may simply resend the same material or add sequential waiting between classification and generation. A combined flow can be preferable in those cases.

A useful candidate has an answer the application can act on, occurs repeatedly, and benefits from evaluation independently of generated prose. Those properties give a separate decision process a concrete purpose. Voice adds a further dimension: when the decision becomes available can change the experience itself.

Official Decisions guide / Official Structured Outputs guide / OpenAI GA announcement

Use decisions during speech to prepare the next interaction

The NPC example registers an action after interpreting the request. Spoken input arrives gradually, which creates another option: prepare screens or candidates from what is already understood while the conversation continues. The purpose of a separate decision is not limited to writing a final reply faster. It can prepare the next part of the interaction before that reply is ready.

Consider a voice order assistant hearing: yesterday’s order, cancel—actually, I want to know the delivery date. The partial request suggests cancellation; the completed request concerns delivery. Recognizing the topic as orders can prepare the user’s order list, but should not execute cancellation. Different operations can have different requirements for how complete an utterance must be.

Inputs can combine the current transcript, visible order, and preceding conversation. Questions can select a topic and a display candidate such as an order list, delivery status, cancellation information, or deferral. A delivery result lets the application prepare the relevant card after identifying the order. Multiple candidates prompt a choice. Keeping display preparation separate from order modification makes corrections easier to accommodate.

GPT-Live’s native integration supports this kind of design. Live can call Decisions directly, avoiding the application round trip used when Live first notifies an app that then calls Decisions. Input or output transcript deltas can also trigger evaluations. This is not raw audio being sent directly to Decisions: the decisions are associated with the transcript as words arrive.

Preparatory work still needs boundaries. Loading another person’s order or exposing unnecessary personal details can matter even if a screen can be changed back. Preparation must stay within the authenticated user’s access. Within that boundary, highlighting a candidate order and asking for confirmation can provide useful feedback before any modification is committed.

Timing must remain associated with the result. The official guide notes that pending transcript deltas can be combined and results can arrive out of order. The app should match a decision to its source utterance so an older cancellation candidate cannot replace a newer delivery view. It can also wait for suitable conditions before changing displays to avoid flickering with every partial phrase.

Official examples include choosing cabin controls and coordinating a digital person’s expressions and gestures with conversation. The latter illustrates why selecting small actions can be useful independently of generating speech. These are implementation examples, not evidence of production accuracy or latency. A selected expression also does not prove that the system correctly inferred a person’s emotions.

The time that matters is from speaking to seeing an appropriate response. Faster model evaluation alone may not help if transcription, order retrieval, or screen updates remain slow. Preparing a selected target before the final reply could still be useful. Measure which part of the interaction improves across transcription, networking, decisions, and rendering.

More intermediate decisions can add calls and incorrect anticipation. Some users may prefer one confirmation after speaking to repeated screen changes. Operations such as cancellation or sending still wait for commitment, and distracting preparatory feedback can be reduced. The adoption test is whether the completed interaction becomes clearer and more useful, rather than merely whether decisions can run during speech.

Official voice integration guide

Route work and identify where approval is needed

The voice example prepares the next screen. Applied to work, preparing the right next step becomes support routing. A customer says they believe they already paid but received another bill. Their need is for the appropriate person or process to inspect that payment. Deciding who should investigate and what evidence is missing can precede writing a reply.

Input can include the message, conversation history, and authorized order records. Keep the customer’s assertion of payment distinct from the ledger’s recorded payment. Questions can identify a billing, delivery, usage, or other destination and whether investigation has enough information. A claim presented to the model must not become an authoritative business record simply through evaluation.

A result of billing with a missing order number lets the application queue the case and prepare a request for that number. When records are available, it can present them with the original message to the reviewer. Refund processing remains a later procedure. The potential benefit is organizing the first step without generating a long answer that ultimately only hands the case off.

Forcing every case into one label can hide part of the request. An undelivered package and a duplicate charge need both delivery and billing attention. Independent checks for the two issues can let the application assign a lead and a supporting team. Questions and their answers should map to the handoff the work actually needs.

When another AI or program receives the handoff, the same pattern becomes agent routing. A case can proceed to an order lookup, record aggregation, an explanation draft, or human review. A generative model can plan the investigation and write the explanation, while Decisions evaluates which established step fits the current evidence. Ordinary code can perform the arithmetic itself.

Missing payment records might yield an additional-lookup result. That selection does not also generate search conditions or tool arguments. The application checks the permitted scope and passes the order identifier to an existing lookup function. If a new query or complex arguments are needed, another generation step can prepare them. A selected task must be mapped to an actual callable capability.

Approval needs a separate boundary. Decisions can help identify ambiguity that requires clarification or a proposed action that includes external sending. A model result of no approval needed must not waive a mandatory approval rule. The application independently checks the authenticated user, recipient, amount limits, and available tools through its authorization controls.

The approval interface should reflect that division. A bare request to approve a refund does not identify the complete action. Show the order, amount, recipient, and intended resulting state. Approval applies to those details; changing the amount or recipient requires handling that change rather than reusing the same approval. AI can help select cases for review, while the application binds approval to the actual action.

Unmatched requests, missing evidence, refused questions, and incomplete network calls need an explicit destination, such as review pending with the original message retained. Treating them as normal no-issue results would hide work that needs attention. Sending everything to people is not a useful automation outcome either, so track why cases are deferred and how often.

Agents can also loop: select a lookup, obtain no new information, and select it again. The application can limit attempts and elapsed time, then return the case for review. Evaluate completed resolutions and the number of handoffs, as well as decision accuracy. Increasing the number of inexpensive decisions does not help if the work never finishes.

Support intake and agent branching both route evidence to a suitable worker or process. Choosing that destination does not establish that its work succeeded. Recording the selected route, actual lookup, and returned result separately helps identify whether classification, the lookup tool, or the explanation needs fixing. That ability to inspect failures is another reason to separate decisions.

Official Decisions guide / Decisions API reference

Use document and image decisions to focus human review

A decision need not immediately trigger an action to be useful. It can organize what a person should inspect first. A team preparing product pages repeatedly checks conditions in the description, matching photos, and required notices. One proposed use is to select material for review rather than certify an entire page as correct.

For text, provide a passage, authoritative product facts, and the communication criteria. Questions can check whether promotional and ordinary prices are distinguished or whether a separately charged feature appears included in the base price. The application presents the associated passage for review. These questions connect evaluation to a specific possible misunderstanding rather than a general judgment of writing quality.

Do not assume the decision result supplies an explanation or rewritten text. The application already knows the passage identifier and maps it to the relevant question and answer. Editors compare the original with the product facts; generation can propose a revision afterward if needed. Selecting material for review can therefore operate without rewriting every passage it inspects.

Document boundaries affect the decision. Sending one sentence without the pricing condition in the following paragraph or an exception in a footnote can create false flags. Include the necessary related text and tables. Sending every document on every call increases both cost and scope. Observing the evidence editors actually compare can guide how to package each evaluation.

The same page’s photos can be evaluated against shared criteria. Place a reference product image and description in shared input, with candidate photos in individual questions. Proposed checks include a visible mismatch with the expected model, label visibility, and inadequate image quality. Per-question images, added for GA, support comparing changing candidates with common reference material.

An illustrative result requiring label review with adequate image quality sends the photo to a reviewer. An image too dark to assess becomes a retake candidate. Show the image’s visible scope and the criterion together; the decision does not establish what is outside the frame or on the reverse side. An unavailable observation must remain distinct from a finding of no problem.

The official guide includes visible-damage checks on photos. That does not validate this proposed product-page review workflow or establish an error-reduction rate. Lighting, viewing angle, color variants, and compression can change appearance. Precise measurement of fixed dimensions or component counts may suit dedicated vision tools better. Flexible language criteria and reliable narrow measurements are different advantages.

Combining text and image results can produce an editorial worklist: check the pricing condition, inspect the label, or request a new photo. Reviewers can begin with these candidates, while retaining mandatory checks. Unflagged material is not guaranteed correct. The experiment is whether prioritization and evidence presentation make the review process more effective.

False flags cost time too. A worklist full of irrelevant candidates may lose reviewers’ trust, while suppressing flags can miss important omissions. Compare missed issues, unnecessary alerts, and review time together. Changes to the document or criteria invalidate old results, and failed calls leave items unreviewed. Those behaviors determine whether the system actually helps the review process.

The NPC selects an action, voice prepares an interaction, support selects a destination, and review selects where to focus attention. Each converts interpreted input into something the next stage can use, but mistakes have different consequences. A common API does not imply one evaluation standard for every use. Those differences determine the quality and cost criteria for adoption.

Official Decisions guide / OpenAI GA announcement

Judge the split by quality and total cost per completed task

Defining output formats makes these proposals approachable to prototype. Adoption requires evidence of improvement over the existing process: correct requested actions for NPCs, mistaken anticipation in voice, routing and resolution time in support, or missed issues and review time for documents. A successful API response should not count as successful completion of the user’s task.

One starting approach is to run existing logic and Decisions on the same inputs without connecting the new results to execution. Include corrections, negation, unsupported requests, missing information, and compound issues alongside ordinary cases. Keep tuning examples separate from final comparison examples, and inspect which categories improve or regress.

Returned probabilities and confidence do not directly state accuracy in your application. Missing a no-combat instruction has a different consequence from an extra editorial review flag. Any threshold for automation or deferral needs evaluation on relevant examples. Also check whether apparent correctness is being achieved mainly by transferring more work to people.

Latency requirements differ by use. A delayed NPC action may be conspicuous, while a publication review may tolerate grouped processing. Measure the slower end of the distribution, missed deadlines, and behavior under concurrency as well as the mean. Official speed claims do not establish identical latency with different inputs, regions, networks, and applications. We have not benchmarked these proposed designs.

Support intake provides a concrete cost example. At GA, Decisions with Luna charges $0.10 per million ordinary input tokens and $0.01 per million cache-read tokens, with no output-token charge. If each request contains 3,000 billable tokens, all charged as ordinary input, 100,000 requests cost $30: 3,000 ÷ 1,000,000 × $0.10 × 100,000. These are assumed token counts, not measured support requests.

Billable input includes more than the customer’s message: shared records, questions, choice descriptions, and images matter too. A request containing 400 questions does not make the additional 399 free. More questions add input, and repeated evaluations add calls. Classifying a message once and repeatedly evaluating a spoken interaction are different workloads, even when both are called one case.

Prompt caching may help repeated reviews using common criteria. It reuses a matching prefix of shared input of at least 1,024 tokens. Question content, including question-specific images, is outside that reusable prefix. Separating stable reference material from changing targets can therefore matter, but padding input merely to reach the minimum would enlarge the workload.

Cache writes have a price as well as reads: $0.125 per million tokens for a 30-minute write and $0.25 for a 12-hour write. Apply that rate to written tokens without adding ordinary-input charges for the same tokens. Read and write counts are already included in input_tokens. Split total usage into ordinary input, reads, and writes by lifetime to avoid double counting.

Assume 10,000 reviews with 2,000 shared tokens written once, successfully read on the following 9,999 requests, and 1,000 changing tokens charged as ordinary input each time. A 30-minute write costs $0.00025, reads cost $0.19998, and changing input costs $1, totaling $1.20023. Charging all 3,000 tokens as ordinary input on every request would instead cost $3.

That illustration assumes matching shared input remains reusable within its lifetime, requires no rewriting, and incurs no write charges on the changing portion. Using the 12-hour write rate with everything else unchanged gives $1.20048. Value depends on reuse during the lifetime. Changing conversation histories and repeatedly used product criteria can have very different actual cache behavior.

Those calculations cover Decisions only. They exclude regional and long-context multipliers, GPT-Live, reply generation, external tools, storage, retries, and human review. Decision charges alone do not establish the cost of a voice session. Lower API costs can also be outweighed by correcting support misroutes. Compare total cost per correctly completed task.

Choose baselines appropriate to the task: rules for amounts and expiry dates, structured LLM outputs for extraction plus explanation, a dedicated classifier for stable high-volume categories, or a local model for on-device processing. Classifiers need training data and updates; local models need device resources and distribution. Compare Decisions’ ease of experimentation and reuse against those options’ quality and operating burden.

Before expanding a successful trial, define when to revert: restore existing routing if misroutes increase, or return to post-utterance display if intermediate voice feedback is unstable. Keep comparable cases for model and question changes. A separate decision process can be replaced and evaluated in isolation, which should make both adoption and rejection concrete choices.

OpenAI pricing / Official prompt caching guide / Official Decisions guide / Decisions API reference

Choose a decision worth separating in your application

Sending the companion beyond the bridge required more than an engaging reply. The request had to become a selection, the game had to validate it, and dialogue had to reflect the confirmed action. Decisions is one option for recurring interpretation and evaluation within that flow. Even where an ordinary LLM already supports it, the question is whether a separate part would make improvement easier to measure.

Choose one input in your application, the result you need, and what that result changes. A free-form billing message might yield a destination and missing information, which prepare the reviewer’s view and a follow-up question. If the result changes no downstream work, the added decision has little purpose. Recurring branches shared across multiple entry points are more concrete candidates.

Add a fallback and an existing approach to compare. The NPC can ask for a destination; voice can wait for a completed utterance; document review can return to a person. This defines a test of sustained usefulness as well as a feature experiment. Trace how changing one decision affects the user’s experience or work.

Interpreting ambiguous inputs into selections lets AI affect actions, preparation, routing, and review targets as well as prose. A separate Decisions interface makes sense where those selections recur, the outputs and receiving processes are clear, and quality and total cost can be compared. A defined task lets developers test one useful part while keeping generation, rules, and human review around it.

Sources and scope

Specifications and pricing checked October 23, 2026; GA announced October 22. Application designs and cost calculations are LATENT proposals and illustrative arithmetic. Official examples are identified in the voice and review sections. No API latency or accuracy benchmark, production deployment, or operational test of these proposed applications was performed.

• OpenAI GA announcement
• Official Decisions guide
• Official voice integration guide
• OpenAI pricing
• Official prompt caching guide
• Decisions API reference
• Official Structured Outputs guide
• Related: running d1 alongside a game
• Related: dividing work with Strands Decider