OpenAI Decisions API: Guide, Examples, Pricing & Jev Comparison

OpenAI Decisions API is a specialized interface for making bounded decisions inside software. Instead of asking a language model to generate an unrestricted response, developers define a question and a finite set of possible answers, then use the returned selection to drive application logic.

That makes the API relevant to classification, routing, workflow branching, and agent control—tasks where software needs a decision rather than prose.

This guide explains how the Decisions API model fits into application architecture, how it differs from traditional LLM APIs and Structured Outputs, what is currently known about access and pricing, and how the approach compares with Jev and other typed decision models.

What Is OpenAI Decisions API?

OpenAI Decisions API is an API for making decisions from a predefined answer space. OpenAI describes it as a limited-preview API powered by Luna that can classify inputs, route requests, or choose an agent's next action from answers defined by the developer.

The key difference from a traditional generative LLM API is the output boundary. A normal model can generate arbitrary text. A decision system starts with an explicit question and a constrained set of valid outcomes.

Conceptually, the flow is:

Context
   ↓
Question
   ↓
Candidate Answers
   ↓
Decision
   ↓
Application Action

This model is useful when an application needs to decide which path to take, rather than generate a paragraph for a person to read.

The result is an architectural shift: model judgment becomes one component inside deterministic application logic.

How Does OpenAI Decisions API Work?

The public Decisions API documentation is still limited, so its final endpoint, request schema, response schema, limits, and SDK interfaces should not be assumed yet.

What OpenAI has confirmed is the central pattern: developers provide a bounded decision problem, and Luna selects from predefined answers for tasks such as classification, routing, and choosing an agent's next action.

The following components describe the general decision architecture without assuming an unpublished OpenAI request schema.

Context

Context is the information the model needs to make a decision.

For a support-routing decision, the context might include:

Customer message:
"I cancelled last week but my card was charged again."

Account state:
- Subscription: cancelled
- Charge status: completed
- Previous refund: none

The context should contain information relevant to the current decision, not every piece of data available to the application.

Reducing irrelevant state can make the decision easier to inspect and reason about.

For Jev, this same concept is exposed explicitly as state. The Jev documentation uses one shared state as input to typed questions.

Question

A decision question should ask for one clear judgment.

Good:

Which queue should this support request enter?

Less useful:

Analyze this customer, determine everything that is happening,
decide what the company should do, and explain your reasoning.

The first question creates a bounded interface between model intelligence and application code.

The second combines classification, policy, planning, and generation into one instruction.

Small questions are easier to test independently, easier to evaluate with labeled data, and easier to combine with deterministic rules.

Candidate Answers

Candidate answers define the valid decision space.

For example:

Question:
Which queue should this request enter?

Candidate answers:
- Billing
- Technical Support
- Account
- Human Review

Instead of generating "This looks like a duplicate billing issue and should probably go to...", the decision layer only needs to select a valid outcome.

OpenAI's current description explicitly centers the API on predefined answers.

This constraint is important because application code already knows every possible branch it may need to handle.

Decision

The decision is the model's judgment inside the answer space defined by the application.

Conceptually:

Input:
Customer was charged after cancellation.

Question:
Which queue should this request enter?

Answers:
Billing
Technical Support
Account
Human Review

Decision:
Billing

The application can then map Billing to a queue ID, service, workflow, or policy.

OpenAI has not yet publicly documented the final Decisions API response schema, so developers should not assume a specific JSON property, model identifier, or SDK method until the public reference is released.

Confidence and Application Logic

A production decision system should separate two responsibilities:

AI makes the judgment.
Application code controls the policy.

For example, a model might estimate that a request belongs to Billing. The application—not the model—should decide whether that prediction is sufficient for automatic routing.

Conceptually:

Model judgment:
billing = likely

Application policy:
high confidence     → route automatically
uncertain           → human review
high-risk condition → require manual approval

Whether OpenAI Decisions API exposes confidence scores or probability distributions in its final public schema is not publicly documented yet.

By comparison, Jev explicitly returns typed probabilistic decisions and confidence information intended for programmatic use. TypeSafe describes Jev as producing typed decisions with calibrated probabilities so software can apply thresholds and escalation rules.

You can inspect that pattern directly in the Jev playground.

OpenAI Decisions API Examples

The following examples describe decision workflows rather than official OpenAI API syntax.

Request Routing

A routing system decides where an incoming request should go.

Input

"My subscription was cancelled, but I was charged $49 this morning."

Decision

Billing

from:

Billing
Sales
Technical Support
Human Review

Application Action

route(ticket, BILLING_QUEUE)

