Skip to content
Bud's Wiki

OpenAI Decisions API — real-time typed classification/routing decisions from GPT-6 Luna

TL;DR

Section titled “TL;DR”

OpenAI announced the Decisions API at DevDay, powered by a post-trained GPT-6 Luna. The API takes text or images as context plus a user-defined question and set of possible answers, and returns a typed structured selection — advertised uses are content classification, request routing, and picking an agent’s next action. Ships as a limited preview to selected API customers with a “broad release planned in the coming days.” No pricing, latency numbers, or technical details in the launch post.

Key claims

Section titled “Key claims”
  • The Decisions API is a distinct product surface designed around “real-time decision-making”: the caller defines a question and possible answers, the API returns one selected answer the caller’s app can consume [Post].
  • The underlying model is post-trained GPT-6 Luna (OpenAI’s smaller/faster Luna variant) — implying a specialization pass on top of the general-purpose Luna base rather than a from-scratch architecture [Post].
  • Multimodal inputs: both text and images are supported as context on the same endpoint [Post].
  • Advertised applications: (a) classification, (b) routing (e.g. a support-request → team-selection example is called out explicitly), (c) selecting an agent’s next action [Post].
  • Preview access is limited to selected API customers at launch, with broader release planned in the coming days [Post].

Method

Section titled “Method”

The launch is a product announcement, not a technical report — no architecture, training-objective, or benchmark details are disclosed. Inferred from the surface:

  • Caller-supplied question + answer set implies a schema-constrained decoding path (the API cannot return a value outside the caller’s answer set), and the “post-trained” framing suggests a supervised or RL specialization on top of Luna targeting exactly this input/output shape.
  • The support-request-routing worked example (supply a request and the teams it could go to → API returns a selection) matches the “unstructured input → typed selection out” contract that other output-space specialist products have converged on.
  • No mention of confidence values, calibration, latency floors, or per-call pricing at filing time — only that “output tokens” are effectively the schema selection, not free-form prose.

The tweet itself is the artifact; there is no linked technical write-up.

Results

Section titled “Results”

None disclosed. No benchmark numbers, no latency measurements, no cost figures.

Why it’s interesting

Section titled “Why it’s interesting”

This is the biggest lab’s move into the same design space as Introducing System One Models & Jev (Jev / TypeSafe AI’s “System One Model”) and its open-weights counterparts Laya — Non-Autoregressive System One Decision Model (open-source RLCD) (Laya) and Laya-MLX — Native Apple Silicon port of Laya typed decision models (Laya-MLX). Where Jev/Laya redesigned the model class end-to-end around calibrated typed decisions with a non-autoregressive parallel decoder trained under RLCD, OpenAI’s take is a post-training specialization of an existing multimodal base (GPT-6 Luna) — a different bet on the same output-space-specialist pole of the Tool-Use Agents design space. Ishaan flags the specific advantage worth watching: multimodal input, which Jev-class models currently lack. That widens the addressable surface from text-only classification/routing to any image-conditioned decision (visual content moderation, image-based dispatch, VLM-as-router in an agent loop) without swapping model classes mid-pipeline.

On LLM Inference Efficiency, this is an independent datapoint that structured-decision workloads are worth their own product SKU at frontier-lab scale, aligning with the SimpleTool: Parallel Decoding for Real-Time LLM Function Calling SimpleTool finding that parallel-decoded typed outputs beat autoregressive tool-call generation on latency by 3–6×. Whether Decisions API’s cost/latency is competitive with Jev’s claimed 20–200× speedup / 40–400× cost reduction over LLMs is unknowable from the launch post — no numbers were shared.

For Luma specifically, Ishaan flags Opal as a natural fit: any decision point in an agent pipeline (route request, classify user intent, pick next tool, gate output) that currently burns a full LLM turn could plausibly drop to a Decisions API call at lower cost and latency, if the preview access + reported behavior hold up.

See also

Section titled “See also”