OpenAI Decisions API: the public beta explained

OpenAI's Decisions API is in public beta: typed questions on gpt-6-luna at $0.10 per 1M input tokens. How it works, what it costs, and how it compares with Jev.

OpenAI's Decisions API went into public beta on October 6, 2026: one endpoint, `POST /v1/decisions`, that answers typed questions about text or images with a probability, a pick or a score instead of prose. It runs on gpt-6-luna, the only model it accepts, and bills $0.10 per million uncached input tokens with nothing charged for output. OpenAI first showed it as a limited preview at DevDay on September 29. Its Decisions guide now says the beta is open and that general availability is expected in the coming weeks.

It gives developers another classifier to compare with TypeSafe's Jev. WorkerKit's integration is being prepared for release, with Jev remaining the default and OpenAI becoming an explicit choice. OpenAI's public beta is available directly today; the WorkerKit controls described below are awaiting rollout. This post covers what OpenAI shipped, what it costs, where it parts ways with Jev, and how WorkerKit will support it. Decisions API vs Jev, field by field goes deeper on the two contracts.

What launched on October 6

Thibault Sottiaux shared the launch on X. OpenAI's guide describes Decisions as answering about 10x faster than the same model through the Responses API.

Three facts from the documentation matter more than the speed claim:

• The 10x is measured against OpenAI's own Responses API, the same model asked the long way. It is not a comparison with Jev or any other classifier, and it is not a latency we have measured.
• It is a separate endpoint with its own price. gpt-6-luna through Responses bills $0.10 in and $0.50 out per million tokens. Through /v1/decisions, the output and cache charges disappear.
• It is a beta. Field shapes, limits and the model behind the name can still move before general availability.

The API asks three kinds of question, and each has a direct counterpart in Jev:

How a request works

A request has three parts: the model, the shared input and a questions array. Input is a plain string or a list of user messages carrying text and image parts. Every question requires a type and instructions. An optional name is echoed on its answer so your code can match the two; WorkerKit supplies one for every question. OpenAI's own example routes a complaint to a department:

{
  "model": "gpt-6-luna",
  "input": "I was charged twice for my order.",
  "questions": [{
    "type": "choice",
    "name": "department",
    "instructions": "Which department should handle this complaint?",
    "choices": [
      {"value": "billing", "description": "Payments, invoices, and refunds."},
      {"value": "technical", "description": "Problems using the product."},
      {"value": "shipping", "description": "Delivery and tracking."},
      {"value": "other", "description": "Requests outside these categories."}
    ]
  }]
}

The guide's illustrative response picks billing, with a probability of 0.95, a confidence of 0.93 and a probability for each of the other three values. Those numbers illustrate the response shape; they are not guaranteed results. Independent questions share one array and one input; a question that depends on an earlier answer goes in a second request. The guide also asks for an other option whenever the categories might not cover every input, the same advice TypeSafe gives and for the same reason: a choice cannot answer outside its own list.

Two behaviours need explicit handling. Images: input can mix text with up to 128 inline images, as base64 data URLs only, with no hosted image URLs or file ids. Refusals: the API reference defines an answer of type: "refusal", so one question in a request can come back with no value at all. Code that reads choice off every answer without checking its type will break on the first refusal.

The guide is also clear about what the endpoint is not for. Extracting fields or writing an explanation belongs to Structured Outputs, and asking for a tool call belongs to function calling. Decisions answers its three question types and nothing else, which is the whole idea of a System One model: a judgment your code can branch on, not text it has to parse.

What it costs

The endpoint charges for uncached input tokens; cache reads, cache writes and output tokens are free. Two premiums still apply. Per the gpt-6-luna model page, a request with more than 272,000 input tokens bills its input at twice the rate, and regional processing adds 10% where it is available.

Here is what the base rate means at volume, next to Jev's published $0.042. Each item is assumed to consume 500 billable input tokens, including its questions, with no cache savings, images or pricing premiums:

On list price, Jev's input costs 42% of OpenAI's base input rate (TypeSafe models page). That is still not the whole story: the two count tokens with different tokenizers, structured records have to be flattened into text before OpenAI reads them, and an image costs input tokens on a request Jev could not take at all. Classification can reduce the work sent to a more expensive language model; the saving depends on input size, the fraction selected and the downstream model. That is the argument screening cheap before spending expensive makes at length.

Where it differs from Jev

The shared shape hides real differences, and these are the ones that change a design:

