# Fast, cheap, and boring: why the Decisions API matters > OpenAI's Decisions API is built for the small calls inside search and support. Here is what I would test first. - Edition: Weekly Visual Essay #2 - Published: 2026-10-26T16:19:45.430Z - Canonical URL: https://genailingo.com/newsletter/openai-decisions-api-product-teams/ ## Key Takeaways - OpenAI made its Decisions API generally available on October 22. It answers bounded questions with a probability, a choice, or a score, and it charges only for input tokens, at $0.10 per million. - Early customers quoted by OpenAI report big speedups. Sierra says it picks next actions in live customer conversations in under 280 ms at p95. Treat these as vendor numbers and test on your own data. - For search and support teams, the opening is in intent detection, routing, and escalation: small calls that today run on brittle rules or on general models too slow for the hot path. - Also this week: AI helped uncover PHP2Shell, two critical PHP flaws; Anthropic previewed Claude Duet; OpenAI models are coming to Google Cloud; and OpenAI gave its Open Responses spec to the Agentic AI Foundation. ## Article The short answer What is the OpenAI Decisions API? It is an endpoint (POST /v1/decisions) that takes text, images, or JSON plus a list of questions you write, and returns a typed answer for each question: the probability that something is true, one option from a fixed list, or a score on a rubric. It runs on GPT-6 Luna. OpenAI says it is about 10x faster than the same model through the Responses API, and it costs $0.10 per million input tokens with no charge for output. Why I picked this story Most AI coverage goes to the biggest models. This week I spent more time on one of the smallest launches. When I think about where AI changes a product, I rarely think about a chatbot writing a paragraph. I think about the quiet calls a system makes before a customer sees anything. Is this search query about a product or a brand? Should this out of stock item show a substitute? Is this customer about to give up on the chat? Each call is simple. A busy app makes a huge number of them, and many sit directly in the path of a page load or a reply. That is the problem OpenAI is going after. In its own words, "Applications and agents make many small decisions throughout a workflow... Individually, they are simple. At scale, their latency and cost add up." What OpenAI shipped The Decisions API became generally available on October 22 after a public beta. You define a question and its allowed answers, pass in the context, and get back one of three answer types, as described in the developer guide: - A predicate returns a probability from 0 to 1 that a condition is true, for example whether a product photo shows visible damage. - A choice picks one of the values you supplied, for example which department should handle a complaint, and also returns probabilities for every option plus a confidence value. - A score rates an input against 2 to 10 ordered levels you define, for example issue severity, and returns a probability weighted average of the levels. What changed since the beta, per OpenAI's announcement and the guide: - Up to 400 questions per request, double the earlier limit of 200. - Native JSON input, so you can pass an order record or a product object without flattening it into text. - Images inside question instructions, so each question can compare its own image against shared evidence. - Prompt caching for shared context, plus a native integration with GPT-Live, OpenAI's voice product. - Inference residency in the US and EU, and extra capacity in several Asian regions to cut latency. Two limits are worth knowing. gpt-6-luna is the only supported model today. And OpenAI's guide is clear that this is a narrow tool: if you need a model to write an object that follows your own JSON schema, or to call a tool with arguments, you should use Structured Outputs or function calling instead. The numbers customers are reporting OpenAI's launch post quotes five early users. All of these figures come from that announcement page: - Sierra uses it to choose the next action in live customer conversations. It reports under 280 ms at p95 (meaning 95% of calls finish faster than that), about 3x faster and 90% lower cost per call than its previous approach, "with no drop in customer outcomes." - Box classifies business documents and routes them to the next step. In its evaluation it saw about 5x faster route selection on 30 certificate of insurance cases, with the same accuracy as the Responses API, and it sends lower confidence cases to human reviewers. - Datadog scores the risk of agent generated shell commands before running them, and reports 40x faster p95 latency than available frontier models, with comparable accuracy. - Ramp says attributing its AI costs to the actual work became 4x faster and 30% cheaper compared with GPT-6 Luna, without losing accuracy. - Speak says that in its testing of the GPT-Live integration, time to next action for language learners dropped from 1.4 seconds to 0.13 seconds. My read: these are strong numbers, and they are also hand picked by the vendor for a launch post. Box's test covered 30 cases. None of the quotes share accuracy figures you can compare across companies. I treat them as a reason to run my own test before planning anything around them. Why this matters for ecommerce search Search is where I see this launch fitting most naturally. What follows is a general practitioner's view. Search runs on small classifications Before a search engine ranks a single product, it usually has to answer several questions about the query. Is this a product query, a brand query, or a category browse? Which category is most likely? Does the shopper want a specific model or anything that fits a need? In multilingual markets, the same intent can also arrive in different languages, or in one language typed in another language's script. Teams usually answer these with a mix of hand written rules, small trained classifiers, and lookup tables. Rules are cheap and fast, but they often break on new phrasings. Trained classifiers work well, but each new label means new training data. A general LLM call understands the query, yet it is often too slow and too expensive to sit in front of every query. A decisions endpoint sits between those options. You describe the labels in plain language, the model picks one, and you get a probability distribution back. If the customer numbers above hold up in practice, it becomes realistic to put a language model inside latency sensitive paths that used to be off limits. The probability is the product feature The part I like most is that every answer comes with probabilities and, for choices and scores, a confidence value. That gives a product team something to design with. A high confidence intent can trigger a direct jump to a category page. A low confidence one can fall back to broad results, or ask the shopper a quick clarifying question. Box already works this way: it sends lower confidence cases to reviewers. OpenAI's guide makes the same point, telling developers to set thresholds with labeled examples, based on the cost of false positives and false negatives. To me, the hard part of AI in search is usually deciding what the product should do when the model is unsure. Getting an answer out of a model is the easier half. An API that says how sure it is gives that discussion a real number to work with. Images and JSON open up catalog work Search quality depends on catalog quality. OpenAI's own example is a predicate that checks whether a product photo shows visible damage, and the guide shows a question that compares a candidate image against a reference image. With JSON input you can pass a product record as is. I can see this being useful for checks like whether a listing's photo matches its category, or whether a title and its attributes disagree. These are ideas I would test. I have no results to share on them. Why this matters for travel and customer support Support is where I expect this kind of tool to matter fastest. A support assistant makes routing calls on every turn. Is this a refund request? Is the traveler already on their trip? Should a human take over now? Sierra's quote describes exactly this use: choosing the next action inside live customer conversations. OpenAI also describes a voice support agent using Decisions inside GPT-Live to decide whether to ask a clarifying question, route a request, or escalate. My view is that travel raises the stakes on escalation. A problem with a flight later today has a deadline that a problem with a delayed parcel usually does not. A fast, cheap score for urgency on every message is the kind of signal that can move an urgent case to a person sooner. Getting that threshold wrong in either direction has a real cost, which is why I would want labeled conversations before trusting it. What I would check before shipping it Calibration A probability of 0.9 is only useful if it means roughly 90% in your data. Build a labeled set from real traffic, as the guide recommends, and pick thresholds per decision. Where the data is processed Regional processing is supported in the United States and Europe. For teams with local data rules, check this against your policies before sending customer messages. Lock in Today this is an OpenAI specific endpoint on a single model. I would keep it behind your own internal interface, so you can swap in a trained classifier or another provider for any decision later. Real cost The list price is low. As simple arithmetic: a decision that reads 1,000 input tokens, run one million times, is one billion input tokens, or about $100 at $0.10 per million. Cached input is $0.01 per million, and caching kicks in only when the shared prefix is at least 1,024 tokens. Cache writes, regional processing premiums, and long context multipliers can change the total, so model your own traffic. Try the math: monthly cost at list price Adjust the inputs to estimate uncached input cost at $0.10 per million tokens. Cache writes, regional premiums, and long context multipliers are not included. Input tokens per decision Decisions per day Estimated cost per 30 days: $300.00 Illustrative arithmetic based on OpenAI's published Decisions API price of $0.10 per million uncached input tokens. What this means for your work this week - Write down the recurring yes, no, or pick one questions your product answers today. Note which ones sit in a latency sensitive path and how each is answered now. - Pick one that is high volume and low risk, for example query category prediction or ticket routing. - Label a few hundred real examples and compare your current approach with a decisions style call on accuracy, p95 latency, and cost per thousand calls. - Decide up front what the product does at low confidence. That fallback is the actual product decision. Also this week AI helped uncover PHP2Shell, two critical flaws in PHP On October 21, PHP shipped fixes for two flaws, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution. Google Cloud lists the severity as critical, with a CVSS score of 9.2, and says every version from 5.4 through 8.5.11 is affected. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The PHP project is not releasing fixes for 8.1 or earlier, which have reached end of life. CISA urged immediate patching, while noting it had not seen successful exploitation at the time it published. The AI part: OpenAI says the security firm Calif found a critical flaw using GPT-5.6 Sol, and Wiz says it used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol, and that frontier models "substantially reduced" the barrier to turning flaws that had been present for decades into working exploits. Wiz notes PHP powers WordPress, Joomla, Drupal, and MediaWiki. My take: if any of your storefront, blog, or campaign sites run on PHP, ask your engineering team for patch status today. It is a five minute question. Anthropic previews Claude Duet, an assistant that comes to you first Anthropic opened a waitlisted research preview of Claude Duet on October 21 for US Pro and Max subscribers. It is built around Claude Opus 5.5, sends a morning brief, checks connected accounts every few hours, and works on its own cloud computer while you are away. Before it sends a message, makes a payment, signs a document, or deletes anything, it shows you the action and waits for approval. Reuters reported that it can make purchases through Stripe's Link wallet and Shopify's Shop Pay. My take: for commerce teams, agents that can pay with a wallet are a sign that some checkouts will soon have a software assistant on the other side. I expect clear product data and predictable checkout flows to matter more as that happens. OpenAI models are coming to Google Cloud OpenAI and Google Cloud announced on October 21 that OpenAI models will be sold through Google Cloud's Model Garden. Google Cloud says GPT-6 Astra, GPT-6.1 Sol, and GPT-6 Luna are rolling out in private preview to select enterprise customers, and that usage can draw down existing cloud commitments. OpenAI says general availability is planned in the coming weeks and that Microsoft remains its primary cloud partner. My take: for teams already on Google Cloud, buying OpenAI models may soon be a billing question instead of a new vendor contract. That makes picking a model per task easier. OpenAI hands Open Responses to the Agentic AI Foundation OpenAI is donating its Open Responses specification to the Agentic AI Foundation, part of the Linux Foundation, according to The New Stack. The spec aims to give developers one shared format for messages, tool calls, and similar building blocks across model providers. Anthropic's Agent Skills and Hugging Face's OpenEv framework are joining the foundation too, and Vercel AI Gateway and Databricks Model Serving already implement the spec. My take: this pairs well with the lead story. Shared formats lower switching costs for general model calls, while new specialized endpoints like Decisions pull the other way. Product teams should keep an eye on both. The takeaway Big models get the headlines, yet a lot of product quality is decided by small, fast calls nobody sees. The Decisions API is OpenAI's bet that those calls deserve their own tool. If you run search, support, or any high traffic flow, pick one decision this week and test whether it holds up on your data. ## Workflow Pattern of the Day: OpenAI Decisions API **Verdict:** Worth testing for high volume classification or routing in latency sensitive paths. Check calibration on your own data first. Route support tickets or classify search queries by defining a choice question with your labels, then acting on high confidence answers and sending low confidence ones to a fallback or a human. ## Frequently Asked Questions ### What is the OpenAI Decisions API used for? It is for bounded questions with a fixed answer type: checking a condition, picking a category, or scoring against a rubric. OpenAI's guide lists uses like classifying content, routing requests, and prioritizing work. It accepts text, images, and JSON, and handles up to 400 questions per request. ### How much does the Decisions API cost? Uncached input costs $0.10 per million tokens, cached input costs $0.01 per million, and output tokens are free. Cache writes, regional processing premiums, and long context multipliers apply on top. ### When should I use Decisions instead of Structured Outputs? Use Decisions when you need a probability, a choice from a fixed list, or a score. Use Structured Outputs or function calling when the model needs to generate fields, write an explanation, or call a tool with arguments.