This replaces brittle keyword routing without handing the model responsibility for the entire support workflow.

Agent Tool Selection

An agent often has several tools available but needs to select the next bounded action.

Input

User asks for the current status of an existing order.
The order ID is available.

Decision

Database

from:

Search
Database
Browser
Ask Human

Application Action

execute(order_database_tool)

The model chooses the action category. Application code still controls which tool implementation is permitted and how it is executed.

This is one of the use cases OpenAI explicitly identifies for Decisions API: selecting an agent's next action.

Customer Support Triage

Support triage often requires more than a single topic label.

Input

Customer:
"I've contacted you three times. My account is still locked
and I need access before payroll closes today."

Decision

Intent: Account Access
Priority: High
Escalation: Required

Application Action

priority_queue.enqueue(ticket)
notify_human_agent(ticket)

A production implementation could model these as separate narrow decisions rather than one large prompt.

That decomposition pattern is also used by TypeSafe's published workflow evaluations: independent narrow questions are combined with application rules to determine final actions.

Content Moderation

A bounded moderation decision can map a piece of content to a known handling policy.

Input

Incoming user-generated content

Decision

Review

from:

Allow
Review
Block

Application Action

moderation_queue.add(content)

The important boundary is that the model provides classification while the application owns enforcement.

A production moderation system may still need separate specialized safety models, legal rules, audit logs, and human review.

Model Routing

A decision layer can determine which model or execution path should handle a request.

Input

Short extraction request with a fixed schema.
No complex reasoning required.

Decision

Small Model

from:

Small Model
Large Model
Human

Application Action

provider.run(SMALL_MODEL, request)

This can help applications avoid sending every request to the most expensive or highest-latency model.

The decision itself should be evaluated independently: incorrect routing can erase the latency or cost savings that motivated the router.

Risk and Fraud Review

A decision model can provide one signal inside a risk workflow.

Input

Transaction amount: $2,400
Account age: 4 days
Shipping country differs from billing country
Three failed payment attempts preceded approval

Decision

Review

from:

Approve
Review
Reject

Application Action

send_to_manual_review(transaction)

For financial, security, employment, healthcare, or other high-impact workflows, a model output should generally be treated as one controlled input to a broader policy rather than unconditional authority to execute consequential actions.

Decisions API vs Traditional LLM APIs

A traditional LLM and a Decision API solve different interface problems.

A conventional LLM flow often looks like this:

Context
   ↓
Prompt
   ↓
Generated Text
   ↓
Parse
   ↓
Validate
   ↓
Action

A bounded decision flow is closer to:

Context
   ↓
Defined Question
   ↓
Defined Answers
   ↓
Decision
   ↓
Action

The distinction matters because open-ended generation creates an additional interpretation layer.

Suppose an application asks a normal LLM:

Classify this support ticket as Billing, Sales,
Technical Support, or Account.
Return only the category.

The prompt requests a bounded result, but the underlying interface is still text generation unless the API adds stronger structural guarantees.

Possible outputs may include:

Billing

but application developers often also have to consider responses such as:

The most appropriate category is Billing.

or a valid structured response with unexpected additional fields.

Structured-output features reduce this problem substantially, but the model is still being used through a general-purpose generation interface.

A Decision API begins from another abstraction: the application defines a decision space, and the model's task is to choose within it.

That affects several engineering concerns:

Concern	Traditional LLM API	Decision API
Core operation	Generate	Decide
Output space	Potentially open-ended	Bounded
Parsing	Often required without structured-output controls	Intended for direct application consumption
Validation	Application typically validates generated output	Valid outcomes are defined before inference
Latency profile	Depends on generated tokens and reasoning	Designed for bounded decision workloads
Application behavior	Generation must be interpreted	Selection maps naturally to predefined branches

This does not make one architecture universally preferable.

Use an LLM when the task requires generation, synthesis, research, explanation, or flexible reasoning.

Use a decision-oriented interface when the useful output is already known to belong to a small, explicit set of possibilities.

Decisions API vs Structured Outputs

A common question is:

Why can't I just use an LLM with JSON Schema?

You often can.

Structured Outputs and decision APIs overlap in production use cases, but they constrain different things.

Dimension	LLM + Structured Outputs	Decisions API
Primary task	Generate a response that conforms to a schema	Make a bounded judgment
Answer space	Can contain rich nested data, strings, arrays, enums, and generated values	Centered on developer-defined finite outcomes
Output	Schema-valid generated structure	Decision intended for direct application use
Typical use	Extraction, structured generation, tool arguments, complex objects	Classification, routing, scoring-style workflows, next-action selection
Application role	Produce structured information	Choose between known branches

