OpenAI Decisions API News für Trading-Research einordnen.

Die OpenAI Decisions API ist ein neuer Endpunkt, der zu einem Text oder Bild keine formulierte Antwort schreibt, sondern typisierte Antworten mit Wahrscheinlichkeiten zurückgibt: ja oder nein, eine Option aus einer festen Liste oder eine Stufe auf einer Skala. Für Trading-Research ist das interessant, weil sich damit Nachrichten, Ad-hoc-Meldungen und Filings schnell und günstig vorsortieren lassen. Stand Oktober 2026 ist die API seit dem 06.10.2026 in der Public Beta, läuft ausschließlich mit gpt-6-luna und kostet 0,10 $ pro 1 Mio. Input-Tokens, Output ist kostenlos. Dieser Leitfaden zeigt, welcher Fragetyp zu welcher Research-Aufgabe passt, was 10.000 Meldungen am Tag ungefähr kosten, warum Sie die Wahrscheinlichkeiten nicht ungeprüft als kalibriert behandeln sollten und wo die klare Grenze liegt: Der Klassifikator liefert ein Research-Signal, keine Order.

Was ist die OpenAI Decisions API und was unterscheidet sie von der Responses API?

Die Decisions API ist ein eigener Endpunkt (POST /v1/decisions). Ein Request besteht aus drei Teilen: dem Modell (gpt-6-luna), dem input als Text oder als Nachricht mit Text und Bildern, und einem Array questions mit den Fragen, die das Modell zum Input beantworten soll. Zurück kommt ein Array answers mit genau einer typisierten Antwort pro Frage. Freitext erzeugt die API nicht.

Die Responses API ist dagegen das Allzweck-Werkzeug: Sie generiert Text, kann mit Structured Outputs ein eigenes JSON-Schema befüllen und Tools aufrufen. OpenAI grenzt das selbst so ab: Decisions, wenn Ihre Anwendung eine der drei Antwortarten braucht; Structured Outputs mit der Responses API, wenn Sie ein Objekt nach Ihrem eigenen JSON-Schema erzeugen wollen, etwa um Felder zu extrahieren. Für Trading-Research heißt das: Wer aus einer Meldung Beträge, Daten und Kennzahlen herausziehen will, bleibt bei der Extraktion mit Structured Outputs, wie im Artikel zur Event-Extraktion aus News beschrieben. Wer nur wissen will, ob eine Meldung relevant ist und in welche Schublade sie gehört, ist mit der Decisions API schneller und günstiger unterwegs.

Einige Details aus der Dokumentation, die für den Betrieb zählen:

• Status: Public Beta seit 06.10.2026; OpenAI erwartet die allgemeine Verfügbarkeit „in den kommenden Wochen“.
• Modell: nur gpt-6-luna, das günstigste Modell der GPT-6-Familie.
• Bilder: nur als eingebettete Base64-Daten-URL, keine HTTP-Links und keine Datei-IDs. Für Charts oder Screenshots von Tabellen relevant.
• Mehrere Fragen: Unabhängige Fragen lassen sich in einem Request bündeln. Hängt eine Frage von der Antwort einer anderen ab, brauchen Sie getrennte Requests.
• SDK: Es ist eine aktuelle SDK-Version nötig, für Python laut Doku ab 3.26.0.

Predicate, choice, score: welcher Fragetyp passt zu welcher Research-Aufgabe?

Die drei Fragetypen decken die typischen Vorsortier-Aufgaben in einem News-Workflow ab. Wichtig ist, die Frage so zu stellen, dass eine Fachperson sie ohne Zusatzwissen eindeutig beantworten könnte. Unscharfe Fragen ergeben unscharfe Wahrscheinlichkeiten.

Bei choice gehört immer eine Auffangoption wie „Sonstiges“ in die Liste. Ohne sie zwingen Sie das Modell, eine unpassende Meldung in eine falsche Kategorie zu drücken. Die Beschreibungen der Optionen sind Teil der Frage: Je klarer „Kapitalmaßnahme“ von „Transaktion“ abgegrenzt ist, desto weniger Verwechslungen.

