OpenAI Decisions API: Skip the Parser, Get Typed Answers

OpenAI unveiled more than 20 products at DevDay 2026 last week. Dots got the headlines. GPT-6.1 Sol got the pricing discussions. The Decisions API got a single tweet and a “limited preview” tag — and it’s arguably the most developer-useful thing on the list.

Not because it’s flashy. Because it kills a piece of boilerplate every agent developer is currently writing and maintaining themselves.

The Loop Every Agent Developer Hates #

When you need a generative model to make a classification or routing decision, the standard flow looks like this:

1. Prompt the model
2. Get text back
3. Parse the text for the value you wanted
4. Validate it against your schema
5. Retry if it came back malformed (it will)
6. Take the action

Steps 2 through 5 are entirely yours to maintain. Wrong casing, unexpected phrasing, hallucinated options — you handle it. The OpenAI Decisions API removes that entire middle layer. You define the allowed answers upfront. You get exactly one of them back, plus a confidence score. No parsing. No retries on malformed output.

What the OpenAI Decisions API Actually Is #

The Decisions API is not another completions endpoint. It’s a decision endpoint: you pass context (text or image), a question, and a closed list of possible answers. The API returns whichever answer fits best, along with a confidence score. It cannot and will not generate text outside your predefined set.

It runs on a specialized version of GPT-6 Luna optimized for classification speed. OpenAI claims roughly 150ms latency. Independent benchmarks put P50 at 19.4ms and P99 at 38.6ms — though these numbers come from a single third-party test, not an official SLA.

Here’s the basic request shape (illustrative — the official schema is not yet public):

{
  "context": {
    "ticket": "Customer charged twice",
    "account_tier": "business",
    "recent_events": ["payment_succeeded", "payment_succeeded"]
  },
  "question": {
    "name": "route",
    "prompt": "Which approved workflow owns this case?",
    "answers": ["refund_review", "technical_support", "account_security"]
  }
}

And the application-side handler:

const decision = await decisionsApi.evaluate(request);

if (!allowedRoutes.includes(decision.choice)) {
  return sendToManualReview('Unknown route');
}

if (decision.confidence < MIN_CONFIDENCE) {
  return sendToManualReview('Uncertain decision');
}

return dispatch(decision.choice, { auditId, source: 'decisions-api' });

Your policy engine retains final authority. The model picks the path; your code decides whether to trust that pick.

Where It Sits in Your Agent Stack #

The Decisions API is not a replacement for your generative model. It’s a separate layer. A clean 5-layer agent stack puts it at position three:

1. Orchestrator
2. Generative model (planning, reasoning)
3. Decision model — bounded judgments (the Decisions API)
4. Policy and permissions
5. Action and audit

Use the decision layer when your agent needs to pick a path, not when it needs to think. Every time your agent asks “what queue does this go to?” or “which tool do I call next?” — that’s a bounded question with a fixed answer set. That’s what the OpenAI Decisions API is for.

OpenAI Just Validated a Category TypeSafe Started #

TypeSafe AI launched Jev on September 15 — exactly 14 days before OpenAI’s DevDay response. Jev is a non-generative decision model: it cannot produce free-form text at all, which gives it compiler-level schema guarantees that the Decisions API (still backed by a constrained generative model) cannot make.

The tradeoffs are real. Jev benchmarks at 3-6ms P50 latency and costs roughly $0.04–$0.18 per million invocations. The Decisions API costs an estimated $1 per million and runs in the 19–150ms range depending on the source. Jev wins on speed and cost. The Decisions API wins on zero-shot accuracy (94.2% vs 88.6%), multimodal input support, and a 1-million-token context window vs Jev’s 32K limit.

They can coexist. Use Jev where non-generative guarantees and volume cost matter. Use the Decisions API where you need image context or higher accuracy on novel categories. OpenAI showing up 14 days after Jev’s launch is confirmation that the decision-model category is now a real product surface, not a research curiosity.

Four Things Still Missing from the Preview #

The Decisions API is in limited preview and four essential details remain unpublished:

• Pricing per call
• Maximum number of candidate answers per request
• Fine-tuning support on custom data
• SLA and rate limits

As of September 30, there is no entry for the Decisions API in OpenAI’s official API reference. Treat the preview as an experiment, not a production dependency. One more thing: confidence score is not accuracy. Measure calibration on your own data before trusting any automation threshold.

What to Do Right Now #

If you’re on the preview: run one production routing hop through it, log latency and cost against your current approach, and track how often the confidence falls below your automation threshold. Don’t expand until you have those baselines.

If you’re not on the preview yet: build the contract now. Define the bounded questions your agent makes, document the allowed answer sets, and write a thin adapter interface. When the API hits general availability, migration will be an afternoon, not a sprint.

The parse-validate-retry loop has been agent developer tax since the first agentic frameworks shipped. OpenAI just made it optional — once the preview widens.