The core distinction is:

Structured Outputs solves output format.

Decision APIs solve bounded judgment.

Consider an invoice workflow.

Structured Outputs may be appropriate when the application needs to extract:

{
  "vendor": "Acme Inc.",
  "invoice_number": "INV-1042",
  "currency": "USD",
  "line_items": []
}

A decision model becomes useful when the application already has the relevant state and needs to ask:

Should this invoice be:

- Pay
- Hold
- Return to Vendor
- Human Review

These approaches can also be combined.

An LLM can extract messy information from a document into a structured object. A decision model can then evaluate a narrow question over that normalized state. Application code can finally apply deterministic accounting or authorization rules.

The architectures are complementary rather than mutually exclusive.

OpenAI Decisions API Pricing

Pricing has not been publicly announced.

As of September 30, 2026, OpenAI's current public Decisions API announcement confirms the limited preview and its intended decision use cases, but does not publish standalone Decisions API pricing.

Last checked: September 30, 2026
Pricing status: Not publicly announced

Developers should not assume that standard GPT-6 Luna token pricing will automatically apply to Decisions API.

The Decisions API may ultimately use token pricing, per-decision pricing, another metering model, or the same Luna rates, but none of those possibilities should be treated as confirmed until OpenAI publishes the pricing terms.

How to Access OpenAI Decisions API

As of September 30, 2026, OpenAI describes Decisions API as being in limited preview.

That means developers should distinguish between the announced capability and a generally documented public API.

Current status:

Availability: Limited preview
Public endpoint: Not publicly documented
Public request schema: Not publicly documented
Public response schema: Not publicly documented
SDK interface: Not publicly documented
Standalone pricing: Not publicly announced

OpenAI has publicly identified the intended use cases—classification, routing, and selecting an agent's next action from predefined answers—but developers should wait for the official API reference before building against a guessed endpoint or SDK method.

In particular, do not assume code such as:

client.decisions.create(...)

is valid OpenAI syntax.

It is not publicly confirmed.

Until the full interface is published, the reliable source of truth is OpenAI's developer documentation and official release information rather than code samples reconstructed from third-party articles.

OpenAI Decisions API vs Jev

OpenAI Decisions API and Jev address a similar architectural problem:

Turning model judgment into predictable software decisions.

Both move away from treating unconstrained text generation as the default interface for every AI task.

But their currently documented interfaces differ substantially.

Dimension	OpenAI Decisions API	Jev
Core concept	Bounded decisions using developer-defined questions and predefined answers	System One model built specifically for typed software decisions
Decision model	Powered by Luna in the limited preview	Jev, TypeSafe's dedicated System One model
Answer space	Finite predefined answers	Choice, Score, and Noul typed questions
Structured state	Final public request schema not documented yet	Shared state supplied to one or more typed questions
Confidence / probabilities	Not publicly documented yet in OpenAI's public API reference	Typed probabilistic answers with confidence information
Availability	Limited preview	API available through TypeSafe; jevaimodel.dev also provides a working integration and playground
Pricing	Not publicly announced	TypeSafe lists $42 per billion input tokens; jevaimodel.dev uses its own credit-pack pricing
Typical use cases	Classification, routing, agent next action	Classification, routing, scoring, verification, guardrails, workflow branching

OpenAI confirms that Decisions API uses Luna to choose among predefined answers for bounded tasks. TypeSafe describes Jev as a System One model that returns typed structured decisions with probabilities and confidence rather than generated strings.

Jev's State and Typed Questions

A Jev request is organized around state and typed questions.

The state is the shared context for the decisions.

Conceptually:

State:
A customer cancelled six days ago but received another charge today.
No previous refund has been issued.

Questions are then applied to that state.

Jev exposes three core question types:

Choice

Select one option from a defined set.

Which team owns this issue?

Billing
Account
Technical Support

Score

Evaluate something on an ordered scale.

How urgent is this issue?

1 → Low
2
3
4
5 → Critical

Noul

A yes-or-no probabilistic question.

Does this request require a human?

TypeSafe's API specification exposes ChoiceQuestion, ScoreQuestion, and NoulQuestion under its /v1/systemone interface. Its workflow documentation describes Noul as a yes/no probability, Choice as a distribution across defined options, and Score as a rating over a scale.

The Jev API documentation shows how these questions can share a state and return structured answers that application code can consume.

Pricing Is Currently a Major Difference

TypeSafe publicly lists Jev's model price as:

$42 per billion input tokens
$0.042 per million input tokens

and describes output tokens as free.

OpenAI has not yet published standalone Decisions API pricing.

