OpenAI's Decisions API gives Luna a smaller job: choose from answers you define

[OpenAI introduced Decisions API](https://openai.com/index/devday‑2026‑recap/) at DevDay 2026 as a fast decision layer powered by a model it calls Luna. Developers define questions with a finite set of acceptable answers, supply context as text or images, and receive a result that can classify content, route a request or choose an agent's next action. The constraint is the point. A support system may ask which of five queues should receive a ticket. A commerce workflow may decide whether an image belongs in one of a fixed set of moderation categories. An agent orchestrator may choose `research`, `ask_user` or `stop` from a known policy. These jobs do not need a long essay; they need an answer that downstream software can validate and map to a permitted branch. The [OpenAI organization profile](https://opentools.ai/organizations/openai) supplies the verified maker relationship. OpenAI's launch materials name Luna, but they do not identify a versioned model, endpoint or pricing schedule. That distinction matters: developers should not assume that a separate Luna model listing supplies Decisions API's limits or billing terms.

A finite output space can simplify validation. The caller knows every permitted value, can reject an unknown answer, attach different permission levels to each branch and fall back to a human when confidence or context is inadequate. It also makes an offline evaluation easier to define: every test case has a target class or action and a measurable error cost. That does not make the decision automatically correct. A constrained model can still choose the wrong valid answer, respond to misleading context or inherit bias from the categories a developer defined. The most consequential design work moves upstream into the label set, examples, escalation rule and cost of a false positive versus a false negative. For agent routing, the output should be treated as a recommendation to a policy layer. A decision such as `send_message` or `approve_refund` should not itself grant permission. The application must still enforce authorization, amount limits, account state and any required human confirmation. The API narrows the model output; it does not replace the surrounding control system.

[In his launch post](https://x.com/thsottiaux/status/2104986448269279399), OpenAI's Tibo Thibault said Decisions API is tuned to make end‑to‑end decisions in less than a few hundred milliseconds. OpenAI's official recap calls it real‑time decision‑making but does not publish a latency distribution, region, input size, concurrency level or service‑level agreement. Teams should therefore test the actual request shape before putting the API on a critical path. Record median, p95 and p99 latency separately for text and image inputs; include network time, retries and any fallback; and measure the deadline that matters to the product. A routing decision for an asynchronous queue has a different latency budget from one sitting between a user click and a payment confirmation. The launch's emphasis on fast constrained decisions can make high‑volume classification attractive, but OpenAI has not yet published Decisions API pricing in the announcement. The correct cost model remains unknown until the preview documentation or billable meter is available. Using Luna's token prices as a substitute would be an unsupported assumption about the API's packaging.

[Decisions API is in limited preview](https://openai.com/index/devday‑2026‑recap/) on September 29. OpenAI says a broad release is planned in the coming days. No dedicated public product documentation was linked from the recap at publication time, so the launch evidence supports the capability outline, input types, example jobs and rollout state—nothing more. A sound preview test starts with one reversible decision. Define mutually exclusive answers, include an explicit `unknown` or `needs_review` path, build a balanced labeled set and decide the maximum acceptable error for each class before calling the API. Test confusing and adversarial inputs, then compare accuracy and latency against the existing rule or classifier. Keep high‑impact actions behind the application's own authorization and audit trail. The decisive metric is not whether the API returns a valid label quickly. It is whether the full workflow makes fewer costly mistakes at an acceptable tail latency and price. That evidence can be collected as the preview expands; until then, the announcement should be read as a constrained‑decision interface powered by Luna, not a proven replacement for every classifier or routing rule. *Figure: Decisions API request‑to‑action flow. Sources: [OpenAI's DevDay recap](https://openai.com/index/devday‑2026‑recap/) and [Tibo Thibault's launch post](https://x.com/thsottiaux/status/2104986448269279399), September 29, 2026. Figure by OpenTools Team; no third‑party expressive material used.*