Bei score ist der Rückgabewert ein wahrscheinlichkeitsgewichteter Mittelwert und kann zwischen zwei Stufen liegen. Die Stufen werden laut Dokumentation ab null gezählt: Bei drei Stufen mit den Wahrscheinlichkeiten 0,1, 0,7 und 0,2 ergibt sich ein Score von 1,1. Legen Sie Schwellenwerte deshalb auf dieser Skala fest und prüfen Sie sie mit eigenen Testfällen. Ein Wert von 1,0 kann außerdem zwei Dinge bedeuten: Das Modell ist sich der mittleren Stufe sicher, oder es schwankt zwischen „Archiv“ und „Sofort“. Deshalb lohnt es sich, neben dem Score auch die Verteilung in probabilities zu speichern.

Für Ad-hoc-Meldungen, also Insiderinformationen, die Emittenten nach Art. 17 der EU-Marktmissbrauchsverordnung veröffentlichen müssen, ist die Relevanzfrage oft weniger wichtig als der Ereignistyp, denn veröffentlicht wird gerade das, was der Emittent für kursrelevant hält. Bei allgemeinen Nachrichtenfeeds und Pressemitteilungen ist es umgekehrt: Dort filtert das predicate den größten Teil weg.

Rechenbeispiel: Was kostet die Klassifikation von 10.000 Meldungen am Tag?

Die Preislogik ist einfach: 0,10 $ pro 1 Mio. Input-Tokens, keine Kosten für Output, Cache-Reads und Cache-Writes. Hinzu kommen der Aufschlag für Regional Processing, laut OpenAI-Preisseite 10 % für Modelle ab Release 05.03.2026, und Long-Context-Aufschläge für Eingaben über 272.000 Tokens. Letztere spielen bei einzelnen Meldungen praktisch keine Rolle, bei vollständigen Jahresberichten schon.

Rechenbeispiel mit konservativen Annahmen: Eine Meldung hat inklusive Anweisungen, Optionsbeschreibungen und Stufen rund 1.500 Input-Tokens. Deutschsprachige Texte brauchen in der Regel mehr Tokens pro Wort als englische, messen Sie den Wert deshalb an Ihren eigenen Daten.

Die API-Kosten sind damit selten der Engpass. Teurer sind meist die Datenquelle selbst, also Newsfeed-Lizenzen und Filing-Zugänge, und vor allem die Arbeitszeit für Testmenge, Pflege und Prüfung. Ein Punkt, den Sie im Blick behalten sollten: Weil Output kostenlos ist, verleitet die API dazu, viele Fragen pro Meldung zu stellen. Jede zusätzliche Frage verlängert aber den Input um ihre Anweisungen und Optionen. Bündeln Sie nur Fragen, deren Ergebnis Sie tatsächlich verwenden.

Zum Vergleich ohne Wertung: Perplexity hat im Oktober 2026 eine eigene Decisions API gestartet (Modell pplx-decider-v1-27b, 0,04 $ pro 1 Mio. Input-Tokens, Output kostenlos), die ebenso Wahrscheinlichkeiten statt Text liefert. Ob sich ein Wechsel lohnt, entscheidet nicht der Listenpreis, sondern die Trefferquote auf Ihrer eigenen Testmenge.

Sind die Wahrscheinlichkeiten kalibriert?

Kalibriert hieße: Von allen Meldungen, denen das Modell 0,8 gibt, sind tatsächlich rund 80 % relevant. Ob das für gpt-6-luna in der Decisions API gilt, dokumentiert OpenAI nicht. Die Doku empfiehlt stattdessen, Schwellenwerte für Routing, Filterung und Prüfung mit gelabelten Beispielen aus der eigenen Anwendung festzulegen. Das ist auch fachlich der richtige Weg, denn Kalibrierung hängt von Ihren Daten ab: Ein Modell kann auf englischen US-Filings gut kalibriert sein und auf deutschen Small-Cap-Meldungen deutlich danebenliegen.

So bauen Sie eine belastbare Testmenge auf:

1. Stichprobe ziehen: einige hundert echte Meldungen aus Ihrem Feed, gemischt über Wochen, Branchen und Sprachen. Nicht nur spektakuläre Fälle.
2. Von Hand labeln: Relevanz, Ereignistyp und Dringlichkeit nach schriftlich festgelegten Regeln. Bei Grenzfällen notieren Sie, warum.
3. Durchlaufen lassen: alle Antworten inklusive probabilities und confidence speichern.
4. Auswerten: Wahrscheinlichkeiten in Bänder teilen (0,0–0,1, 0,1–0,2 usw.) und je Band die tatsächliche Trefferquote ausrechnen. Das zeigt, ob 0,8 bei Ihnen wirklich etwa 80 % bedeutet.
5. Schwelle wählen: nach den Kosten der Fehler, nicht nach einer runden Zahl.

Die Fehlerkosten sind asymmetrisch. Eine übersehene Gewinnwarnung (falsch negativ) wiegt in der Regel schwerer als zehn irrelevante Meldungen in der Prüfliste (falsch positiv). Eine niedrige Schwelle für die Relevanzfrage ist deshalb oft sinnvoll, solange die Prüfliste bewältigbar bleibt. Wie sich solche Fehler auf ein Trading-Setup auswirken, beschreibt der Artikel Wenn das LLM falsch klassifiziert.

Wiederholen Sie die Auswertung regelmäßig. Ein Modell-Update in der Beta, neue Meldungsformate oder eine geänderte Fragestellung können die Verteilung verschieben, ohne dass eine Fehlermeldung erscheint.

Datenschutz und Betrieb: Was gilt für EU-Processing, ZDR und die Beta?

Laut Dokumentation unterstützt die Decisions API Zero Data Retention (ZDR, keine Speicherung der Anfragen bei OpenAI) für berechtigte Kunden und Regional Processing in den USA und in Europa, also im EWR und der Schweiz. ZDR ist kein Schalter für jeden, sondern muss für die Organisation freigegeben sein.

Für öffentliche Meldungen und Filings ist die Datenschutzfrage meist überschaubar. Anders sieht es aus, sobald Sie eigene Daten mitschicken: Research-Notizen, Positionslisten, interne Einschätzungen oder Kundendaten bei einem Vermögensverwalter. Dann sind Regional Processing in Europa, ein Auftragsverarbeitungsvertrag und eine klare Regel, welche Felder überhaupt an die API gehen, die Mindestausstattung. Datenschutzfreundlich wird so ein Setup erst, wenn diese Regeln auch technisch durchgesetzt werden, etwa indem der Code nur den Meldungstext übergibt.

Betrieblich bedeutet Beta: Verhalten, Parameter und Modellstand können sich ändern. Für einen Research-Workflow sind das handhabbare Risiken, wenn Sie vorsorgen:

• Modellname, SDK-Version und Fragedefinition mit jeder Antwort protokollieren.
• Eine kleine feste Kontrollmenge täglich durchlaufen lassen und Abweichungen melden.
• Timeouts und Fehler abfangen: Fällt die API aus, landen Meldungen ungefiltert in der Prüfliste statt still im Archiv.
• Die Geschwindigkeitsangabe von OpenAI (etwa zehnmal schneller als die Responses API) unter Ihrer eigenen Last messen, bevor Sie Latenz-Annahmen in den Workflow einbauen.

Grenzen: Research-Signal statt Orderauslöser.

Technisch wäre es leicht, aus „Ereignistyp = Gewinnwarnung, Dringlichkeit = sofort“ direkt eine Order zu machen. Genau das sollten Sie nicht tun. Ein Klassifikator bewertet Text, nicht den Markt: Er weiß nicht, ob die Information schon eingepreist ist, wie liquide das Instrument ist, ob die Meldung korrigiert wird oder ob es sich um eine Fälschung handelt. Wenn ich Trading-Systeme entwickle, trenne ich deshalb grundsätzlich die Signalerzeugung aus Texten von der Ausführung mit eigener Risikologik, Positionslimits und Not-Aus.

Auch OpenAI zieht hier eine Linie: Die Nutzungsrichtlinien (Fassung vom 29.10.2025) untersagen, Entscheidungen mit hoher Tragweite in sensiblen Bereichen ohne menschliche Prüfung zu automatisieren; ausdrücklich genannt sind unter anderem Finanzaktivitäten und Kredite. Für den Research-Einsatz heißt das: Die API sortiert vor, ein Mensch liest und entscheidet.