Separately, jevaimodel.dev has its own credit-pack pricing, which should not be confused with TypeSafe's direct model pricing. Current plans are listed on the Jev pricing page.

That distinction matters when comparing providers: model-level vendor pricing and the commercial terms of a third-party integration are different layers.

The Main Architectural Difference Today

The safest comparison at this stage is not based on undocumented latency claims or guessed endpoint syntax.

It is based on the interfaces that are actually known.

OpenAI currently describes:

Context
+
User-defined questions
+
Finite predefined answers
→
Decision

Jev publicly exposes:

State
+
Typed Questions
    ├── Choice
    ├── Score
    └── Noul
→
Typed probabilistic answers

The two systems occupy the same broader category of machine-consumable AI decisions, but Jev's public interface currently exposes more detail around typed question primitives and probabilities.

Whether OpenAI Decisions API eventually exposes equivalent primitives, calibrated probabilities, multiple questions per call, ordinal scores, abstention behavior, or other decision types is not publicly documented yet.

Developers evaluating alternatives can also compare Jev with OpenJev and SemIf to see how different decision-model implementations expose similar concepts.

How to Build a Decision Workflow in Production

The largest architectural benefit of a decision model does not come from replacing a long prompt with a shorter API call.

It comes from changing how the workflow is decomposed.

A robust pattern is:

Application State
       ↓
Small Decisions
       ↓
Probabilities / Labels
       ↓
Deterministic Policy
       ↓
Action or Human Review

TypeSafe's published workflow evaluations use this pattern explicitly: narrow model judgments are separated from programmatic rules, and the results are combined in code to produce actions.

Define the State

Start by asking:

What information does this specific decision actually need?

Suppose a support application contains:

- 200 previous messages
- complete CRM record
- payment history
- subscription state
- product telemetry
- marketing attribution

A question about whether a recent charge is disputed may only need:

Recent customer message
Latest charge
Subscription state
Refund state

Smaller state has several advantages:

• easier debugging
• less irrelevant context
• lower token usage
• clearer evaluations
• easier privacy review
• fewer accidental correlations

The goal is not to provide the model with everything the business knows.

The goal is to provide enough state to answer one defined question.

Ask a Small Explicit Question

Avoid:

Analyze this customer and decide what we should do.

That prompt hides multiple decisions:

• What does the customer want?
• Is the request urgent?
• Is the account state consistent with the complaint?
• Is a refund allowed?
• Does policy require a person?
• What action should happen next?

Instead, decompose the workflow.

For example:

What is the customer's primary intent?

then:

Does this case require human review?

then:

Which queue should this request enter?

The application can combine these results with account state and deterministic rules.

This makes failures easier to locate.

If the final workflow sends a ticket to the wrong queue, you can inspect the individual decision that caused the branch instead of debugging one large opaque prompt.

Define Explicit Answers

Decision boundaries should correspond to application behavior.

For example:

Question:
Which queue should this request enter?

Answers:
- Billing
- Technical Support
- Account
- Human Review

Each answer should have an obvious programmatic meaning.

Avoid overlapping choices such as:

Billing Problem
Payment Problem
Account Billing
Payment Support

unless your organization has precise definitions for each.

A decision system cannot compensate for an ambiguous ontology.

If two engineers cannot reliably explain the difference between two options, the model may not be able to either.

Separate Judgment from Policy

This separation is one of the most important production patterns.

The model should handle fuzzy judgments:

predict
classify
score
rank
detect

Application code should handle business policy:

threshold
permissions
limits
authorization
business rules
execution

For example:

Model:
"Does this message show strong cancellation intent?"

Application:
if cancellation_probability > threshold:
    show_retention_flow()

Another:

Model:
"Which support category best fits this request?"

Application:
if category == "Billing" and account.enterprise:
    queue = ENTERPRISE_BILLING
else:
    queue = STANDARD_BILLING

The model interprets ambiguity.

Code applies rules the organization already knows.

This reduces the amount of policy encoded in natural-language prompts and keeps critical behavior inspectable.

Add Confidence and Human Fallbacks

A decision system should have a path for uncertainty.

For example:

High confidence
    ↓
Automatic action

Medium confidence
    ↓
Additional decision or stronger model

Low confidence
    ↓
Human Review

This is especially important when the cost of a wrong decision varies by case.

Routing a newsletter into the wrong internal category has a low failure cost.

Automatically closing a security alert or rejecting a financial transaction may have a much higher one.

For systems that expose probabilities, thresholds should be validated on your own labeled workload rather than copied from a generic example.

With Jev, developers can inspect typed results and probabilities through the Jev playground before wiring them into an application.

