OpenAI Assistants API abgeschaltet Migration für Trading-Tools.

Die Assistants API von OpenAI ist seit dem 26.08.2026 abgeschaltet und nicht mehr verfügbar. Wer Research-, Journal- oder Auswertungs-Tools für das Trading darauf gebaut hat, muss auf die Responses API und die Conversations API umziehen. Die Migration ist überschaubar, wenn Sie die Begriffe sauber zuordnen: Aus Assistants werden Prompts, aus Threads Conversations, aus Runs Responses und aus Run Steps Items. Zusätzlich stellt sich die Architekturfrage neu, denn OpenAI bietet seit dem 10.09.2026 die Agents API als Public Beta an und pflegt parallel das quelloffene Agents SDK. Dieser Artikel zeigt die Zuordnung, einen Migrationspfad mit Codebeispiel, die Abwägung zwischen SDK und Agents API inklusive Datenresidenz und die Leitplanken, die in Trading-Tools nicht verhandelbar sind. Stand Oktober 2026; die Agents API ist eine Beta, Details ändern sich schnell.

Was ist mit der Assistants API passiert?

OpenAI hat die Abkündigung am 26.08.2025 bekanntgegeben und die Assistants API genau ein Jahr später, am 26.08.2026, abgeschaltet. Der Hintergrund: Mit der Responses API (veröffentlicht im März 2025) wollte OpenAI alle Funktionen der Assistants API in eine einfachere Schnittstelle überführen. Seit August 2025 gibt es dafür ergänzend die Conversations API für dauerhafte Gesprächsverläufe. Laut Deprecation-Seite sind diese beiden Schnittstellen der empfohlene Ersatz.

Für Trading-Tools heißt das konkret: Alles, was Assistants, Threads oder Runs aufruft, liefert seit Ende August Fehler. Typische Beispiele aus diesem Umfeld sind ein nächtlicher Job, der Marktberichte zusammenfasst, ein Journal-Assistent, der Trades kommentiert, oder ein Backtest-Auswerter, der CSV-Dateien mit dem Code Interpreter analysiert. Wenn solche Werkzeuge seit Ende August still sind, liegt es mit hoher Wahrscheinlichkeit an der Abschaltung, nicht an Ihrem Code.

Wichtig für die Historie: OpenAIs Migrationsleitfaden empfiehlt, frühere Gesprächsverläufe aus den Nachrichten zu rekonstruieren, die Ihre eigene Anwendung gespeichert hat. Der Abruf von Thread-Nachrichten über die Assistants API funktioniert laut Leitfaden nicht mehr. Wer Threads nur bei OpenAI gehalten und nicht exportiert hat, kann sie auf diesem Weg nicht mehr abrufen. Der ältere Beitrag OpenAI Agents API für Trading beschreibt noch die Welt vor der Abschaltung; dieser Artikel ist die technische Fortsetzung.

Was ersetzt Assistants, Threads und Runs?

Der Migrationsleitfaden von OpenAI ordnet die alten Objekte eindeutig zu. Die Tabelle fasst das zusammen und ergänzt, was das für Ihren Code bedeutet:

Die eingebauten Werkzeuge gibt es weiterhin. File Search ist ein von OpenAI gehostetes Tool in der Responses API und arbeitet wie bisher mit Vector Stores, die Sie über vector_store_ids angeben. Der Code Interpreter läuft in einem Container; laut Dokumentation verfällt ein Container nach 20 Minuten Inaktivität, die Daten darin werden dann verworfen. Für einen Backtest-Auswerter heißt das: Ergebnisse sofort abholen und selbst speichern.

Beim Function Calling ändert sich das Format. Statt eines Run-Status, der eine Aktion verlangt, liefert die Response ein Item vom Typ function_call. Ihr Code führt die Funktion aus und schickt ein function_call_output mit derselben call_id zurück. Strukturierte Ausgaben konfigurieren Sie über text.format. Lassen Sie den Parameter strict weg, versucht die Responses API laut Dokumentation den strikten Modus und fällt zurück, wenn das Schema nicht kompatibel ist. Das kann Ausgaben gegenüber dem alten Verhalten verändern.

