Einstieg in die OpenAI Decisions API: Drei Zugangswege

Die OpenAI Decisions API ist eine Schnittstelle zur Klassifikation und Bewertung. Sie übergeben Ausgangsmaterial und mehrere Fragen. Die API liefert Auswahlwerte, Wahrscheinlichkeiten oder Bewertungen, die Ihre Anwendung weiterverarbeiten kann.

Viele Produkte benötigen solche Entscheidungen: Welches Team soll ein Supportticket erhalten? Muss eine Nachricht weiterverfolgt werden? Welche Schwere hat ein gemeldetes Problem? Damit daraus ein verlässlicher Ablauf entsteht, müssen Eingaben, mögliche Antworten und Antwortformate klar definiert sein.

OpenAI veröffentlichte die Decisions API am 6. Oktober 2026 als Beta mit gpt-6-luna. Das Modell ist auch über OpenRouter und decisions-api.dev verfügbar. OpenAI Änderungsprotokoll, OpenRouter Modellseite, Modellseite auf decisions-api.dev.

Diese Anleitung erklärt die drei Zugangswege anhand desselben Beispiels: der Zuordnung eines Supporttickets. Die Anfrageformate unterscheiden sich. Wer diese Unterschiede kennt, kann die ersten Aufrufe leichter in seine Anwendung einbauen.

1. Frage und mögliche Antworten festlegen

Angenommen, Ihr Supportsystem erhält dieses Ticket:

Bestellung R-208 wurde zweimal belastet. Bitte erstatten Sie den zusätzlich abgebuchten Betrag.

Die Anwendung soll es dem Abrechnungsteam, dem Kontoteam oder einer allgemeinen Warteschlange zuordnen. Dafür definieren Sie zunächst drei feste Werte: billing, account und other.

Das ähnelt einer Sortierkraft mit einem gedruckten Verteilungsplan. Die Adresse auf einem Paket liefert die Informationen; die Felder auf dem Plan zeigen die möglichen Ziele. Die Sortierkraft wählt ein Feld, und der Zustellprozess verarbeitet diese Auswahl weiter.

Bei der API entspricht das Ticket der Eingabe, die Zuordnungsanweisung der Frage und die Liste der Ziele den Auswahlmöglichkeiten. Klare Beschreibungen erleichtern die anschließende Verarbeitung im Programm.

Es gibt drei grundlegende Fragetypen. Die native API und die beiden Vermittlungsdienste verwenden folgende Bezeichnungen. OpenAI Anfrageschema, OpenRouter Decisions-Schema.

Was möchten Sie wissen?	Nativer OpenAI-Typ	Typ bei OpenRouter und dieser Website	Wesentliches Ergebnis
Fordert das Ticket eine Erstattung?	predicate	noul	Wahrscheinlichkeit, dass die Bedingung zutrifft
Welches Team soll es bearbeiten?	choice	choice	Ausgewählter Wert und Wahrscheinlichkeitsverteilung
Wie hoch ist die Priorität?	score	score	Bewertung auf geordneten Stufen und Wahrscheinlichkeitsverteilung

Teams sind Kategorien ohne Rangfolge. Dafür eignet sich choice. Niedrige, mittlere und hohe Priorität bilden dagegen eine geordnete Skala. Dafür verwenden Sie score.

Definieren Sie auch eine Auffangkategorie. other bedeutet hier, dass keines der beschriebenen Teams passt. Die Anwendung kann solche Tickets einer allgemeinen Warteschlange zuweisen, anstatt sie in eine unpassende Kategorie einzuordnen.

2. Die drei Zugangswege vergleichen

Alle drei Varianten ermöglichen den Zugriff auf das Entscheidungsmodell von OpenAI. Sie verbinden sich aber mit unterschiedlichen Diensten, verwenden unterschiedliche Schlüssel und lesen unterschiedliche JSON-Strukturen.

Am 7. Oktober 2026 gelten die folgenden wesentlichen Unterschiede. Nativer OpenAI-Endpunkt, OpenRouter Endpunkt, API-Dokumentation dieser Website.

Merkmal	OpenAI	OpenRouter	decisions-api.dev
POST-Adresse	https://api.openai.com/v1/decisions	https://openrouter.ai/api/alpha/decisions	https://decisions-api.dev/v1/systemone
Modellbezeichnung	gpt-6-luna	openai/gpt-6-luna-decisions	openai/gpt-6-luna-decisions
Aussteller des Schlüssels	OpenAI	OpenRouter	decisions-api.dev
Feld für das Ausgangsmaterial	input	state	state
Fragen	Array; jede Frage hat einen name	Objekt mit Fragennamen als Schlüsseln	Objekt mit Fragennamen als Schlüsseln
Antworten	Array unter answers	Objekt unter answers	Objekt unter data.result.answers