For OpenAI Decisions API, the exact confidence and probability interface is not publicly documented yet, so production threshold logic should wait for the official response specification.

When Should You Use a Decision API?

A Decision API is a strong fit when the application already knows the shape of a valid answer.

Common characteristics include:

• finite answer space
• classification
• routing
• scoring
• agent next action
• tool selection
• workflow branching
• high-volume repetitive decisions

Consider request routing.

The application does not need:

A thoughtful 500-word explanation of which department might
be best suited for this customer's situation.

It needs:

Billing

The same pattern appears in agent systems.

An agent may need to decide:

Search
Database
Browser
Ask Human
Stop

The value comes from treating intelligence like a software primitive.

A useful rule is:

If your code ultimately converts model output into one of a small number of branches, the problem may already be decision-shaped.

Decision models are particularly interesting when the judgment itself is fuzzy but the resulting software actions are well defined.

They can sit between brittle handwritten rules and unrestricted generation.

When Should You NOT Use a Decision API?

A decision interface is not appropriate for every AI workload.

Do not force a bounded decision model onto tasks whose value comes from generating new information.

Examples include:

• long-form writing
• creative generation
• open-ended research
• unrestricted conversation
• tasks without a clearly defined decision space

If the user asks:

Explain why this distributed system keeps failing under load.

the useful answer may require diagnosis, reasoning, evidence, alternatives, and prose.

Reducing the output to:

Database
Network
Application
Unknown

could remove information the user actually needs.

Similarly, research tasks may require discovering possibilities that were not known when the request began. A fixed answer set would prematurely constrain the problem.

Decision APIs are strongest when developers can define the output boundary in advance.

If you cannot describe the valid answer space clearly, a generative or agentic interface may be more appropriate.

Frequently Asked Questions

What is OpenAI Decisions API?

OpenAI Decisions API is a limited-preview API powered by Luna for bounded software decisions. Developers define questions and predefined answers, and the model selects an outcome that an application can use for tasks such as classification, request routing, or choosing an agent's next action.

Is OpenAI Decisions API publicly available?

As of September 30, 2026, OpenAI describes Decisions API as being in limited preview. A generally available public endpoint, complete API reference, SDK interface, request schema, and response schema have not yet been publicly documented in the materials reviewed for this guide.

How much does OpenAI Decisions API cost?

Pricing has not been publicly announced. OpenAI has not published standalone Decisions API token rates, per-decision pricing, or a free tier. Developers should not assume that normal GPT-6 Luna pricing applies to the Decisions API until OpenAI publishes official pricing information.

What is the difference between Decisions API and a normal LLM API?

A normal LLM API is primarily designed to generate text or other open-ended outputs. A Decisions API starts with a bounded question and predefined answers, making the result easier to map directly into application branches. Generative models remain more suitable when the task requires explanations, synthesis, creative output, or open-ended reasoning.

What is the difference between OpenAI Decisions API and Jev?

Both target machine-consumable decisions rather than unrestricted prose. OpenAI describes Decisions API as a Luna-powered interface for selecting predefined answers. Jev is TypeSafe's System One model and exposes typed Choice, Score, and Noul questions with probabilistic outputs. OpenAI's final public schema and probability interface are not publicly documented yet.

What are Decisions API use cases?

Decisions API use cases include classification, request routing, agent next-action selection, support triage, workflow branching, model routing, moderation decisions, and similar tasks where the application already knows the valid outcome space. OpenAI explicitly identifies classification, routing, and selecting an agent's next action as target uses.

What's Next

Decision APIs represent a shift from asking models to generate everything toward using models as bounded decision components inside software systems.

The important idea is not simply shorter output. It is a cleaner interface between probabilistic judgment and deterministic code: define state, ask a small question, constrain the possible answers, then let application policy decide what happens next.

OpenAI Decisions API brings that pattern into OpenAI's model ecosystem, while Jev and other decision models provide different implementations of the same broader architecture.

For developers exploring this category, the useful next step is to study typed decision models, test real cases in the Jev playground, and evaluate decision workflows using the ambiguous, high-cost examples that actually occur in production.

Sources and Further Reading

• OpenAI DevDay 2026 — event information and keynote details.
• OpenAI API changelog — current API releases and public documentation updates.
• GPT-6 Luna model documentation — OpenAI's public Luna model reference and pricing.
• TypeSafe API reference — Jev's public API specification.
• Jev AI documentation and Jev pricing — Jev's integration and current service plans.

Information about Decisions API availability, schema, and pricing was checked on September 30, 2026. The public API reference may change as the limited preview develops.