Weitere Grenzen, die Sie kennen sollten:

• Keine Begründung: Die API liefert Zahlen, keinen Text. Warum eine Meldung als dringend gilt, sehen Sie nicht. Für Stichproben-Audits brauchen Sie gegebenenfalls zusätzlich ein generatives Modell.
• Keine Abhängigkeiten in einem Request: „Wenn relevant, dann Ereignistyp“ geht nur über zwei Aufrufe.
• Nur ein Modell: Stößt gpt-6-luna bei schwierigen Texten an Grenzen, gibt es innerhalb der Decisions API keine größere Alternative.
• Totalverlust bleibt möglich: Gute Klassifikation verbessert den Informationsfluss, sie macht Trading nicht risikolos. Hebelprodukte und automatisierte Ausführung verstärken jeden Fehler.

So bauen Sie einen ersten Klassifikator mit Prüfschleife.

Das folgende Python-Beispiel stellt drei unabhängige Fragen zu einer Meldung in einem Request. Die Struktur folgt der OpenAI-Dokumentation; Texte und Kategorien sind Platzhalter, die Sie an Ihre Quellen anpassen.

from openai import OpenAI

client = OpenAI()  # API-Key aus der Umgebungsvariable OPENAI_API_KEY

meldung = "...Volltext der Meldung..."

decision = client.decisions.create(
    model="gpt-6-luna",
    input=meldung,
    questions=[
        {"type": "predicate", "name": "relevant",
         "instructions": "Enthält die Meldung eine neue, potenziell kursrelevante "
                         "Information zum Emittenten (keine Wiederholung, keine Werbung)?"},
        {"type": "choice", "name": "ereignis",
         "instructions": "Welcher Ereignistyp beschreibt die Meldung am besten?",
         "choices": [
             {"value": "prognose", "description": "Prognoseänderung oder Gewinnwarnung"},
             {"value": "kapital", "description": "Kapitalerhöhung, Aktienrückkauf, Dividende"},
             {"value": "personal", "description": "Wechsel in Vorstand oder Aufsichtsrat"},
             {"value": "transaktion", "description": "Übernahme, Fusion, Verkauf von Geschäftsteilen"},
             {"value": "sonstiges", "description": "Alles, was nicht in die anderen Typen passt"}]},
        {"type": "score", "name": "dringlichkeit",
         "instructions": "Wie schnell sollte ein Analyst diese Meldung lesen?",
         "levels": [
             {"label": "Archiv", "description": "Kein Handlungsbedarf, nur ablegen"},
             {"label": "Heute", "description": "Im Tagesverlauf prüfen"},
             {"label": "Sofort", "description": "Sofort lesen und einordnen"}]},
    ],
)

for a in decision.answers:
    if a.type == "refusal":  # das Modell hat die Frage nicht beantwortet
        print(a.name, "abgelehnt")
        continue
    print(a.name, a.type, getattr(a, "probability", None),
          getattr(a, "choice", None), getattr(a, "score", None),
          getattr(a, "confidence", None))

Jede Antwort kann statt des erwarteten Typs auch vom Typ refusal sein; die Beispiele in der Dokumentation fangen diesen Fall ab. Behandeln Sie eine Ablehnung wie einen Fehler: Die Meldung landet ungefiltert in der Prüfliste. Daraus wird ein Workflow in fünf Schritten:

1. Fragen schriftlich definieren: Relevanz, Ereignisliste mit „Sonstiges“, Dringlichkeitsstufen. Jede Option mit einer Beschreibung, die auch ein Kollege versteht.
2. Testmenge labeln und die Antworten samt Wahrscheinlichkeiten speichern, zum Beispiel in SQLite oder Parquet.
3. Schwellen festlegen: etwa Prüfliste ab einer bestimmten Relevanz-Wahrscheinlichkeit, Alarm nur bei hoher Dringlichkeit und ausreichender Konfidenz. Die Werte kommen aus Ihrer Auswertung, nicht aus diesem Artikel.
4. Schattenbetrieb: zwei bis vier Wochen parallel zur bisherigen Sichtung laufen lassen und jede Abweichung ansehen.
5. Prüfschleife verankern: Was ein Mensch korrigiert, wandert als neues Label in die Testmenge. So sehen Sie Drift früh.

