Das Fazit in 5 Sekunden: Die rechen- und denkintensiven Teile, etwa die Rückwärtssuche nach unbekannten Gewinnmustern in Orderbuch- und Ausführungsdaten beim Scalping, konzentriert man auf GPT-6 Astra. Datenbasis, Experimentierumgebung, Fehlerbehebung, Regressionstests, Backtests, Widerlegungsversuche und Job-Steuerung übernimmt dagegen Claude Opus 5.5. Es geht also nicht darum, „die klügste KI für alles zu nehmen“, sondern um zwei Stufen: Astra als teurer Forscher, Opus 5.5 als Bauleiter, der nie stehen bleibt.
1. Überrascht hat mich weniger die „Klugheit“ als das Weitermachen ohne Stopp
In einer langen Wartungssitzung für Software war es nicht so, dass nach dem Beheben des ersten Fehlers Schluss war.
Ein Testfehler, der von unterschiedlichen Laufzeitumgebungen kam, wurde per Dependency Injection (Abhängigkeiten von außen einsetzen) eingegrenzt. Ein alter Test, der eine abgeschaffte Spezifikation prüfte, wurde umgeschrieben. Die Prüflogik, die den Umstieg auf einen gemeinsamen Validator nicht mitgemacht hatte, wurde repariert. Zuletzt fand die KI sogar die fehlende Testdatei (Fixture), die den Produktions-Build blockiert hatte. Nach der Korrektur einzelner Tests ließ sie alle Tests erneut laufen und brachte schließlich auch den echten Build durch.
Aus Sicht eines Menschen ist das mehr wert als eine geniale Antwort auf Anhieb.
Der Engpass bei Agentenarbeit ist nämlich oft diese „Unterbrechungssteuer“ für Menschen:
- Ein Problem entdecken
- Eines beheben
- Einen weiteren Fehler finden
- Mit „Bitte prüfen Sie als Nächstes dies“ anhalten
- Ein Mensch muss mit „Nein, mach einfach weiter“ neu anstoßen
Anthropic positioniert Opus 5.5 als Modell, das lange Coding-Sitzungen, große Codebasen und Agentenarbeit über mehrere Werkzeuge hinweg mit wenig Aufsicht voranbringt. Außerdem nennt das Unternehmen für typische tokenbasierte Arbeitslasten rund 40 % niedrigere Kosten als bei Opus 5.
Wichtig ist hier, den Wert einer KI nicht nur am „IQ“ zu messen, mit dem sie eine schwere Aufgabe löst. In der Praxis zählt, ob Ursachenfindung, Korrektur, Überprüfung, erneute Korrektur und Abschlusskontrolle zusammenhängen.
2. Braucht man Astra dann nicht? Im Gegenteil: Nur für die Suche eingesetzt, lohnt sich der Luxus
GPT-6 Astra ist das Spitzenmodell, das OpenAI für die schwierigsten End-to-End-Aufgaben herausgebracht hat. Der API-Preis liegt bei 10 Dollar für Eingabe und 50 Dollar für Ausgabe pro Million Tokens und damit über den 4 und 20 Dollar von Opus 5.5.
In der Vorstellung von Astra durch OpenAI heißt es zudem, Jane Street habe gegenüber GPT-5.6 Sol eine klare Verbesserung bei der Bewertung des „trading intuition“ (Gespür fürs Trading) festgestellt. Auch in OpenAIs Produkten für Finanzdienstleister gilt Astra als stark in drei Bereichen: Informationsrecherche, Finanzanalyse und Erstellung von Arbeitsergebnissen.
Es wäre also schade, Astra mit Aufgaben wie CSV-Formatierung, Abhängigkeitsfixes, Test-Fixtures oder Dateiumbenennungen zu verbrennen.
An Astra gibt man nur den Teil „Forschung“ ab, in dem
- unklar ist, was überhaupt wirkt
- die Kandidaten für Merkmale (Features) breit gestreut sind
- es viele Kombinationen von Bedingungen gibt
- die Form der richtigen Antwort noch nicht definiert werden kann
- massenhaft gescheiterte Hypothesen verworfen werden müssen
Für Straßenbau braucht man keinen Formel-1-Wagen. Den ruft man erst, wenn die Strecke steht.
3. Bei der Rückwärtssuche im Orderbuch-Scalping geht man nicht von Indikatoren aus, sondern von der späteren Kursbewegung zurück in die Vergangenheit
Üblicherweise entwirft man Strategien so, dass Menschen zuerst Bedingungen aufstellen: „Wenn der RSI niedrig ist, kaufen“ oder „Wenn auf der Kaufseite des Orderbuchs viel liegt, steigt der Kurs vielleicht“.
Die Rückwärtssuche dreht das um.
Zuerst werden maschinell die Situationen herausgezogen, in denen sich der Kurs nach 500 Millisekunden, 1 Sekunde, 3 Sekunden, 5 Sekunden und so weiter über Gebühren und Spread (Differenz zwischen Kauf- und Verkaufskurs) hinaus bewegt hat. Dann geht man zum Orderbuch und zur Reihe der Ausführungen kurz davor zurück und sucht, was ihnen gemeinsam war.
Mögliche Kandidaten sind zum Beispiel:
- die Dicke des Orderbuchs rund um das beste Gebot (best bid) und die beste Verkaufsorder (best ask)
- Depth Imbalance (Ungleichgewicht der Tiefe) über mehrere Preisstufen
- Richtung und Stärke von Market Orders
- Order-Flow-Imbalance (Ungleichgewicht im Orderfluss)
- das Verhältnis von Stornierungen (cancel) zu neuen Orders (add)
- die Geschwindigkeit, mit der das Orderbuch wieder aufgefüllt wird
- Ausweitung und Verengung des Spreads
- die Erholung des Orderbuchs nach Ausführungen
- die Abweichung zwischen Microprice und Mid-Price
- das Volatilitäts-Regime (Marktphase)
- die Tageszeit
- die Reihenfolge von Ereignissen im Bereich von einigen hundert Millisekunden
und so weiter.
Cont, Kukanov und Stoikov haben gezeigt: Kursänderungen in kurzen Zeitfenstern hängen stärker mit dem Order-Flow-Imbalance rund um best bid und best ask zusammen als mit schlichtem Handelsvolumen, und die Wirkung hängt auch von der Markttiefe ab.
Das Orderbuch ist also kein Standbild nach dem Motto „Die Kaufseite ist dick, also geht es hoch“. Es ist eine Ereignisfolge, in der neue Orders, Stornierungen, Market Orders und Auffüllungen zeitlich ablaufen.
Genau hier lohnt es sich, Astra suchen zu lassen.
4. Aber „100 Versuche, der profitabelste gewinnt“ ist vielleicht kein Heiliger Gral, sondern ein Overfitting-Glücksspiel
Die größte Falle der KI-Suche: Je klüger sie wird, desto mehr Strategien kann sie ausprobieren.
Die Arbeit von Bailey und Kollegen behandelt das Problem, dass man mit massenhaft getesteten Backtest-Kandidaten und der Wahl des besten Ergebnisses immer eher eine Strategie wählt, die im Stichprobenzeitraum (in-sample) nur zufällig gut war.
Sobald Astra also 10.000 Bedingungen findet und sagt „Das hier ist die beste“, sollte man eher die Warnstufe anheben.
Bei der Rückwärtssuche braucht es mindestens:
- Suchzeitraum und Endbewertungszeitraum trennen
- sich nicht allein auf zufällige Splits verlassen, die die Zeitreihe zerstören
- nicht immer wieder in denselben Zeitraum zurückgehen und Bedingungen nachjustieren
- die Zahl der getesteten Hypothesen festhalten
- prüfen, ob die Strategie über mehrere Regimes hinweg standhält
- inklusive Gebühren und Spread bewerten
- auf Einsickern zukünftiger Informationen prüfen
Hier macht man Opus 5.5 zum „Gutachter, der die von Astra gefundene Strategie zu Fall bringen soll“.
Astra lässt man entdecken. Opus lässt man zweifeln.
Für eine Forschungsorganisation ist es genau richtig, wenn die beiden sich nicht ganz grün sind.
5. Das Gruseligste beim Orderbuch-Backtest: „Wäre dieser Preis überhaupt ausführbar gewesen?“
Gerade beim Scalping ist es ein Unterschied, ob man einen Preis im Chart sieht oder ob die eigene Order zu diesem Preis durchgeht.
Bei einer Limit Order gibt es die Queue Position (Platz in der Warteschlange). Die Ausführungsquote hängt davon ab, wie viele Orders vor einem stehen, wie viel Gegenorder hereinkommt und ob Orders davor zwischendurch storniert werden.
Eine 2025 in Management Science erschienene Studie behandelt, dass sich die Reihenfolge in der Warteschlange selbst bei fast gleichzeitig abgeschickten Limit Orders durch zufällige Latenz (Verzögerung) ändern kann. Auch eine neuere empirische Studie am Kryptomarkt berichtet: Durch die Zeitdifferenz zwischen dem beobachteten Orderbuch und dem Eintreffen der Order in der Matching Engine (dem Handelsabgleich der Börse) kommt es zu Failure-to-fill, also dazu, dass sichtbare Liquidität in Wirklichkeit nicht zu bekommen ist, was HFT-Backtests (Hochfrequenzhandel) beeinflusst.
Der Backtester muss deshalb mindestens abbilden können:
- fee (Gebühren)
- spread
- slippage (Preisabweichung bei der Ausführung)
- latency
- queue position
- partial fill (Teilausführung)
- cancel latency
- order rejection / failure-to-fill
- adverse selection (ungünstige Auswahl der eigenen Orders)
Kann er das nicht, steigt mit Astras wachsender Suchfähigkeit auch die Gefahr, dass man schnell „schöne Fantasiegewinne“ produziert.
Die KI ist klüger geworden, aber der Ausführungssimulator ist schlampig. Das ist, als würde man einem Ferrari Reifen aus Pappe montieren.
6. Die Rollenverteilung: Opus ist die Fabrik, Astra das Labor
Im Betrieb ist diese Aufteilung leicht verständlich:
| Aufgabe | Hauptverantwortlich |
|---|---|
| Orderbuch- und Ausführungsdaten beschaffen | Opus 5.5 |
| Datenlücken, Zeitsynchronisation, Normalisierung | Opus 5.5 |
| Parquet / DB / Feature Store aufbauen | Opus 5.5 |
| Backtester und Ausführungsmodell implementieren | Opus 5.5 |
| Tests, Regressionsschutz, Logging | Opus 5.5 |
| Zielvariable und Suchraum vorbereiten | Opus 5.5 + Mensch |
| Rückwärtssuche nach unbekannten Merkmalen und Bedingungen | Astra |
| Hypothesen erzeugen, Cluster erkunden | Astra |
| Prüfung auf Look-ahead / Leakage | Opus 5.5 |
| Widerlegung von Overfitting und Regime-Abhängigkeit | Opus 5.5 |
| Kandidaten neu implementieren, massenhaft neu prüfen | Opus 5.5 |
| Nächste Suchaufgabe zuschneiden | Opus 5.5 → Astra |
Anthropic nennt Opus 5.5 ausdrücklich als Daily Driver (Alltagsmodell) für Coding, Agenten, Computer Use und Arbeit über mehrere Apps hinweg.
Astra wiederum bezeichnet OpenAI selbst als Spitzenmodell für komplexes Schlussfolgern, Coding, Computer Use und Forschung.
Gerade weil sich die Fähigkeiten überschneiden, funktioniert ein Aufbau, der das teure Können nur im richtigen Moment ruft, statt alles demjenigen zu geben, der es kann.
7. Opus über Chrome Astra bedienen zu lassen, ist als Prototyp in Ordnung. Für den Produktivbetrieb ist die API sauberer
Man lässt Opus 5.5 mit Browser-Berechtigung die Chat-Oberfläche von Astra öffnen und dann:
- Astra die Suchaufgabe schicken
- Die Fertigstellung prüfen
- Das Ergebnis einsammeln
- Selbst widerlegen
- Bei Bedarf die nächste Suche schicken
Dieser Aufbau, in dem eine KI eine andere KI benutzt, ist als Prototyp ziemlich anschaulich.
Opus 5.5 nennt offiziell Computer Use als Hauptanwendung. Mit einer passenden Steuerung für Browser und Computer kann es also die Schaltzentrale solcher mehrstufigen Arbeit sein.
Sobald der Ablauf aber feststeht und regelmäßig läuft, ist die API in der Regel besser zu handhaben als die Oberfläche.
Der Weg über den Browser bringt mit sich:
- abgelaufene Logins
- Änderungen an der Oberfläche
- Schaltflächenzustände
- die Frage, ob gerade generiert wird oder alles steht
- verpasste Ausgaben
- aufgeblähten Gesprächskontext
- Ausfälle des Browsers selbst
Über die API lassen sich Experiment-ID, Hash der Eingabedaten, Prompt-Version, Ausgabe und Bewertungsergebnisse strukturiert speichern.
Die natürliche Reihenfolge ist deshalb:
Erst über Chrome die menschliche Arbeit eins zu eins automatisieren und den Nutzen prüfen, dann, wenn die Suchschleife steht, auf die API umstellen.
Man muss nicht gleich ein Raumschiff bauen. Erst bindet man eine Rakete an ein Fahrrad und sieht, ob die Richtung stimmt, in die man wirklich will.
8. Das Endziel ist nicht „Astra denken lassen“, sondern Astra nur Probleme zu geben, die sich zum Nachdenken lohnen
Der verschwenderischste Aufbau wäre, Astra riesige Rohdaten und kaputten Code hinzuwerfen und zu sagen:
„Such irgendeine Strategie, die Geld bringt.“
Ein starker Aufbau macht das Gegenteil.
Auf der Seite von Opus 5.5 wird dafür gesorgt, dass
- die Datenqualität gesichert ist
- eine reproduzierbare Experimentierumgebung steht
- eine Such-API bereitsteht
- die Erfolgsbedingungen definiert sind
- das Kostenmodell eingebaut ist
- die Leakage-Prüfung automatisiert ist
- Ergebnisse gespeichert werden
- die von Astra gelieferten Kandidaten unabhängig widerlegt werden
All das ist erledigt.
Erst dann lässt man Astra dort graben, wo „Menschen noch nicht auf Merkmale gekommen sind“.
Der Fluss der Rechenressourcen sieht dann so aus:
Opus 5.5 baut das Fundament → Astra gräbt im Unbekannten → Opus 5.5 versucht, es zu zerstören → nur was überlebt, kommt weiter
Nicht ein einziges Genie-KI-System bekommt alles.
Die Forscher forschen, und die Bauleiter halten die Baustelle am Laufen.
Auch im Zeitalter der KI-Agenten wirkt am Ende am stärksten das Design der Organisation.
