OpenAI Decisions API: Ja-oder-Nein-Fragen ohne teure LLM-Aufrufe beantworten
Viele Agentenentscheidungen wie Ticket-Kategorisierung oder Eskalation brauchen keine ausführliche Begründung, sondern nur eine Antwort aus einer kurzen Liste. OpenAIs Decisions API soll solche Fälle ohne vollständigen reasoning Aufruf abdecken.
Zählen Sie die Entscheidungen in jedem Agenten, den Sie bereits ausgeliefert haben. Geht es bei diesem Ticket um Abrechnung oder um Technik? Soll der Agent es erneut versuchen, fortfahren oder um Klärung bitten? Ist dieses Bild beschädigt? Ist der Anrufer wütend genug für eine Eskalation?
Keine dieser Fragen erfordert einen Absatz voller Reasoning. Sie brauchen jeweils eine einzige Antwort aus einer kurzen Liste. Trotzdem schicken die meisten von uns sie durch denselben Chat-Completion-Endpunkt, den wir auch für das Schreiben von E-Mails nutzen, zahlen für die Output-Tokens, parsen das JSON und fügen einen Retry für den Fall hinzu, dass das Modell kreativ wird.
Am 22. Oktober hat OpenAI die Decisions API allgemein verfügbar gemacht, und sie ist genau dafür gebaut (OpenAI). Hier ist, was sie leistet, welche drei Antworttypen es gibt und welche Muster sich lohnen, selbst wenn Sie sie nie direkt aufrufen.
Decisions läuft auf GPT-6 Luna, erzeugt aber anstelle von Text Antworten mit begrenzten Antwortmöglichkeiten. OpenAI zufolge ist sie bis zu 10x schneller, als Luna dieselbe Frage über die Responses API zu stellen. Seit der Beta sind Prompt-Caching, native JSON-Eingaben, Bilder innerhalb der Instruktionen, bis zu 400 Fragen pro Anfrage sowie US- und EU-Inference-Residency hinzugekommen.
Der interessante Teil ist die Preisgestaltung: 0,10 Dollar pro Million Input-Tokens, 0,01 Dollar im Cache, und überhaupt keine Kosten für Output-Tokens. Für einen Router, der ein Ticket mit 600 Tokens liest, sind das etwa sechs Tausendstel Cent pro Entscheidung vor Caching.
Man definiert eine Frage mit ihren erlaubten Antworten, übergibt Kontext als Text, Bild oder JSON und erhält eines von drei Ergebnisformaten zurück:
Das Format ist wichtiger, als es aussieht. Eine Auswahl mit Wahrscheinlichkeiten lässt sich mit Schwellenwerten filtern. Ein Score, der ein gewichteter Durchschnitt ist, lässt sich sortieren. Eine Freitextantwort eines Chat-Modells ist beides erst, nachdem man sie geparst hat.
Das Nützlichste, was man zurückbekommt, ist nicht die Antwort selbst. Es ist das Maß, wie sicher sich das Modell ist. Box teilte mit, dass die Decisions API in seiner Evaluierung Routen bei Versicherungsbescheinigungen etwa 5x schneller ausgewählt hat bei gleicher Genauigkeit wie die Responses API, und Fälle mit geringerer Konfidenz an menschliche Prüfer weitergeleitet hat.
Das ist das Muster: erst die günstige Entscheidung, der teure Pfad nur bei Bedarf.
def route ( ticket: dict ) -> str: d = decide ( # dünner Wrapper um den Decisions-Endpunkt question = { " type ": " choice ", " name ": " queue ", " instructions ": " Welches Team soll dieses Support-Ticket bearbeiten? ", " choices ": [{ " value ": v } for v in [ " billing ", " technical ", " account ", " sales " ]], }, context = ticket, # natives JSON, kein Prompt-Templating ) if d. confidence >= 0.85: return d. choice # schneller Pfad, der meiste Traffic if d. confidence >= 0.55: return escalate_to_large_model ( ticket, hint = d. choice ) # langsamer Pfad return " human_review " # das Modell weiß, dass es es nicht weiß Die beiden Schwellenwerte sollte man anhand einer gelabelten Stichprobe justieren, nicht nach Gefühl. Der erste steuert die Kosten, der zweite, wie viel bei Menschen landet.
Bis zu 400 Fragen pro Anfrage bedeuten, dass man aufhören kann, verwandte Prüfungen seriell abzufragen. Moderiert man ein Inserat, fragt man einfach "enthält Kontaktdaten?", "sieht der Preis nach einem Tippfehler aus?", "passt das Foto zur Kategorie?" und "ist die Sprache Englisch?" in einer einzigen Anfrage gegen einen einzigen gecachten Kontext. Ein Roundtrip statt vier, und der gemeinsame Kontext wird nur einmal abgerechnet.
checks = [ { " type ": " predicate ", " name ": " has_contact_info ", " instructions ": " Enthält der Inseratstext eine Telefonnummer oder E-Mail-Adresse? " }, { " type ": " predicate ", " name ": " price_suspicious ", " instructions ": " Ist der Preis für diese Artikelkategorie unplausibel? " }, { " type ": " score ", " name ": " photo_quality ", " instructions ": " Bewerte die Fotoqualität.
", " levels ": [ " unusable ", " poor ", " fine ", " good ", " excellent " ]}, ] result = decide_many ( checks, context = listing ) Muster 3: Entscheidungen innerhalb eines Live-Sprachanrufs Das ist der Teil, den ich am spannendsten finde. Decisions lässt sich jetzt in GPT-Live-Sessions als Auslöser für Transkript-Ereignisse einbinden. Während der Anrufer noch spricht, kann die Anwendung entscheiden, ob sie eine Rückfrage stellen, weiterleiten oder eskalieren soll, ohne das Gespräch für einen vollständigen Modell-Durchlauf zu pausieren.
OpenAIs Demo nutzt dies, um den Gesichtsausdruck eines Avatars anhand des Live-Transkripts auszuwählen:
{ "type": "decisions", "event_type": "session.input_transcript.delta", "decisions": { "questions": [{ "type": "choice", "name": "reaction", "instructions": "Wähle eine passende Reaktion für den Avatar basierend auf der letzten Nachricht des Nutzers.", "choices": [{ "value": "neutral" }, { "value": "happy" }, { "value": "sad" }, { "value": "concerned" }] }] } } Ersetzt man "reaction" durch escalate, needs_human oder intent, hat man den Nebenkanal, den jeder Voice-Agent braucht: eine kontinuierliche, günstige Auswertung des Gesprächs, die es nie unterbricht.
Der Großteil der Agentenkosten steckt nicht in den cleveren Schritten. Er steckt in den Dutzenden kleinen, unspektakulären Klassifikationen drumherum. Diese in eine dedizierte, strukturierte, schwellenwertbasierte Ebene auszulagern, ist gute Architektur, ganz gleich, welchen Anbieter man nutzt: Sie macht Agenten schneller, günstiger und leichter zu debuggen, weil jede Routing-Entscheidung nun einen Namen, eine Konfidenz und eine Logzeile hat.
Wir entwerfen solche Agentenarchitekturen bei Axionry, einem Studio für die Entwicklung von KI-Produkten. Wenn Sie einen Agenten planen und wissen möchten, was der Betrieb kosten wird, probieren Sie unseren AI-Produkt-Kostenschätzer aus oder sehen Sie sich an, wie wir arbeiten, auf unserer Seite zur AI-Produktentwicklung.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Count the decisions inside any agent you have shipped. Is this ticket billing or technical? Should the agent retry, continue or ask for clarification? Is this image damaged? Is the caller angry enough to escalate?
None of these need a paragraph of reasoning. They need one answer from a short list. Yet most of us send them through the same chat completion endpoint we use for writing emails, pay for the output tokens, parse the JSON, and add a retry for when the model gets creative.
On October 22, OpenAI made the Decisions API generally available, and it is built for exactly this ( OpenAI ). Here is what it does, the three answer types, and the patterns worth stealing even if you never call it.
Decisions runs on GPT-6 Luna, but instead of generating text it answers questions with bounded answers. OpenAI says it is up to 10x faster than asking Luna the same thing through the Responses API. Since the beta it has gained prompt caching, native JSON inputs, images inside instructions, up to 400 questions per request, and US and EU inference residency.
The pricing is the interesting part: $0.10 per million input tokens, $0.01 cached, and no output token charges at all. For a router that reads a 600 token ticket, that is about six thousandths of a cent per decision before caching.
You define a question and its allowed answers, pass context as text, images or JSON, and get back one of three result shapes:
The shape matters more than it looks. A choice with probabilities is something you can threshold. A score that is a weighted average is something you can sort. A free-text answer from a chat model is neither until you parse it.
The most useful thing you get back is not the answer. It is how sure the model is. Box shared that in its evaluation the Decisions API picked routes about 5x faster on certificate of insurance documents with the same accuracy as Responses, and sent lower-confidence cases to human reviewers.
That is the pattern: cheap decision first, expensive path only when needed.
def route ( ticket: dict ) -> str: d = decide ( # thin wrapper around the Decisions endpoint question = { " type ": " choice ", " name ": " queue ", " instructions ": " Which team should handle this support ticket? ", " choices ": [{ " value ": v } for v in [ " billing ", " technical ", " account ", " sales " ]], }, context = ticket, # native JSON, no prompt templating ) if d. confidence >= 0.85: return d. choice # fast path, most traffic if d. confidence >= 0.55: return escalate_to_large_model ( ticket, hint = d. choice ) # slow path return " human_review " # the model knows it does not know Enter fullscreen mode Exit fullscreen mode Tune the two thresholds on a labelled sample, not by feel. The first one controls cost, the second controls how much lands on people.
Up to 400 questions per request means you can stop making serial calls for related checks. Moderating a listing? Ask "contains contact details?", "price looks like a typo?", "photo matches category?" and "language is English?" in one request against one cached context. One round trip instead of four, and the shared context is billed once.
checks = [ { " type ": " predicate ", " name ": " has_contact_info ", " instructions ": " Does the listing text include a phone number or email? " }, { " type ": " predicate ", " name ": " price_suspicious ", " instructions ": " Is the price implausible for this item category? " }, { " type ": " score ", " name ": " photo_quality ", " instructions ": " Rate photo quality.
", " levels ": [ " unusable ", " poor ", " fine ", " good ", " excellent " ]}, ] result = decide_many ( checks, context = listing ) Enter fullscreen mode Exit fullscreen mode Pattern 3: decisions inside a live voice call This is the part I find most exciting. Decisions now plugs into GPT-Live sessions as a trigger on transcript events. While the caller is still speaking, the app can decide whether to ask a clarifying question, route, or escalate, without pausing the conversation to run a full model turn.
OpenAI's demo uses it to pick an avatar's facial expression from the live transcript:
{ "type": "decisions", "event_type": "session.input_transcript.delta", "decisions": { "questions": [{ "type": "choice", "name": "reaction", "instructions": "Choose an appropriate reaction for the avatar based on the user's latest message.", "choices": [{ "value": "neutral" }, { "value": "happy" }, { "value": "sad" }, { "value": "concerned" }] }] } } Enter fullscreen mode Exit fullscreen mode Swap "reaction" for escalate, needs_human or intent, and you have the side channel every voice agent needs: a continuous, cheap read on the conversation that never interrupts it.
Most agent cost is not in the clever steps. It is in the dozens of small, boring classifications around them. Pulling those out into a dedicated, structured, thresholded layer is good architecture whichever vendor you use: it makes agents faster, cheaper and easier to debug, because every routing choice now has a name, a confidence and a log line.
We design agent architectures like this at Axionry, an AI product development studio. If you are planning an agent and want to know what it will cost to run, try our AI product cost estimator, or see how we build on our AI product development page.