Am Ende steht eine sortierte Prüfliste, keine automatische Order. Wenn Sie einen solchen Klassifikator in eine bestehende Research- oder Trading-Infrastruktur einbinden wollen, mit Protokollierung, Tests und sauberer Trennung von der Ausführung, ist das ein typisches Thema für die Trading-Automatisierung, für private Trader ebenso wie für Unternehmen.

Häufige Fragen.

Was kostet die OpenAI Decisions API?

Stand Oktober 2026 kostet die Decisions API 0,10 US-Dollar pro 1 Million Input-Tokens. Output, Cache-Reads und Cache-Writes werden nicht berechnet. Für Regional Processing kommt laut OpenAI-Preisseite ein Aufschlag von 10 Prozent hinzu, für sehr lange Eingaben über 272.000 Tokens gelten Long-Context-Preise. Rechenbeispiel: 10.000 Meldungen mit je 1.500 Tokens kosten damit rund 1,50 bis 1,65 US-Dollar pro Tag.

Welches Modell nutzt die OpenAI Decisions API?

Die Decisions API läuft in der Public Beta ausschließlich mit gpt-6-luna, dem günstigsten Modell der GPT-6-Familie laut OpenAI-Preisliste. Andere Modelle lassen sich dort derzeit nicht auswählen. OpenAI gibt an, dass die API typisierte Antworten etwa zehnmal schneller liefert als die Responses API; das ist eine Herstellerangabe, die Sie unter eigener Last nachmessen sollten.

Kann ich die Wahrscheinlichkeiten der Decisions API direkt als Trefferquote verwenden?

Nicht ohne Prüfung. OpenAI dokumentiert nicht, wie gut die Wahrscheinlichkeiten kalibriert sind, und empfiehlt, Schwellenwerte mit gelabelten Beispielen aus der eigenen Anwendung festzulegen. Bauen Sie eine Testmenge aus einigen hundert eigenen Meldungen auf, vergleichen Sie Wahrscheinlichkeitsbänder mit der tatsächlichen Trefferquote und wählen Sie Schwellen nach den Kosten von Fehlklassifikationen.

Kann die Decisions API in der EU genutzt werden?

Laut OpenAI-Dokumentation unterstützt die Decisions API Regional Processing in den USA und in Europa, also im EWR und in der Schweiz. Zero Data Retention ist für berechtigte Kunden verfügbar. Ob Ihr konkretes Setup datenschutzrechtlich passt, hängt davon ab, welche Daten Sie übermitteln; das sollten Sie im Einzelfall mit Ihrem Datenschutzbeauftragten oder einem Anwalt klären.

Darf ich mit der Decisions API automatisch Trades auslösen?

Technisch ließe sich das bauen, sinnvoll ist es nicht. Die Nutzungsrichtlinien von OpenAI untersagen, Entscheidungen mit hoher Tragweite im Finanzbereich ohne menschliche Prüfung zu automatisieren. Nutzen Sie die Klassifikation als Research-Signal, das eine Prüfliste sortiert, und halten Sie die Orderausführung mit eigener Risikologik davon getrennt.

Quellen und Stand.

• Decisions API guide — OpenAI
• API Changelog (Eintrag 06.10.2026) — OpenAI
• API Pricing — OpenAI
• GPT-6 Luna (Modellseite) — OpenAI
• Usage Policies — OpenAI
• API Changelog (Decisions API, Oktober 2026) — Perplexity
• Verordnung (EU) Nr. 596/2014 über Marktmissbrauch (MAR) — EUR-Lex

Stand: 7. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen News, Ad-hoc-Meldungen oder Filings automatisch für Ihr Trading-Research vorsortieren? Unverbindlich anfragen — wir klären Datenquellen, Testmenge, Schwellenwerte und die saubere Trennung von der Ausführung. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.