Die Zeichnung zeigt Anwendung, API-Einstiegspunkt und Modellanbieter. Interne Weiterleitungsdienste sind darin ausgelassen. Für dieses Modell leitet decisions-api.dev Anfragen über OpenRouter weiter und wendet eigene Guthaben- und Anfragelimits an. Details zur Integration.

Wir beginnen mit einer kleinen Textanfrage. Jede der folgenden Umgebungsvariablen enthält einen Schlüssel des jeweiligen Dienstes. Ersetzen Sie die Beispielwerte und führen Sie die Befehle im Terminal oder auf Ihrem Server aus. Die Schlüssel gehören auf den Server.

3. Variante eins: OpenAI direkt aufrufen

Wenn Ihr Projekt bereits OpenAI nutzt, können Sie den nativen Endpunkt direkt aufrufen.

Speichern Sie diese Anfrage als openai-request.json:

{
  "model": "gpt-6-luna",
  "input": "Bestellung R-208 wurde zweimal belastet. Bitte erstatten Sie den zusätzlich abgebuchten Betrag.",
  "questions": [
    {
      "name": "route",
      "type": "choice",
      "instructions": "Wählen Sie das zuständige Team für dieses Ticket. Wählen Sie other, wenn kein Team passt.",
      "choices": [
        {
          "value": "billing",
          "description": "Abbuchungen, Rechnungen und Erstattungen"
        },
        { "value": "account", "description": "Anmeldung und Kontozugriff" },
        {
          "value": "other",
          "description": "Probleme außerhalb der Zuständigkeit dieser Teams"
        }
      ]
    }
  ]
}

Hier enthält input das Material, das alle Fragen gemeinsam auswerten. questions ist ein Array; route benennt diese Frage. Jede Auswahlmöglichkeit enthält einen Wert für das Programm und eine Beschreibung seiner Bedeutung.

Senden Sie die Anfrage anschließend mit curl:

export OPENAI_API_KEY="YOUR_OPENAI_API_KEY"

curl --fail-with-body https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @openai-request.json

Der Authorization-Header verwendet Ihren OpenAI-Schlüssel. --data-binary liest die zuvor gespeicherte JSON-Datei. Das Antwortformat ist in der Referenz zu Create a decision beschrieben.

Der folgende Antwortauszug veranschaulicht das Format. Die Zahlen sind Beispiele und keine Messwerte aus einem Aufruf mit diesem Ticket:

{
  "answers": [
    {
      "name": "route",
      "type": "choice",
      "choice": "billing",
      "probabilities": [
        { "value": "billing", "probability": 0.92 },
        { "value": "account", "probability": 0.03 },
        { "value": "other", "probability": 0.05 }
      ],
      "confidence": 0.84
    }
  ]
}

choice enthält den ausgewählten Wert. probabilities beschreibt die Verteilung über die Auswahlmöglichkeiten. confidence ist ein separates Feld und ersetzt nicht die Wahrscheinlichkeit der gewählten Option.

Die native API kann eine einzelne Frage mit type: "refusal" ablehnen. Prüfen Sie den Antworttyp, bevor Sie Auswahlwert oder Bewertung lesen. Andere Fragen derselben Anfrage können trotzdem beantwortet werden. Offizielles Ablehnungsschema.

4. Variante zwei: Über OpenRouter aufrufen

Wenn Ihr Projekt bereits OpenRouter nutzt, verwenden Sie dessen Schlüssel und den speziellen Decisions-Endpunkt /api/alpha/decisions. OpenRouter Anfragedokumentation.

Speichern Sie diese Anfrage als gateway-request.json:

{
  "model": "openai/gpt-6-luna-decisions",
  "state": "Bestellung R-208 wurde zweimal belastet. Bitte erstatten Sie den zusätzlich abgebuchten Betrag.",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Wählen Sie das zuständige Team für dieses Ticket. Wählen Sie other, wenn kein Team passt.",
      "criteria": {
        "billing": "Abbuchungen, Rechnungen und Erstattungen",
        "account": "Anmeldung und Kontozugriff",
        "other": "Probleme außerhalb der Zuständigkeit dieser Teams"
      }
    }
  }
}

