OpenAI Agents API für Trading: was geht, was ist Marketing.
Seit OpenAI seine Schnittstellen zur Agents-Plattform ausgebaut hat, ist „Agent“ das Lieblings-Buzzword in jedem Pitch-Deck. Ich nutze die API täglich, parallel zu Anthropic. Hier ist, was im Trading-Kontext tatsächlich funktioniert — und wo die Demos das Marketing mehr lieben als die Realität. Hinweis: Die Assistants-API mit serverseitigen Threads, auf der dieser Beitrag ursprünglich aufbaute, hat OpenAI am 26.08.2026 abgeschaltet. Wie Sie heute mit Responses API, Conversations API und Agents SDK arbeiten, zeigt der Beitrag zur Assistants-Migration.
Was die Agents-API überhaupt ist.
OpenAIs Agenten-Werkzeuge kombinieren ein Modell, eingebaute Tools (Code-Interpreter, File-Search, Web-Suche) und Function-Calling zu einem orchestrierten Setup. Sie schicken eine Nachricht, der Agent entscheidet, welche Tools er braucht, läuft die Schleife durch und gibt eine Antwort zurück.
Der Unterschied zur reinen Chat-Completion-API: Sie müssen die Tool-Aufrufe nicht selbst orchestrieren. Die serverseitige Orchestrierung nimmt Ihnen den State-Handling-Aufwand ab. Das ist bequem — und ein zweischneidiges Schwert, weil Sie weniger Kontrolle haben.
Vergleich zu Anthropic Tool-Use.
Anthropics Tool-Use-Pattern ist konzeptionell schlanker: Sie schicken bei jedem API-Call den vollständigen Verlauf, das Modell antwortet mit einer Tool-Anfrage, Sie führen das Tool clientseitig aus, schicken das Ergebnis zurück. Mehr Latenz pro Call, dafür voller Kontrollfluss bei Ihnen.
Die Unterschiede in der Praxis:
- State: OpenAI kann Gesprächsverläufe serverseitig halten (heute über die Conversations API). Bequem, aber Sie müssen sie aktiv aufräumen. Anthropic ist stateless — Sie schicken den Kontext immer mit.
- Eingebaute Tools: OpenAI liefert Code-Interpreter und File-Search out of the box. Bei Anthropic stehen ebenfalls eingebaute Werkzeuge bereit, eigene Werkzeuge bindet man über MCP-Server an.
- Reasoning-Qualität: Aktuell liefert Claude bei komplexem Code und langen Reasoning-Ketten etwas robustere Ergebnisse. Kleinere, günstige Modelle sind schneller und billiger für strukturierte Workflows.
- Function-Calling-Stabilität: Beide sind inzwischen sehr stabil. Strukturierte Outputs mit JSON-Schema-Garantien funktionieren bei beiden zuverlässig.
Function-Calling für Trade-Logik.
Function-Calling ist der Kern. Sie definieren Funktionen, der Agent ruft sie auf. Im Trading-Kontext sieht das typischerweise so aus:
tools = [
{
"type": "function",
"function": {
"name": "get_quote",
"description": "Aktuelle Quote für ein Symbol",
"parameters": {
"type": "object",
"properties": {
"symbol": {"type": "string"},
"field": {"type": "string", "enum": ["bid","ask","last","mid"]}
},
"required": ["symbol","field"]
}
}
},
{
"type": "function",
"function": {
"name": "calc_position_size",
"description": "Positionsgröße nach Kelly mit Cap 0.25",
"parameters": {
"type": "object",
"properties": {
"edge": {"type": "number"},
"variance": {"type": "number"},
"capital": {"type": "number"}
},
"required": ["edge","variance","capital"]
}
}
}
]Wichtig: Funktionen, die echte Orders absetzen, gehören nicht in dieses Schema. Der Agent darf Quotes lesen, Sizing rechnen, Reports schreiben. Die Order selbst schickt ein deterministischer Code-Pfad nach menschlicher Freigabe ab. Wer das nicht trennt, baut sich eine Bombe mit Halluzinations-Zündung.
Code-Interpreter für Datenanalyse.
Der Code-Interpreter ist die in meiner Praxis nützlichste eingebaute Funktion. Sie laden ein CSV mit Backtest-Returns hoch, und der Agent kann Python-Code schreiben, ihn in einer Sandbox laufen lassen und Ergebnisse zurückgeben — inklusive Plots.
Konkrete Use-Cases, die bei mir täglich laufen:
- Sharpe-, Sortino-, Calmar-Berechnung über einen Returns-Vektor mit verschiedenen Rolling-Fenstern.
- Drawdown-Profile zeichnen und mit historischen Worst-Cases vergleichen.
- Trade-Logs explorieren: „Welche Stunde des Tages produziert die schlechteste Hit-Rate?“
- Schnelle Monte-Carlo-Simulationen für Risiko-Szenarien.
Die Sandbox ist gegenüber dem Internet abgeschottet, was für vertrauliche Daten beruhigend ist. Aber: was Sie hochladen, liegt auf OpenAI-Servern. Für streng vertrauliche Strategien ist das ein No-Go — dafür gibt es lokale Setups, dazu im nächsten Artikel.
File-Search für eigene Research-Dokumente.
File-Search ist OpenAIs eingebautes RAG. Sie indizieren PDFs, Markdown, CSV, und der Agent kann darin suchen. Für eine Trading-Praxis heißt das: Earnings-Transkripte, Analyst-Reports, eigene Research-Notizen werden durchsuchbar.
Was es gut kann: semantische Suche über einige hundert bis tausend Dokumente. Sie stellen eine Frage in natürlicher Sprache und bekommen die relevanten Passagen mit Quellen-Verweisen zurück.
Was es schlecht kann: präzise Zahlen-Extraktion aus Tabellen, exakte Volltextsuche (dafür ist eine Postgres-FTS oder Elasticsearch immer noch überlegen), Skalierung über zehntausende Dokumente bei niedriger Latenz. Für meine Zwecke — etwa 800 PDFs Research zu beobachteten Sektoren — ist es perfekt.
Zwei Trading-Use-Cases aus meiner Praxis.
Morgenroutine
Um 7:30 läuft bei mir ein Agent, der: (1) für jedes Asset im Watch-Set die letzten 24 h News via Web-Suche aggregiert, (2) gegen mein File-Search-Index der Earnings-Transkripte prüft, ob es Kontext-Treffer gibt, (3) eine kurze Lage-Zusammenfassung pro Asset ausgibt und (4) markiert, welche Positionen meine Aufmerksamkeit brauchen. Output: strukturierter Bericht in mein Notion. Spart 40–60 Minuten pro Morgen.
Backtest-Iteration
Ich habe eine Strategie-Idee, lade meine Daten in eine Session, und der Agent baut den Backtest im Code-Interpreter. Erste Version in 5 Minuten, statt 90. Ich iteriere die Hypothese im Dialog: „Was, wenn wir die Position nur halten, solange der 10-Tage-RV unter 18 liegt?“ — der Agent ändert den Code, läuft neu, zeigt das Ergebnis. Drei Iterationen, 25 Minuten. Statt eines halben Tages.
Kostenrealität.
Ungefähre Pricings (variieren laufend, bitte vor Implementierung verifizieren):
- Kleinere Modelle: günstig pro Token, gut für High-Volume-Workflows mit klarer Struktur.
- Größere Reasoning-Modelle: teurer, aber für anspruchsvolle Reasoning-Aufgaben (komplexe Code-Generation, mehrstufige Recherche) klar überlegen.
- Code-Interpreter: Session-Pricing on top — relevant bei vielen kurzen Sessions, vernachlässigbar bei wenigen langen.
- File-Search: Storage-Kosten pro Monat, plus Such-Kosten pro Query. Bei meinem 800-PDF-Index überschaubar.
Realistisch landen meine OpenAI- und Anthropic-Kosten zusammen im niedrigen vierstelligen Bereich pro Monat — bei einem Volumen, das mir mehrere Stunden pro Tag spart. Die Rechnung geht klar auf.
Meine Praxis: ich nutze beides.
Die Frage „Claude oder GPT“ ist falsch gestellt. Ich nutze beide täglich, je nach Aufgabe:
- Claude für lange, anspruchsvolle Reasoning-Ketten, für Code-Architektur, für Texte, bei denen Ton und Präzision wichtig sind.
- GPT für Workflows mit eingebauten Tools (Code-Interpreter, File-Search), für strukturierte Function-Calling-Pipelines, für schnelle Volumen-Arbeit.
Wer sich auf ein Modell festnagelt, baut Single-Points-of-Failure. Kunden-Setups, die ich begleite, haben in der Regel mindestens zwei API-Anbieter — schon allein, um bei Ausfällen oder Preisänderungen handlungsfähig zu bleiben.
Stand: Mai 2026, überarbeitet Oktober 2026. Angaben zu Produkten, Preisen, Gesetzen und Fristen können sich seitdem geändert haben; maßgeblich sind die aktuellen Angaben der Anbieter und Behörden.
Sie überlegen, einen OpenAI-Agent in Ihren Trading-Workflow zu integrieren? Unverbindlich anfragen — ich zeige Ihnen, welcher Use-Case zuerst Sinn macht. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.