What Is OpenAI Decision API? Features, Access, and Jev Compared

A customer writes, “My order arrived, but the charger is missing.” Your app needs to send that message to the right team. A helpful paragraph is useful later. Right now, you need a category your software can act on.

That is the kind of problem behind OpenAI Decision API searches. The official product name is OpenAI Decisions API, with an “s.” OpenAI announced it at DevDay on September 29, 2026: a Luna-powered interface for questions with a fixed set of possible answers, using text or image context. The launch status is limited preview. OpenAI's announcement is the source for those details.

This guide explains the idea, compares it with Jev, and shows how to prepare a useful first test. You can explore the decision workflow now in the Jev AI Playground; the Playground runs Jev, and does not currently provide the OpenAI Decisions API.

What is OpenAI Decision API?

Think of it as a small decision step inside an application. You define the question and the available answers before sending the context. The result gives your application a selection it can use in its next step.

For the missing-charger example, you could ask which support queue owns the issue. Your options might be missing_item, billing, technical_help, and needs_review. The useful work is interpreting the customer's message within those boundaries.

OpenAI describes classification, request routing, and selecting an agent's next action as intended uses. The announcement does not provide a public request schema. Examples in this article are therefore workflow designs, rather than copy-and-paste OpenAI API calls.

There is also a naming trap. OpenRouter has a separate Decisions API for decision models. An OpenRouter example is not automatically an OpenAI integration, even if both use the word “decisions.” Check the provider and documentation before reusing code.

Why developers are interested

Many useful AI features involve a short answer repeated thousands of times. Which folder should this document go into? Does this message need a person? Which tool should an agent try next?

Those questions explain much of the practical interest in an OpenAI Decision API. For a working application, developers usually need to resolve four things:

• Access: Can my account call it, and is there a documented interface?
• Quality: Does it choose correctly when the wording is unclear?
• Cost and speed: What happens with long context and repeated questions?
• Fit: Does it improve on Jev, a classifier, or my existing LLM setup?

These are research questions, not measured search-volume rankings. One early Reddit discussion about reusable questions and caching points to a concrete concern: developers may send the same decision rules over and over. That makes billing and reuse worth investigating. It does not establish that this preview supports either feature.

OpenAI Decision API features: what matters in practice

A fixed answer set

The answer list becomes part of your application design. A support queue can accept a known label without guessing whether “payment problem” means the same thing as “billing.”

Good labels still take work. complaint and refund overlap: a customer can be complaining while requesting a refund. You might instead ask two questions, one about the topic and another about the requested action. Clear boundaries help you understand mistakes when they happen.

Include somewhere for incomplete cases to go. If all options assume you already know what happened, a vague message can produce a precise-looking but unhelpful answer.

Text and image context

Image input is part of the announced scope. A possible application would classify a photographed delivery problem alongside the customer's description. That is an example to evaluate, not a claim about tested accuracy.

Images can add evidence, but they can also hide it. A dark photograph may not show whether a cable is missing or simply outside the frame. Test blurry images and conflicting descriptions, not just clean product photos.

A decision inside a larger workflow

Choosing request_more_information is only one part of helping a customer. Your application still has to ask a sensible question, save the response, and decide when the case is complete.

Keep that division visible when planning an OpenAI Decision API integration. The decision component selects a next step; your software owns the workflow and the permissions needed to perform it.

OpenAI Decision API vs Jev

Jev is TypeSafe's dedicated structured decision model. Its API reference documents Choice, Score, and Noul questions. Choice returns an option with probabilities; Score evaluates a defined rubric; Noul handles yes/no questions.

The following comparison covers documented capabilities as of September 30, 2026. It is not a performance ranking, and we have not run a head-to-head benchmark.

TypeSafe's current model reference lists Jev 1.13 as text-only. For an image task, converting a photo to a text description adds another processing step and can lose information. Compare complete workflows if one system sees the original image and another sees a summary.

For a text-only queue, the more useful comparison may be which system makes fewer expensive mistakes. Sending a billing question to technical support wastes time. Sending an unclear case for review may be acceptable. Count those outcomes separately.

How it differs from Structured Outputs and function calling

You can already build a classifier with a general-purpose model. OpenAI's Structured Outputs guide explains how supported models can return data that follows a supplied JSON schema. An enum can restrict a category field to your allowed labels.

That gives you another way to build a bounded decision. It also lets you combine the label with generated text, such as a short explanation. However, a response that follows the schema can still contain the wrong classification.

Function calling addresses tool interactions. The model can request a function with arguments; your application handles executing it. A decision label by itself does not execute a tool.

For example, an overdue-invoice rule may only need a date comparison. A message saying “I think I paid this already” requires interpretation. Use each approach where it earns its place.

How to plan an OpenAI Decision API integration

At review time, we could verify the launch description but could not find a Decisions-specific public endpoint or SDK example in the official API reference and changelog. We therefore cannot provide a verified curl command for it yet.

You can still prepare the application side. Start with a small decision specification:

This is a planning example, not an official OpenAI payload. Once your account has access, map these parts to the documented request fields and validate the returned answer against your allowed list.

Handle timeouts separately from uncertainty. A failed request means you did not receive a decision. A needs_review answer means the decision step completed and chose review. Combining them in one metric makes problems harder to diagnose.

For a first rollout, record suggestions alongside the existing process. Let support staff correct them before you automate routing. Those corrections give you useful evidence about the wording, label boundaries, and cases that need more context.

OpenAI Decision API pricing and access

The launch announcement says wider release is planned, but that is not the same as access being enabled for every account. Check current availability before scheduling implementation work.

We did not find a dedicated OpenAI Decision API pricing entry in the official pricing page checked for this article. Luna's ordinary token price should not be presented as the price of this interface. The announcement also leaves details such as question limits and response fields unresolved.

When pricing becomes available, estimate the cost of your actual request. Include the context, label descriptions, number of questions, image processing where applicable, and retries. A short answer can still require a long input.

Then add the cost of mistakes and manual review. A cheap call is useful only if it helps the team finish the job. For support routing, cost per correctly handled ticket is often easier to reason about than token prices alone.

Try the decision pattern in the Jev AI Playground

You do not need to wait for another API to explore whether your question is well defined. Open the Jev AI Playground and choose Your own case.

1. Paste the missing-charger message into Text to evaluate.
2. Add a Choice question asking which team should handle it.
3. Define the four categories from the example, with clear descriptions.
4. Select Run Jev and inspect the live result.
5. Change the message to “Something is missing” and compare what happens.

The second input is deliberately vague. It helps you see whether your review option does useful work. Try a billing complaint next, then a message that contains two problems. Keep the questions unchanged so the comparison means something.

Our Jev examples provide more starting points. Treat illustrative answers as explanations; use results from your own run when evaluating behavior. This exercise gives you a Jev baseline for a later OpenAI comparison, rather than evidence about how OpenAI would answer.

Frequently asked questions

Is OpenAI Decision API the official name?

The official name is OpenAI Decisions API. The singular wording refers to the same product in this guide.

Does it replace Jev?

That depends on the workload. Compare the same inputs, labels, review rules, and operating costs. A new launch alone does not establish better results for your application.

Can it explain why it chose an answer?

Do not assume that it returns a written explanation. The public launch description does not establish an explanation field. If explanations are essential, make them part of your evaluation requirements.

What should I test first?

Choose one recurring decision with a clear expected answer. Collect ordinary cases, ambiguous cases, and examples where a wrong answer causes extra work. Start with that small set in the Jev AI Playground, refine your categories, and keep it for future comparisons.