{"schema_version":"1.0","service":"Publicasta","type":"article","id":964,"slug":"decisions_api_narrow_ai_routing_workflows","title":"OpenAI’s Decisions API Targets the Small Choices That Slow Down AI Workflows","excerpt":"OpenAI’s new Decisions API is built for fast classification, routing, scoring, and escalation—not open-ended generation. Its low input price is appealing, but reliable deployment still depends on thresholds, review paths, caching, and strict control of what a decision is allowed to trigger.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=en","image":{"url":"https://publicasta.com/storage/projects/8/pages/964/2026/10/a98d089e-7151-40b0-946f-5ff74235001a.webp","alt":"Editorial technology photograph of an abstract AI decision-routing workflow on a monitor."},"publisher":{"id":8,"slug":"ai_practice","name":"AI Practice","url":"https://publicasta.com/ai_practice"},"author":{"name":"Anton R"},"published_at":"2026-10-25T10:07:08+00:00","updated_at":"2026-10-25T10:07:08+00:00","content_markdown":"OpenAI’s new Decisions API is aimed at a part of AI software that rarely appears in launch demos: the small choice made between two larger steps.\n\n ![Editorial technology photograph of an abstract AI decision-routing workflow on a monitor.](https://publicasta.com/storage/projects/8/pages/964/2026/10/a98d089e-7151-40b0-946f-5ff74235001a.webp)\n\n Should this support request go to billing or technical support? Is a document complete enough to enter the next workflow? Does a generated shell command look safe to run automatically? Should a voice assistant ask a clarifying question, transfer the conversation, or continue?\n\n These decisions are easy to describe and expensive to perform badly. If an application makes one on every incoming message, document, transaction, or tool result, latency accumulates. The cost of sending each question through a general-purpose model accumulates too. A wrong classification can also send work into the wrong queue, expose information to the wrong operator, or trigger an action that should have waited for review.\n\n OpenAI made the Decisions API generally available on October 22, 2026. It runs on GPT-6 Luna and returns typed answers rather than a paragraph: a probability, a choice from a predefined set, or a score against an ordered rubric. OpenAI says the endpoint is designed to answer these bounded questions up to 10 times faster than using GPT-6 Luna through the Responses API. The company lists a price of $0.10 per million input tokens, with no output-token charge for the endpoint.\n\n That combination makes Decisions interesting for teams already building AI products. It is less interesting as a replacement for a general assistant. The useful question is not whether the model is capable of reasoning. It is whether a team can define a narrow decision well enough to measure it, put a sensible threshold around it, and keep the resulting action inside a controlled workflow.\n\n ## What the API actually returns\n\n The endpoint accepts shared evidence and one or more questions. The evidence can be text, an ordered conversation with tool calls and outputs, images, or structured JSON. Each question has a type, a name, instructions, and, where relevant, a set of allowed choices or ordered score levels.\n\n A `predicate` estimates whether a condition is true and returns a probability between zero and one. This fits questions such as “Does this ticket describe a duplicate charge supported by the order record?” or “Does this image show visible damage?”\n\n A `choice` selects one value from a predefined set. A routing system might offer `billing`, `technical_support`, `account_access`, and `human_review`. A voice application might choose `continue`, `clarify`, `transfer`, or `end_call`.\n\n A `score` evaluates an input against ordered levels, such as low, medium, and high severity. The response includes probabilities for the levels and a probability-weighted average. That average can fall between two levels, which is useful for ranking but dangerous if a developer treats it as a magically precise measurement.\n\n The endpoint can ask up to 400 questions in one request, an increase from the 200-question limit during the public beta. That matters when many independent attributes can be evaluated against the same evidence. It does not mean that dependent decisions should be bundled together. If question two should only be asked after question one is answered, separate requests make the control flow easier to inspect and test.\n\n The API’s typed output is the main product distinction. A general model can be instructed to return JSON, but a developer still has to validate that output and handle malformed or ambiguous values. Decisions constrains the answer space at the API level. That reduces parsing work, but it does not make the underlying judgment correct.\n\n ## Where it fits in a real application\n\n The strongest use cases are repetitive decisions with a bounded answer set and a clear next step. Think of the endpoint as a fast judgment layer inside an existing program, not as an autonomous employee.\n\n A document workflow could use it to decide whether an uploaded certificate contains the required fields, identify a document category, and route the item to the appropriate queue. The document extraction itself may still need a separate system. Decisions answers the narrower question of what should happen next.\n\n A support system could classify a ticket, estimate urgency, and determine whether the customer’s message contains enough information for a first reply. A low-confidence result could go to a human queue instead of being used to send an automatic answer.\n\n An agent orchestration system could use a choice question to select the next tool from a small, reviewed set. For example, an incoming request might be routed to a search tool, an account lookup, a scheduling function, or a clarification step. The model chooses among those options; the application remains responsible for permissions, argument validation, rate limits, and execution.\n\n A security or operations workflow could score a proposed action before execution. OpenAI cites Datadog using the endpoint to assess agent-generated shell commands before autonomous remediation. That is a potentially useful pattern, but it should not be interpreted as a complete security boundary. A model-based score can add a review signal. It cannot replace command allowlists, sandboxing, identity checks, filesystem restrictions, or an approval policy.\n\n Voice applications are another natural fit because a slow decision is noticeable to the person speaking. Decisions now has native GPT-Live integration and can be triggered as input or output transcripts arrive. An application might decide whether the assistant should ask for clarification, transfer a call, or update an interaction state. OpenAI says Speak reduced the time to its next action in testing from 1.4 seconds to 0.13 seconds with its integration. That is a vendor-reported result, not a guarantee for every voice stack, but it illustrates why a specialized endpoint can matter more in an interactive loop than in a batch process.\n\n ## The practical architecture: model, threshold, action\n\n A reliable implementation needs three separate layers.\n\n The first layer is the question. It should describe observable evidence and distinguish neighboring answers. “Is this good?” is not a production question. “Does the message contain a request to cancel a paid subscription, rather than a request for pricing information?” is much closer to one.\n\n The second layer is the policy that interprets the answer. A probability of 0.82 does not mean that the application must act. The team has to decide whether 0.82 is sufficient for an automatic route, whether 0.55 should trigger review, and whether certain categories always require a person regardless of confidence.\n\n The third layer is the action. The model should not be granted broad authority merely because it returned a valid choice. The application should map an allowed value to a known function and reject anything outside that mapping. Sensitive operations should require independent authorization and, where appropriate, a human confirmation.\n\n This separation also makes evaluation possible. Teams can change a threshold without rewriting the prompt. They can compare model decisions with labeled examples. They can measure false positives and false negatives according to the cost of each error. A fraud filter, a support router, and a content moderation queue should not use the same threshold simply because they use the same API.\n\n OpenAI’s developer guidance makes a similar point: use labeled examples from the application to set thresholds. The advice is easy to overlook because the endpoint returns probabilities and confidence values that look quantitative. Those numbers are useful for ranking and routing only when they have been calibrated against the organization’s own data.\n\n ## Prompt design is now policy design\n\n A narrow decision still depends heavily on the evidence and instructions supplied to it. The prompt should define what counts as supporting evidence, what to do when evidence is missing, and how to distinguish a borderline case from a clear one.\n\n Suppose a team wants to route invoices. A weak question might ask the model to “choose the right department.” A production question would specify the available departments, the fields that identify each one, the meaning of an incomplete document, and the rule for conflicting signals. It might also include an explicit `human_review` option rather than forcing the model to choose a business queue when the input is ambiguous.\n\n Examples should cover normal cases and failure cases. Include short messages, long messages, mixed languages if the product accepts them, contradictory records, missing fields, malformed JSON, and attempts to inject instructions into the evidence. The evidence is data. It should not be allowed to rewrite the decision policy.\n\n For image decisions, define what the model can actually see and what it cannot establish. A photo may show a dent but not prove the cause of damage. A screenshot may show an error message but not prove that the account is compromised. The answer space should reflect that distinction.\n\n When several questions share the same source document or conversation, place the reusable material in shared input and vary the question instructions. The API supports prompt caching for this pattern. The documentation says the reusable prefix must contain at least 1,024 tokens, and that cached input receives discounted pricing. Caching can reduce cost and latency, but it also means developers need to understand cache boundaries and avoid placing caller-specific or sensitive material in a prefix that could be reused in the wrong context.\n\n ## Cost is low, but volume changes the calculation\n\n The published Decisions price is $0.10 per million uncached input tokens, with cached input priced at $0.01 per million tokens. There is no output-token charge for the endpoint. At first glance, that makes many routing tasks almost free.\n\n The actual bill depends on how much evidence is sent with every question. A repeated policy document, conversation history, or tool output can be much larger than the instruction itself. Sending the same large context separately for every decision defeats the purpose of a small classifier. Caching helps when the prefix is stable, but cache writes and regional processing can add cost.\n\n Teams should measure cost per completed business task rather than cost per API call. If a classifier rejects an item and sends it to a manual queue, the model call may be cheap while the overall process becomes slower. If an automatic route creates an incorrect downstream action, the cost of correction may dwarf the token bill.\n\n The endpoint can ask many independent questions in one request. That can reduce request overhead, but it should not become an excuse to ask every conceivable question about every item. Extra questions increase complexity, make evaluation harder, and may encourage teams to act on scores that no one has validated.\n\n A sensible pilot records at least the input-token count, cache-hit rate, latency percentiles, answer distribution, review rate, correction rate, and downstream completion time. For interactive products, p95 latency matters more than the average. For back-office queues, throughput and reviewer workload may matter more.\n\n ## Privacy and regional controls\n\n The API supports inference residency in the United States and Europe, and OpenAI says Zero Data Retention is available to eligible customers. The developer documentation also lists HIPAA support for eligible customers and describes Private Link availability. These are useful controls, but eligibility, contracts, endpoint configuration, and feature limitations still need to be checked by the organization deploying the system.\n\n Regional processing is not the same as a complete privacy strategy. A team must still decide whether the input contains personal data, whether it is necessary to send the full record, how long application logs retain the request and response, and who can view usage reports. Redaction and minimization should happen before the model call where practical.\n\n Structured JSON does not make sensitive information safe by itself. A customer record passed as `input_json` is still customer data. Images are still sensitive if they contain faces, addresses, medical information, or confidential screens. The right question is not whether the API accepts the format; it is whether the workflow has a defensible reason to transmit that information.\n\n The same caution applies to prompt caching. Reusing a stable reference document is efficient. Reusing a prefix that contains one customer’s private details across unrelated requests is a design error. Cache keys and boundaries should be part of the data-flow review, not an afterthought added during performance tuning.\n\n ## What Decisions does not replace\n\n The endpoint is not a general extraction system. If the application needs a rich object with many fields, a written explanation, or output that follows a custom schema, the Responses API with Structured Outputs may be more appropriate. If the model needs to request a tool with arguments, function calling may be the clearer abstraction.\n\n It is not a rules engine. A deterministic rule is preferable when the condition can be expressed exactly. For example, an account should not be treated as eligible because a model is confident that the account balance is below a threshold. The application can compare the balance directly.\n\n It is not a safety approval by itself. A “safe” choice from a model does not authorize an irreversible action. Use permissions, allowlists, sandboxing, transaction limits, approval steps, and audit logs around anything that can spend money, change access, send a message externally, modify production data, or execute code.\n\n It is not a replacement for human review in ambiguous or high-impact cases. A typed answer is easier to consume than free-form text, but clean serialization can make an uncertain judgment look more authoritative than it is. The system should preserve confidence, evidence references, and the reason a case was escalated.\n\n ## A small pilot that can produce useful evidence\n\n A team considering the endpoint should start with one recurring decision that already has a measurable outcome. Do not begin with a workflow whose success depends on five model calls and several poorly defined handoffs.\n\n First, collect a sample of real inputs and have qualified reviewers label the correct action. Keep the labels separate from the prompts used for testing. Include difficult and borderline examples rather than selecting only obvious cases.\n\n Next, write a finite answer set. Add `human_review` when uncertainty is a legitimate outcome. Define what each answer authorizes and what it does not authorize. If the action cannot be stated clearly, the decision is probably too broad.\n\n Then test three operating modes: automatic routing above a high threshold, review in an intermediate band, and a safe fallback below the lower threshold. Compare those results with the current process. A pilot that merely reports model accuracy without measuring reviewer load or downstream errors will not answer the business question.\n\n Log enough information to reconstruct a decision without storing more sensitive data than necessary. Record the version of the question, model, threshold, answer, confidence, action taken, and later correction. If a prompt changes, treat the change like a software release and rerun the evaluation set.\n\n Finally, run the endpoint beside the existing workflow before allowing it to control actions. Shadow mode can reveal where the model disagrees with experienced operators, where the evidence is incomplete, and where a supposedly simple decision hides an exception policy.\n\n ## Who should try it—and who should wait\n\n The Decisions API is worth testing for teams that already have a narrow classification, routing, scoring, or escalation problem; can define allowed outcomes; and have enough labeled examples to evaluate changes. It is especially promising when the current bottleneck is repeated latency in a live interaction or the cost of sending every small decision through a larger generative workflow.\n\n It may also fit products that need to evaluate multiple independent questions against the same text, image, or structured record. Prompt caching and regional controls improve the case for workloads with stable shared context and clear data requirements.\n\n Teams should wait if they are still searching for a use case, cannot explain what a correct answer looks like, or plan to let the endpoint choose arbitrary tools and actions. A low token price does not rescue an undefined policy. Nor should a fast response be used to hide the absence of authorization, review, or audit controls.\n\n The broader significance of the release is architectural. AI applications are moving away from one large request that tries to understand, decide, and act all at once. A more maintainable system separates those jobs: a model may interpret evidence, a bounded decision endpoint may choose among reviewed options, and ordinary software may enforce permissions and carry out the result.\n\n That division will not eliminate model mistakes. It does make them easier to measure, contain, and correct. For most teams, that is the practical reason to test Decisions—not that every workflow needs another AI endpoint, but that some workflows need a smaller and more accountable decision layer.","available_translations":[{"language":"ar","title":"تستهدف واجهة قرارات OpenAI الخيارات الصغيرة التي تُبطئ سير عمل الذكاء الاصطناعي","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=ar","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=ar","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=ar"},{"language":"de","title":"OpenAIs Decisions API zielt auf die kleinen Entscheidungen, die KI-Workflows ausbremsen","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=de","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=de","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=de"},{"language":"en","title":"OpenAI’s Decisions API Targets the Small Choices That Slow Down AI Workflows","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=en","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=en","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=en"},{"language":"es","title":"La API Decisions de OpenAI apunta a las pequeñas decisiones que ralentizan los flujos de trabajo de IA","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=es","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=es","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=es"},{"language":"fr","title":"L’API Decisions d’OpenAI cible les petits choix qui ralentissent les workflows d’IA","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=fr","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=fr","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=fr"},{"language":"pl","title":"Decisions API od OpenAI celuje w drobne wybory spowalniające przepływy pracy AI","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=pl","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=pl","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=pl"},{"language":"ru","title":"API Decisions от OpenAI нацелен на небольшие решения, замедляющие рабочие процессы ИИ","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=ru","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=ru","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=ru"},{"language":"zh","title":"OpenAI 的 Decisions API 瞄准拖慢 AI 工作流的小决策","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=zh","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=zh","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=zh"}],"_links":{"self":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=en","html":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=en","canonical":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=en","markdown":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=en","json":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/ai_practice","channel_articles":"https://publicasta.com/api/public/v1/channels/ai_practice/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}