Neu zu bedenken ist die Aufbewahrung. Response-Objekte speichert OpenAI standardmäßig 30 Tage, abschaltbar mit store auf false. Conversations und ihre Items unterliegen dagegen nicht dieser 30-Tage-Frist, und laut OpenAIs Datenschutz-Dokumentation sind die Conversations-Endpunkte nicht für Zero Data Retention zugelassen. Wer Positionsdaten oder Strategiedetails in Conversations schreibt, braucht deshalb ein eigenes Löschkonzept.

Wie gelingt die Migration auf die Responses API?

In der Praxis bewährt sich eine Reihenfolge, die das Risiko klein hält und jederzeit einen Vergleich mit dem alten Verhalten erlaubt:

1. Inventur: Suchen Sie im Code nach allen Aufrufen von Assistants, Threads, Runs und Vector Stores. Notieren Sie je Stelle das Modell, die Tools, die Anweisungen und wo der Verlauf gespeichert wird.
2. Konfiguration übertragen: Legen Sie für jeden wichtigen Assistant einen Prompt an oder versionieren Sie die Anweisungen im eigenen Repository. Bei Trading-Tools ziehe ich das Repository vor, weil Änderungen dann im selben Review laufen wie der übrige Code.
3. Neue Sitzungen umstellen: Neue Gespräche starten über die Conversations API und laufen über die Responses API.
4. Altverlauf überführen: Gespeicherte Nachrichten aus Ihrer Datenbank in Conversation-Items umwandeln, sofern Sie den Kontext wirklich brauchen. Oft reicht eine Zusammenfassung.
5. Tool-Schleife umbauen: Polling auf Run-Status ersetzen durch die Auswertung von function_call-Items.
6. Ausgaben absichern: Strukturierte Ausgaben auf text.format umstellen und gegen das eigene Schema validieren.
7. Aufbewahrung festlegen: store, Löschroutinen und Logging bewusst setzen.

Ein vereinfachtes Python-Beispiel zeigt den Kern: eine Conversation anlegen, eine reine Lesefunktion anbieten und deren Ergebnis zurückgeben. Der Modellname ist ein Platzhalter.

import json
from openai import OpenAI

client = OpenAI()
conv = client.conversations.create()

tools = [{
    'type': 'function',
    'name': 'get_positions',
    'description': 'Liest offene Positionen (nur lesend).',
    'parameters': {'type': 'object', 'properties': {}, 'required': []},
}]

INSTR = 'Fasse Risiken zusammen. Keine Handelsempfehlungen.'

resp = client.responses.create(
    model='IHR_MODELL',
    conversation=conv.id,
    instructions=INSTR,
    input='Welche Positionen haben das höchste Exposure?',
    tools=tools,
)

for item in resp.output:
    if item.type == 'function_call' and item.name == 'get_positions':
        result = load_positions_readonly()  # Ihre eigene Funktion
        resp = client.responses.create(
            model='IHR_MODELL',
            conversation=conv.id,
            instructions=INSTR,
            input=[{'type': 'function_call_output',
                    'call_id': item.call_id,
                    'output': json.dumps(result)}],
            tools=tools,
        )

print(resp.output_text)

Alternativ zur Conversation können Sie Antworten über previous_response_id verketten. Beachten Sie dabei die Kosten: Laut Dokumentation werden alle vorherigen Eingabe-Tokens der Kette erneut als Eingabe abgerechnet. Bei langen Research-Sitzungen lohnt sich ein Blick auf die Compaction-Funktionen der API.

Agents SDK oder Agents API: Was passt wann?

Mit der Migration stellt sich die Frage, ob Sie nur die Schnittstelle tauschen oder gleich eine Agenten-Laufzeit einsetzen. Grob gibt es drei Wege, die sich vor allem darin unterscheiden, wo der Agent läuft und wer den Zustand hält:

Das Agents SDK ist quelloffen (MIT-Lizenz), liegt für Python aktuell in Version 0.23.1 vom 02.10.2026 vor und unterstützt Python 3.10 bis 3.14. Es bringt Handoffs (Übergabe an spezialisierte Agenten), Guardrails für Ein- und Ausgaben, Human-in-the-Loop-Freigaben, Sessions, Tracing und MCP-Werkzeuge mit. Laut Projektbeschreibung funktioniert es neben OpenAI mit über 100 weiteren Sprachmodellen. Für Trading-Tools ist das ein Argument: Sie können ein Modell austauschen, ohne die Orchestrierung neu zu schreiben, und die Freigabelogik bleibt in Ihrem Code.

Die Agents API ist seit dem 10.09.2026 als Public Beta verfügbar. OpenAI betreibt dort einen verwalteten Codex-Harness, der Sessions, Orchestrierung, Kontextverdichtung und Wiederaufnahme übernimmt. Bausteine sind Agent (Modell, Anweisungen, Tools, MCP-Server), Environment (optionale Sandbox), Session und Events beziehungsweise Items. MCP-Server bindet die Agents API über HTTP an. Abgerechnet werden Modell-Tokens zu den API-Preisen des gewählten Modells, OpenAI-Tools zu ihren Standardpreisen und von OpenAI gehostete Sandboxes zu den üblichen Container-Preisen. Bequem ist das vor allem für längere Aufgaben, etwa die Dokumentation eines Backtest-Repositorys oder die Auswertung öffentlicher Daten.

Welche Datenresidenz bietet die Agents API?

Laut OpenAIs eigener Dokumentation unterstützt die Agents API derzeit Datenresidenz nur in den USA und kein Zero Data Retention. Zero Data Retention (ZDR) bedeutet, dass OpenAI Ein- und Ausgaben nicht speichert; diese Option fehlt hier. Auch eine selbst gehostete Sandbox macht die Agents API laut OpenAI nicht ZDR-fähig. Wer also Kontostände, Positionsdaten, Strategielogik oder personenbezogene Daten von Kunden an die Agents API gibt, verarbeitet diese in den USA und mit Speicherung beim Anbieter.

Für viele Trading-Entwickler ist das kein Datenschutzproblem im engeren Sinn, wohl aber ein Thema für Geschäftsgeheimnisse. Strategieparameter und Ausführungslogik sind oft das eigentliche Kapital. Sobald personenbezogene Daten im Spiel sind, etwa bei Vermögensverwaltern oder Family Offices, kommt die DSGVO hinzu. Die rechtliche Bewertung gehört zu Ihrem Datenschutzbeauftragten oder Anwalt; technisch können Sie vorher drei Dinge entscheiden:

• Datenklassen trennen: öffentliche Marktdaten und Nachrichten an die Agents API, Konto- und Strategiedaten nur in die eigene Infrastruktur.
• Lokale Orchestrierung wählen: Mit dem Agents SDK oder der Responses API bleibt die Steuerung bei Ihnen, und Sie können store sowie Löschroutinen selbst setzen.
• Projekte gezielt anlegen: Für viele andere Endpunkte bietet OpenAI Projekte mit Datenresidenz in Europa (EWR und Schweiz) an, sofern Datenresidenz für Ihr Konto freigeschaltet ist; die Agents API ist laut Dokumentation davon ausgenommen. Prüfen Sie den Stand vor jeder Architekturentscheidung neu, gerade in der Beta-Phase.

Leitplanken für Trading-Tools: Lesen ja, Ausführen nur mit Freigabe.

Eine Migration ist ein guter Zeitpunkt, die Rechte eines Agenten neu zu schneiden. OpenAIs Nutzungsrichtlinien untersagen, folgenreiche Entscheidungen unter anderem im Finanzbereich ohne menschliche Prüfung zu automatisieren. Unabhängig davon ist es schlicht gutes Handwerk: Ein Sprachmodell kann Zahlen verwechseln, Anweisungen aus eingeschleusten Texten übernehmen oder eine Funktion mit falschen Parametern aufrufen. Eine Order ist danach nicht mehr rückgängig zu machen.

Bewährt hat sich eine klare Rollentrennung:

• Agent: liest Marktdaten, Positionen und Nachrichten, fasst zusammen, schlägt vor und erzeugt bestenfalls einen Order-Entwurf.
• Deterministischer Code: prüft Limits wie maximale Positionsgröße, erlaubte Instrumente, Handelszeiten und Tagesverlust.
• Mensch: gibt den Entwurf frei, idealerweise in der Oberfläche des Brokers, nicht im Chat.
• Schlüssel: API-Schlüssel des Agenten nur mit Leserechten, Ausführungsschlüssel getrennt verwahren.

Im Agents SDK markieren Sie Werkzeuge mit needs_approval=True. Der Lauf hält dann an, die offene Freigabe erscheint in result.interruptions, und Ihr Code setzt ihn nach state.approve(...) oder state.reject(...) fort. Den pausierten Zustand können Sie serialisieren und später wieder aufnehmen. Schematisch:

from agents import Agent, Runner, function_tool

@function_tool(needs_approval=True)
def create_order_ticket(symbol: str, qty: int) -> str:
    '''Legt nur einen Entwurf in der internen Freigabe-Queue an.'''
    return write_ticket(symbol, qty)  # keine Broker-Verbindung

agent = Agent(name='Research', instructions='...', tools=[create_order_ticket])
result = await Runner.run(agent, 'Prüfe das Risiko im Depot.')

if result.interruptions:
    state = result.to_state()
    for item in result.interruptions:
        state.reject(item)  # Standard: ablehnen, Freigabe nur manuell
    result = await Runner.run(agent, state)

Für Remote-MCP-Server in der Responses API fragt OpenAI standardmäßig eine Freigabe an, bevor Daten an den Server gehen. Setzen Sie require_approval für schreibende Werkzeuge nie auf never und begrenzen Sie mit allowed_tools, welche Funktionen das Modell überhaupt sieht. Mehr zu diesem Muster finden Sie im Beitrag Guardrails für Trading-Agenten.

Grenzen und Risiken der Migration.

Eine API-Migration klingt nach reinem Umbau, verändert aber oft das Verhalten. Diese Punkte sollten Sie einplanen:

• Anderes Ausgabeverhalten: Strict-Modus als Standard, neue Item-Struktur und gegebenenfalls ein neueres Modell führen zu anderen Antworten. Ein Tool, das vorher stabil lief, kann nach der Umstellung Felder anders befüllen.
• Beta-Status: Die Agents API ist eine Public Beta. Schnittstellen, Preise und Funktionsumfang können sich ändern; für produktive Pfade mit Geld im Spiel ist das ein Risiko.
• Prompt Injection über Werkzeuge: OpenAI warnt selbst, dass ein bösartiger MCP-Server sensible Daten aus dem Modellkontext abziehen kann. Nachrichtenfeeds und Webseiten sind ebenfalls Einfallstore.
• Datenhaltung: Conversations ohne 30-Tage-Frist sammeln Daten, bis Sie sie löschen.
• Kosten: Verkettete Antworten rechnen den gesamten Vorverlauf erneut ab; Container und Tools kommen hinzu.
• Kein Ersatz für Tests: Ein Agent, der einen Backtest auswertet, prüft weder Überanpassung noch Datenfehler zuverlässig. Die Verantwortung für Strategie und Risiko bleibt bei Ihnen; automatisierter Handel kann zu erheblichen Verlusten bis zum Totalverlust führen.

Migrations-Checkliste mit Regressionstests.

Damit die Umstellung nicht zum Blindflug wird, lohnt sich ein kleiner, fester Testsatz. Mit dieser Liste bleibt der Umzug eines Trading-Tools nachvollziehbar und überprüfbar:

1. Referenzfälle sammeln: 20 bis 50 typische Eingaben mit den bisherigen Ausgaben aus Ihren Logs, darunter Grenzfälle wie leere Depots, Feiertage und fehlerhafte Kursdaten.
2. Strukturierte Ausgaben vergleichen: Felder, Datentypen und Wertebereiche automatisch gegen das Schema prüfen, Freitext nur stichprobenartig.
3. Tool-Aufrufe protokollieren: Testen, welche Funktionen in welcher Reihenfolge aufgerufen werden. Ein harter Test: Kein Werkzeug mit Schreibrechten wird ohne Freigabe ausgeführt.
4. Angriffstests ergänzen: Eingeschleuste Anweisungen in Nachrichtentexten dürfen keine Aktion auslösen.
5. Kosten und Latenz messen: Tokens und Laufzeit je Fall vor und nach der Migration festhalten.
6. Parallel laufen lassen: Die neue Version einige Tage im Schattenbetrieb neben dem bisherigen Prozess, Ergebnisse vergleichen, erst dann umschalten.
7. Dokumentieren: Datenflüsse, Aufbewahrung, Freigabewege und Verantwortliche schriftlich festhalten.

Wenn Sie dabei Unterstützung brauchen: Bei der Trading-Automatisierung gehören genau diese Schritte zum Standard, unabhängig davon, ob am Ende OpenAI, ein anderes Modell oder gar kein Sprachmodell im Live-Pfad steht.

Häufige Fragen.

Funktioniert die OpenAI Assistants API noch?

Nein. OpenAI hat die Assistants API am 26.08.2026 abgeschaltet, sie ist nicht mehr verfügbar. Die Abkündigung wurde ein Jahr vorher, am 26.08.2025, veröffentlicht. Als Ersatz empfiehlt OpenAI die Responses API für einzelne Aufrufe und die Conversations API für dauerhafte Gesprächsverläufe. Code, der Assistants, Threads oder Runs aufruft, muss umgebaut werden.

Was ersetzt Threads und Runs aus der Assistants API?

Threads werden zu Conversations, Runs zu Responses und Run Steps zu Items; auch Nachrichten sind nur noch ein Item-Typ. Assistants selbst werden zu Prompts, also versionierbarer Konfiguration aus Modell, Tools und Anweisungen. Statt auf einen Run-Status zu warten, werten Sie Items wie function_call aus und senden das Ergebnis als function_call_output mit derselben call_id zurück.

Soll ich für ein Trading-Tool das Agents SDK oder die Agents API nutzen?

Für Tools mit Konto-, Positions- oder Strategiedaten ist das Agents SDK meist die bessere Wahl, weil es in Ihrer eigenen Anwendung läuft und Freigaben, Speicher und Logging bei Ihnen bleiben. Die Agents API ist bequemer, aber eine Beta, unterstützt derzeit nur Datenresidenz in den USA und kein Zero Data Retention.

Darf ein OpenAI-Agent selbstständig Orders beim Broker platzieren?

OpenAIs Nutzungsrichtlinien untersagen, folgenreiche Entscheidungen im Finanzbereich ohne menschliche Prüfung zu automatisieren. Technisch sinnvoll ist ohnehin, dass der Agent nur liest und Entwürfe erstellt, deterministischer Code Limits prüft und ein Mensch jede Order freigibt. Im Agents SDK erzwingen Sie das mit needs_approval an den betreffenden Werkzeugen.

Wie lange speichert OpenAI Daten aus der Responses API?

Response-Objekte werden laut Dokumentation standardmäßig 30 Tage gespeichert; mit store auf false lässt sich das abschalten. Conversations und ihre Items unterliegen dieser 30-Tage-Frist nicht und bleiben bestehen, bis Sie sie löschen. Für sensible Trading-Daten brauchen Sie daher ein eigenes Lösch- und Aufbewahrungskonzept.

Quellen und Stand.

• Deprecations — OpenAI
• Assistants migration guide — OpenAI
• Conversation state — OpenAI
• Agents API overview — OpenAI
• Data controls in the OpenAI platform — OpenAI
• openai-agents 0.23.1 (Agents SDK für Python) — PyPI
• Human-in-the-loop (OpenAI Agents SDK) — OpenAI
• MCP and Connectors — OpenAI
• Usage policies — OpenAI
• Changelog (Agents API Public Beta, 10.09.2026) — OpenAI

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

Ihr Research- oder Trading-Tool hängt noch an der Assistants API? Unverbindlich anfragen — wir klären Migrationsumfang, Regressionstests und saubere Freigabewege für den Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.