On October 6, OpenAI released a slightly unusual API into public beta. It is called the Decisions API. Instead of writing like GPT, it returns the probability that something is true, a pick from fixed options, and a score on an ordered scale. The model underneath is GPT-6 Luna, and only Luna for now.

The headline is speed. OpenAI says it answers about 10x faster than calling the same model through the Responses API. That figure comes from the vendor, with no independent replication yet. Before the numbers, let us look at what the thing actually does.

Decisions API flow taking one input and returning predicate, choice, and score answers, with the Responses API division of labor

That is the whole picture. One input, several questions, fixed answer shapes. Your code makes the final call.

In one line: it picks without writing

Borrowing the official phrasing:

Ask predicate, choice, and score questions about shared input, and get probability answers back.

Unpacked: one customer message usually needs two jobs. Deciding what it means, and writing the sentence a person will see. The Decisions API takes only the first job.

Responses API:  situation -> long text, tool calls, reasoning (flexible but slow)
Decisions API:  situation + questions -> probability JSON (fast, fixed shape)

The seat is familiar. It matches the System One models in the Jev post and the Choice, Yes/No, and Score shapes in the Microsoft Decision post. What is new is the familiar OpenAI API doorway.

Three question shapes: predicate, choice, score

The request is simple. Send model, input, and a questions array to POST /v1/decisions. There are three question types.

Type Asks Returns Reach for it when
predicate Is this statement true Probability from 0 to 1 Code branches on an if
choice Which fixed value fits Pick plus per-option probabilities and confidence Teams or routes diverge
score Where on an ordered scale Between-level value plus per-level probabilities and confidence Severity needs measuring

Bundling several questions into one request is handy in practice. Refund intent, owning team, and urgency can travel together. Questions that depend on each other's answers need separate requests, because questions in one request are answered independently against the same input.

Images must be base64 inline. Hosted URLs and file IDs are not supported. Think screenshots attached to one judgment: picking buttons, moving through forms, and flagging risky tool calls are the listed examples.

A concrete call helps. One double-charge refund message:

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "The package arrived today. The screen is cracked and it will not turn on.",
    "questions": [
      {
        "type": "predicate",
        "name": "damaged",
        "instructions": "Does the customer report that the delivered item is damaged?"
      },
      {
        "type": "choice",
        "name": "route",
        "instructions": "Choose the best support route.",
        "choices": [
          {"value": "damage_claim", "description": "A delivered product is physically damaged."},
          {"value": "technical_support", "description": "The product is intact but has a technical problem."},
          {"value": "general_support", "description": "Neither specialist route applies."}
        ]
      }
    ]
  }'

The answers array follows question order. A predicate carries a probability, a choice carries the pick with confidence and a distribution. A refusal lands in that question's slot when the model declines. Names must be unique, and a string true and a boolean true cannot share one choice question.

The LangChain integration follows the same shape. Wrap OpenAIDecisions as a Runnable, invoke with input and questions together, and read predicates, choices, and scores separately. The documented use is middleware that steps in at specific agent lifecycle points.

Price and speed: pay input only, measure 10x yourself

Pricing is simple. With gpt-6-luna, input costs $0.10 per million tokens, with no output, cache-read, or cache-write charges. Regional processing and long-context multipliers can still apply. What you send is what you pay.

Read the speed claim carefully. About 10x is a product description, and it moves with network, input size, concurrency, and region. AI Gateway lists 0.29 seconds latency for the same Decisions model, but that is one environment's number too.

Early community tests are more interesting. In a loaded-coin test, predicate answers tracked the expected probability fairly well, while choice answers piled too much mass on the most likely side. A 70-30 coin came back looking like 98-2 through choice. It is early beta, so no verdict yet, but it is enough signal to check calibration on your own data before trusting confidence numbers.

Confidence needs the same care. The guide publishes no formula. Do not freeze a threshold at a pretty number like 0.8. The guide's own advice is to set it from labeled traffic of yours, weighing false positives against false negatives.

CodeBridge Mini Lab: same test sheet as Jev, Laya, and Decision-1

Build the test sheet before touching the API. The same routine from the briefing:

1. Collect 100: real inputs with correct labels, keep the ambiguous ones
2. Freeze: record model ID, byte-identical input, identical question wording
3. Measure together: accuracy and calibration, p50 and p95, cost per correct answer
4. Split: predicate and choice separately, sliced by task
5. Gate: auto-handle above 0.9, human review below, then check accuracy

The comparison partners are already mapped. As the fair-comparison post shows, Microsoft figures, JevBench, and Laya numbers come from different tests. Run your own 100 side by side, like the sysone-bench experiment. Where attachment pays off continues in the production-patterns post, and the pre-adoption checklist in the eval-safety post.

Conclusion: judging is becoming a layer, not a feature

One line to keep:

Split writing answers from picking answers, and put probabilities and thresholds on the picking side.

The Decisions API shows division of labor, not replacement. Fast, cheap judging takes repeatable classification, routing, and guardrails, while open-ended generation and tool use stay on Responses. It is beta, so behavior and pricing can move. Today's job is to carve out one picking step in your service and build its 100-case test sheet.

Further reading

References

Go deeper with a course

Trying a judging API and running it in production are different jobs. The hardest practical part is shaping states and questions, then splitting automatic handling from human review by confidence.

The Practical Decision AI course runs a decision model directly, from state design through Choice and Score reading into policy and Human Review, in one flow. If you want to carve out one recurring judgment, it continues directly from this post's Mini Lab.