Die Modellbezeichnung enthält nun das Präfix openai/ und das Suffix -decisions. Das Ausgangsmaterial steht unter state, der Fragenname wird zum Objektschlüssel und die Optionen werden im Objekt criteria definiert.

Senden Sie die Anfrage an OpenRouter:

export OPENROUTER_API_KEY="YOUR_OPENROUTER_API_KEY"

curl --fail-with-body https://openrouter.ai/api/alpha/decisions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @gateway-request.json

Dieser Aufruf benötigt einen von OpenRouter ausgestellten Schlüssel. Die Antworten sind nach Namen organisiert. Diese Antwort finden Sie daher unter answers.route.

Dasselbe beispielhafte Klassifikationsergebnis hat hier folgende Struktur:

{
  "answers": {
    "route": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.92, "account": 0.03, "other": 0.05 },
      "confidence": 0.84
    }
  }
}

Sowohl die Antwortsammlung als auch die Wahrscheinlichkeitsverteilung sind hier Objekte. Wenn Sie nativen OpenAI-Code umstellen, passen Sie den Aufbau der Anfrage und das Auslesen der Antwort gemeinsam an.

Die Modellseite nennt Text- und Bildeingaben, ein Kontextfenster von 1.050.000 Tokens und bis zu 200 Fragen beim Modellanbieter. Diese Anleitung verwendet eine Frage und einen kurzen Text. Prüfen Sie aktuelle Dokumentation und Verfügbarkeit für Ihr Konto, bevor Sie mit der gesamten angegebenen Kapazität planen. OpenRouter Modellinformationen.

5. Variante drei: Über decisions-api.dev aufrufen

decisions-api.dev stellt dieses Modell in seiner Arbeitsoberfläche und API bereit. Auf der Modellseite können Sie Fragen ausprobieren und Anfrageformate ansehen. Für den Aufruf aus Ihrer Anwendung verwenden Sie einen Schlüssel dieser Website. Modellseite zu GPT-6 Luna Decisions.

Für dieses Modell können Sie die Datei gateway-request.json aus dem vorherigen Abschnitt weiterverwenden. Die Website akzeptiert dieselben Felder model, state und das Objekt mit benannten Fragen. Adresse und äußeres Antwortformat unterscheiden sich jedoch. Kurzanleitung zur Integration.

Speichern Sie die Antwort in result.json. Diese Datei verwenden wir später für das Beispiel zur Anwendungslogik:

export DECISIONS_API_KEY="YOUR_DECISIONS_API_KEY"

curl --fail-with-body https://decisions-api.dev/v1/systemone \
  -H "Authorization: Bearer $DECISIONS_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @gateway-request.json \
  --output result.json

Der Header verwendet Ihren Schlüssel von decisions-api.dev. --output schreibt die JSON-Antwort in eine lokale Datei für die weitere Verarbeitung.

Dies ist ein Auszug aus einer erfolgreichen Antwort. Verbrauchsfelder sind ausgelassen; die Zahlen dienen weiterhin nur der Veranschaulichung:

{
  "code": 0,
  "message": "ok",
  "data": {
    "result": {
      "answers": {
        "route": {
          "type": "choice",
          "choice": "billing",
          "probabilities": { "billing": 0.92, "account": 0.03, "other": 0.05 },
          "confidence": 0.84
        }
      }
    }
  }
}

code: 0 kennzeichnet eine erfolgreiche Anfrage bei dieser Website. Die Klassifikation steht unter data.result.answers.route, der Tokenverbrauch unter data.result.usage und das abgebuchte Guthaben unter data.creditsUsed. Dokumentation der Antworten.

Die Website hat eigene Grenzen: höchstens acht Fragen, insgesamt 32 KiB für Text und Fragen sowie vier Bilder. Das Kontextfenster des Modellanbieters erhöht diese Grenzen nicht automatisch. Limits der Website.

6. Zwei weitere Fragen hinzufügen

Sobald die Zuordnung funktioniert, können Sie zusätzlich nach einer Erstattungsforderung und der Priorität fragen. Beide Fragen bewerten das ursprüngliche Ticket unabhängig von der Teamzuordnung.

Für den nativen OpenAI-Aufruf ergänzen Sie das folgende Objekt im Array questions:

{
  "name": "needs_refund",
  "type": "predicate",
  "instructions": "Verlangt das Ticket ausdrücklich die Rückzahlung eines Geldbetrags?"
}