• Images. OpenAI takes them. Jev is "Text only", in TypeSafe's words.
• Refusals. OpenAI can refuse a single question. Jev's published successful-response schema has no refusal type; errors from either provider still need handling.
• Confidence. TypeSafe publishes the formula behind each confidence value. OpenAI returns confidence on choice and score answers without documenting how it is computed, and recommends setting thresholds from labeled application examples. Thresholds need validation separately for each provider.
• Version pinning. Jev's aliases point at a versioned model, jev-1.13.0 today. OpenAI's example response names the model as gpt-6-luna, with no version in it.
• Data handling. OpenAI's data controls state that API data is not used for training by default and abuse-monitoring logs may be retained for up to 30 days. Eligible customers can request Zero Data Retention, subject to the documented cache and image exceptions: GPU-local encrypted cache state can persist for up to 24 hours, and flagged images can be retained for review. Regional processing is supported in the US and Europe where configured. These vendor options are not automatic guarantees for a WorkerKit deployment. TypeSafe's legal page links a data processing agreement and a privacy policy it describes as committing not to train on user data, with ZDR for enterprise customers through sales.
• Published limits. TypeSafe publishes Jev's: 64k tokens per request, 32k for the state plus the longest question, and rate limits it says can change without notice. OpenAI's guide publishes no limit on questions, choices or levels per request.

The full comparison lines the two contracts up field by field, with what to test before trusting either.

How WorkerKit will support it

A decision worker is the worker class with no agent loop. It reads items through its app grants, asks each one the kit's typed questions, routes on the answers in code, and acts or escalates. The integration being prepared lets a kit choose a default decision model, a worker override that choice, and an individual run override it once. With no explicit choice, Jev stays the default. This choice is separate from any language model used by a kit that classifies first and then hands selected items to an agent.

The dashboard, CLI and MCP will expose the same selection. Once enabled, the available decision models will appear in the model list and dashboard pickers. The initial OpenAI profile supports text classification of individual items; images and corpus ranking remain unsupported. A corpus kit must continue to use Jev.

The integration preserves these rules:

• Nothing moves on its own. Existing workers keep Jev until someone changes them.
• One classifier per run. The classifier and its rate are fixed when a run starts. A failure never silently switches the run to the other provider, because a judgment from a different model is a different judgment.
• The receipt says which. New runs using decision profiles record the classifier on their run receipt and keep a refusal apart from a low-confidence answer. Historical receipts are unchanged.
• List price, from the wallet. Classification bills at the provider's list rate on the input tokens it measured, paid from the runtime wallet, with no markup and no per-run minimum. A worker whose language stage runs on your own key still pays for classification from the wallet.
• The classifier is a recipient. It sees what the worker's app firewall lets through, after field masks and redaction, and nothing more. Choosing OpenAI changes who receives that evidence, which is worth checking against your own data policy before you switch a worker that reads customer mail.

Switching a worker without fooling yourself

A floor tuned on Jev should not be assumed to work on OpenAI. Jev's confidence for a choice measures how far the top probability sits above an even split; OpenAI does not say what its number measures. A confidence threshold that held at 0.8 on one can let a different set of mistakes through on the other. Treat a switch like a new deployment:

1. Prepare a separate test worker with read-only app grants and reporting routes only: remove call actions and agent handoffs. Ordinary WorkerKit runs execute their configured actions; there is no Preview/Live switch.
2. Compare both classifiers on the same fixed, labeled inputs. A fresh read of a changing mailbox is not necessarily the same test set.
3. Choose each provider's threshold from the errors and acceptable error costs, then apply the tested profile and rules to the worker that will take actions.

The workers most worth testing are the ones where TypeSafe names a weakness. Its notes on Jev 1.13 list date comparisons, counting and long state full of irrelevant detail, and the models page says English is where accuracy is best. A Multilingual Inbox Router sorting mail by language, or a Critical Email Finder reading long threads, is where a second classifier earns its measurement. A short, English, well-separated choice such as the Internal Request Router picking IT, HR or Finance is where Jev's lower price is hardest to beat.

FAQ

When did OpenAI's Decisions API launch?

OpenAI announced it as a limited preview at DevDay on September 29, 2026, and opened a public beta on October 6, 2026. Its guide says general availability is expected in the coming weeks.

Which model does the Decisions API use?

Only gpt-6-luna, through the dedicated POST /v1/decisions endpoint. The same model called through the Responses API has a different price and returns generated text rather than typed answers.

How much does OpenAI's Decisions API cost?

$0.10 per million input tokens, with no charge for output tokens, cache reads or cache writes. Requests over 272,000 input tokens bill input at twice that rate, and regional processing adds 10% where available.

Is the Decisions API faster than Jev?

OpenAI's claim is that Decisions answers about 10x faster than the same model through the Responses API, not faster than Jev. Neither vendor publishes a shared benchmark, so the only fair comparison is one you run on the same items.

How do you use OpenAI Decisions in WorkerKit?

WorkerKit support is awaiting rollout. Once enabled, choose a default decision model on a kit, override it on a worker, or select one for a single run. Jev remains the default when no choice is saved. The kit's supported questions, routing rules and app access carry over; the classifier, price and receipt attribution change. Browse decision model kits to see the workflows it will support.

What does a WorkerKit decision worker send to OpenAI?

The initial integration sends the kit's questions and text evidence from fields allowed by the worker's app firewall, after field masks and redaction. It does not send images, even though the endpoint accepts them.