Die Antwort auf predicate enthält im Feld probability die Wahrscheinlichkeit, dass die Bedingung zutrifft. Die Anwendung entscheidet anhand ihrer eigenen Regeln, ob eine Erstattungsprüfung beginnt.

Fügen Sie die folgende Prioritätsfrage demselben nativen Array hinzu:

{
  "name": "priority",
  "type": "score",
  "instructions": "Bewerten Sie die Priorität nur anhand der ausdrücklich beschriebenen Auswirkungen.",
  "levels": [
    {
      "label": "low",
      "description": "Frage oder Vorschlag; vorhandene Funktionen bleiben nutzbar"
    },
    {
      "label": "medium",
      "description": "Zahlungs- oder Funktionsproblem ohne ausdrücklich vollständige Blockade"
    },
    {
      "label": "high",
      "description": "Das Kerngeschäft ist vollständig blockiert und benötigt schnelle Bearbeitung"
    }
  ]
}

Die Stufen sind von niedrig nach hoch geordnet. Ihre Indizes beginnen bei null, hier also 0, 1 und 2. score ist der nach Wahrscheinlichkeiten gewichtete Mittelwert. Deshalb sind auch Werte wie 1,4 möglich. Offizielle Erläuterung zur Bewertung.

Bei OpenRouter oder decisions-api.dev fügen Sie stattdessen diese Einträge in das Objekt questions ein:

{
  "needs_refund": {
    "type": "noul",
    "instructions": "Verlangt das Ticket ausdrücklich die Rückzahlung eines Geldbetrags?"
  },
  "priority": {
    "type": "score",
    "instructions": "Bewerten Sie die Priorität nur anhand der ausdrücklich beschriebenen Auswirkungen.",
    "criteria": [
      "Niedrig: Frage oder Vorschlag; vorhandene Funktionen bleiben nutzbar",
      "Mittel: Zahlungs- oder Funktionsproblem ohne ausdrücklich vollständige Blockade",
      "Hoch: Das Kerngeschäft ist vollständig blockiert und benötigt schnelle Bearbeitung"
    ]
  }
}

Die Ja/Nein-Frage verwendet hier den Typ noul. Das Ergebnisfeld heißt ebenfalls noul und enthält die Wahrscheinlichkeit einer zutreffenden Bedingung. Für geordnete Bewertungsstufen verwenden Sie ein Array von Zeichenketten unter criteria. OpenRouter Fragenformate.

Unabhängige Fragen können dieselbe Anfrage verwenden. Wenn Sie erst eine Antwort benötigen, um die nächste Frage zu formulieren, senden Sie getrennte Aufrufe. Offizielle Hinweise zu mehreren Fragen.

7. Unsichere Ergebnisse im Programm behandeln

Nach der Antwort billing muss Ihr Programm weiterhin entscheiden, ob es das Ticket automatisch zuordnet. Diese Entscheidung richtet sich nach Ihren Geschäftsregeln und den ausgegebenen Wahrscheinlichkeiten.

Eine ausreichend eindeutige Auswahl kann in die Warteschlange des zuständigen Teams gelangen. Eine unsichere Auswahl oder other kann einer manuellen Prüfung zugewiesen werden.

Das folgende Beispiel liest die Datei result.json aus dem Aufruf dieser Website. Speichern Sie den Code als route.mjs und starten Sie ihn mit node route.mjs. Der Schwellenwert 0,85 ist ein Beispiel:

import { readFileSync } from 'node:fs';

const body = JSON.parse(readFileSync('result.json', 'utf8'));
if (body.code !== 0) throw new Error(body.message || 'Request failed');

const answer = body.data?.result?.answers?.route;
const probability = answer?.probabilities?.[answer.choice];
const canRoute =
  answer?.type === 'choice' &&
  ['billing', 'account'].includes(answer.choice) &&
  Number.isFinite(probability) &&
  probability >= 0.85;

console.log(canRoute ? answer.choice : 'manual-review');

Der Code prüft Antworttyp, erlaubten Zielwert und Wahrscheinlichkeit der ausgewählten Option. Schlägt eine Prüfung fehl, gibt er manual-review für die anschließende Warteschlangenlogik aus.

Ein Schwellenwert von 0,85 belegt keine gemessene Genauigkeit von 85 Prozent. Verwenden Sie echte Tickets mit manuell vergebenen Zielwerten. Beobachten Sie Fehlzuordnungen und Prüfaufwand, bevor Sie den Schwellenwert festlegen. Auch confidence ist ein eigenständiges Signal, das geprüft werden muss. Offizielle Interpretation der Antworten.

Bei Erstattungen bleiben die Geschäftsschritte klar getrennt: Das Modell erkennt eine Erstattungsforderung. Ihr Programm prüft anschließend Bestellung, Zahlungsdaten und Berechtigungen. Der hier gezeigte Decisions-Aufruf übernimmt die Klassifikation.

8. Preise und Limits gemeinsam betrachten

Am 7. Oktober 2026 wurden die folgenden Basispreise für Eingaben angegeben. Die tatsächlichen Kosten hängen auch vom verarbeiteten Material und den Abrechnungsregeln des Dienstes ab.

Zugangsweg	Basispreis für Eingaben	Kosten für Ausgaben	Quelle
OpenAI Decisions	0,10 US-Dollar pro Million Tokens	Keine Kosten für Ausgabe-Tokens	Offizielle Preise
OpenRouter	Die Modellseite nennt 0,10 US-Dollar pro Million Tokens	Die Modellseite nennt 0 US-Dollar	Modellpreise
decisions-api.dev	1.500 Credits pro Million Eingabe-Tokens, entsprechend 0,15 US-Dollar	Keine zusätzlichen Ausgabekosten	Website-Preise und Formel

Bei OpenAI können zusätzlich regionale Verarbeitungsaufschläge und Preisfaktoren für lange Kontexte gelten. Prüfen Sie diese Bedingungen, bevor Sie umfangreiche Eingaben kalkulieren. Offizielle Preisbedingungen.

decisions-api.dev rundet jede erfolgreiche Anfrage auf und berechnet mindestens einen Credit. Für dieses Modell gilt:

credits = max(1, ceil(input_tokens × 1500 / 1,000,000))

input_tokens ist der tatsächlich gemeldete Eingabeverbrauch des Modellanbieters einschließlich Fragen und verarbeiteter Bilder. Beispielsweise kosten 1.000 Eingabe-Tokens zwei Credits, 5.000 kosten acht. Mindestbetrag und Aufrundung beeinflussen die Kosten kleiner Anfragen. Abrechnungsdetails der Website.

Prüfen Sie beim Hinzufügen von Bildern das Anfrageformat erneut. OpenAI erwartet sie in Benutzernachrichten unter input, als input_image mit eingebetteter Data-URL. Diese Website akzeptiert zusätzlich das Feld images und wandelt es vor der Weiterleitung um. Anzahl, Größe und zulässige URLs richten sich nach der jeweiligen Dokumentation. OpenAI Bildschema, Bildparameter der Website.

Prüfen Sie bei Fehlern drei Bereiche: Anfragefelder bei HTTP 400, den Aussteller des Schlüssels bei HTTP 401 sowie Guthaben, Aufruffrequenz oder Anfragegröße bei HTTP 402, 429 oder 413. Die Fehlermeldung hilft bei der genauen Einordnung. OpenRouter Fehlerdefinitionen, Fehlerdokumentation der Website.

Wählen Sie den Zugang passend zu Ihrem vorhandenen Projekt. Wer bereits OpenAI nutzt, kann den nativen Endpunkt verwenden. Wer seine Modelle über OpenRouter verwaltet, kann dessen Decisions-Endpunkt nutzen. Wer Fragen in dieser Arbeitsoberfläche ausprobieren und dasselbe Guthabensystem verwenden möchte, kann den Endpunkt dieser Website wählen.

Beginnen Sie mit einer Frage und wenigen Tickets. Ergänzen Sie danach weitere Fragen, sammeln Sie manuell bewertete Beispiele und passen Sie die Schwellenwerte an. So entsteht eine Entscheidungskomponente, die sich als Teil Ihres Produkts prüfen und pflegen lässt.

---

Quellenstand: 7. Oktober 2026. Diese Anleitung wurde anhand öffentlicher Dokumentation, tatsächlich aufgerufener Dienstseiten und der OpenRouter-Aufrufprotokolle dieses Repositorys vom selben Datum geprüft. Für die Erstellung wurden keine neuen authentifizierten Aufrufe an alle drei Dienste vorgenommen. Das Ticket ist ein eigenes Beispiel; die Antwortzahlen erläutern das Format und belegen weder Genauigkeit noch Leistung. Die Illustrationen wurden mit ImageGen als Bleistiftzeichnungen mit englischen Beschriftungen erstellt.