Laut OpenAI-Kundenstory: Codex verkürzt einen Backtest von drei Stunden auf drei bis fünf Minuten

Stellen Sie sich vor, Sie sitzen mit einem Kind im Auto, und alle zwei Minuten kommt von hinten: „Sind wir bald da?“ Die Strecke wird dadurch keinen Meter kürzer. Ihre Nerven aber leiden, und irgendwann besteht die Fahrt zur Hälfte aus Antworten auf diese eine Frage. Dieses Bild passt zur Kundenstory, die OpenAI am Mittwoch, 14. Oktober, über das Start-up Third Moment Research veröffentlicht hat.

Die kurze Version: Laut OpenAI-Kundenstory betreibt Third Moment 10.000 Agenten gleichzeitig, jede autonome Research-Session dauert laut Third Moment 36 bis 48 Stunden. Ein Backtest, der zuvor etwa drei Stunden brauchte, lief nach einem von Codex gefundenen Fix laut OpenAI-Kundenstory nur noch etwa drei bis fünf Minuten. Das ist die Schlagzeile. Spannender finde ich das, was dahinter steckt: Die Agenten haben in der Wartezeit offenbar permanent nachgefragt, ob die Aufgabe fertig ist, und dabei Tokens verbrannt.

Wir bei digital-magazin.de schauen deshalb nicht nur auf die großen Zahlen, sondern auf die Mechanik dahinter: wie das Harness aufgebaut ist, warum Warten teuer wird und was eine Kundenstory eigentlich ist. Spoiler: Sie ist kein unabhängiger Benchmark. Jede Zahl in diesem Text stammt von OpenAI oder Third Moment, und ich werde Sie bei jeder daran erinnern. Dazwischen gibt es ein paar eigene Rechnungen, die ich ausdrücklich als „dm-Rechnung“ markiere.

Was Third Moment laut OpenAI betreibt

Beginnen wir mit dem Rahmen. Third Moment Research ist laut OpenAI ein Start-up aus Nordamerika, das auf API und Codex setzt. Die Idee dahinter: Jedes Unternehmen hat eigene Abläufe, Werkzeuge, Sonderfälle und eine eigene Definition von Erfolg. Gute Agenten sollten genau diese Arbeit richtig gut beherrschen und mit jeder Nutzung besser werden. Third Moment baut dafür laut Kundenstory ein sich selbst verbesserndes KI-System. Es nutzt OpenAIs aktuelle Modelle, um das Verhalten von Agenten zu verstehen, wiederkehrende Schwächen zu erkennen und tausende synthetische Szenarien rund um diese Schwächen zu erzeugen. Mit diesen Szenarien werden die Agenten verbessert, und das Ganze wiederholt sich, sobald neue Probleme auftauchen.

Die Kennzahlen, die OpenAI prominent an den Anfang der Story stellt, lauten (alle laut OpenAI-Kundenstory):

• 10.000 Agenten, die gleichzeitig laufen,
• 36 bis 48 Stunden pro autonomer Research-Session,
• 97 Prozent weniger Backtest-Zeit mit Codex,
• 1 Billion OpenAI-Tokens an einem einzigen Tag.

Ein kleiner Hinweis zur Schreibweise, weil sich hier gern Fehler einschleichen: Im Englischen steht „1 Trillion“, und das ist eine Billion (eine Eins mit zwölf Nullen). Wer „Trillion“ ungeprüft als „Trillion“ ins Deutsche übernimmt, macht aus der Zahl das Millionenfache einer Billion. Die Quelle meint die Billion.

Und was ist mit „36 Stunden Fokus“, wie es in manchen Zusammenfassungen kursiert? Die Quelle sagt etwas anderes: Sie nennt Untersuchungen, die 36 bis 48 Stunden dauern. Das ist die Spanne pro autonomer Session, kein Mindestfokus und kein Garantiewert. Ich bleibe daher bei „36 bis 48 Stunden“, und zwar laut Third Moment.

Welche Modelle sind im Spiel? Laut Kundenstory unterstützen Codex, GPT‑6 Astra, GPT‑6 Sol und GPT‑6.1 Sol die Research- und Rechenarbeit des Systems. Die Modelle der GPT‑6-Reihe liefern dabei „das Reasoning“, also das Denken, während das Codex-Harness den Agenten die Werkzeuge zum Handeln gibt. Das Harness ist die Schicht, die Pläne erstellen, Ziele setzen, Subagenten starten und den Kontext verdichten lässt, wenn die Arbeit länger dauert. Merken Sie sich diese Aufgabenteilung, denn sie ist der Schlüssel zum Rest der Geschichte: Das Modell denkt, das Harness organisiert.

Ein Wort zum Anwendungsfeld, bevor Missverständnisse entstehen. Third Moment startet laut OpenAI in der quantitativen Finanzanalyse, weil dort der Erfolg klar messbar ist. Das gibt den Forschenden einen konkreten Raum, um zu studieren, wie Agenten arbeiten und wo sie scheitern. Es geht in diesem Artikel ausdrücklich nicht um Anlagen, Handelsideen oder Renditen. Die Kundenstory nennt dazu keine Zahl, und ich erfinde keine.

Die Nerd-Frage lautet also nicht „Was bringt das an der Börse?“, sondern „Wie hält man tausende Agenten tagelang arbeitsfähig?“. Dazu gehört die unscheinbarste Zutat überhaupt: Geduld, oder besser gesagt, ein Weg, Warten nicht zu bezahlen.

Drei Stunden Warten

Jetzt der konkrete Fall, um den sich die Überschrift der Kundenstory dreht. Third Moment hat laut OpenAI Codex mit GPT‑5.6 eingesetzt – laut Text das „neueste GPT-Modell zu diesem Zeitpunkt“ (Übersetzung). Codex analysierte damit tausende aufgezeichnete Simulationsverläufe, also die Aktionen der Agenten und die Antworten der Umgebung, zusammen mit Zeitstempeln und dem Quellcode.

Dabei fiel etwas auf. Ein Backtest einer Handelsstrategie über ein Jahr Order-Level-Daten des US-Aktienmarkts dauerte laut Kundenstory mehrere Stunden. Während die Agenten warteten, fragten sie wiederholt ab, ob der Lauf fertig ist. Das kostete Tokens und füllte ihren Kontext mit Statusmeldungen.

Zwei Probleme in einem. Das erste ist offensichtlich: Tokens kosten Ressourcen, und ein Agent, der alle paar Sekunden „fertig?“ fragt, verbraucht welche, ohne irgendetwas zu erreichen. Das zweite ist subtiler und aus meiner Sicht das gemeinere. Jede Statusabfrage und jede Antwort darauf landet im Kontextfenster. Der Agent trägt also immer mehr Ballast mit sich herum, während die eigentliche Aufgabe, die Forschungsfrage, zwischen hunderten Zeilen „läuft noch“ verschwindet. In der Kundenstory heißt das „context pollution“, Kontextverschmutzung.

Zurück zum Auto: Das Kind, das alle zwei Minuten fragt, ist nicht dumm. Es hat nur keine andere Möglichkeit, mit der Wartezeit umzugehen. Ein Agent, der keinen Weg kennt, sich schlafen zu legen und geweckt zu werden, wenn das Ergebnis da ist, pollt eben. Ob Third Moment das Polling selbst umgebaut hat, steht nicht in der Quelle. Dort steht nur, dass Codex den Backtest selbst schneller gemacht hat. Das ist eine andere Stellschraube, und sie ist elegant: Wer den Wartegrund beseitigt, braucht das Warten nicht zu verwalten.

Zum Thema Kontext hat digital-magazin.de bereits einen ausführlichen Text: Wie Context Engineering KI-Kosten senkt. Er erklärt, warum ein aufgeräumter Kontext nicht nur Tokens spart, sondern auch die Qualität der Antworten stabilisiert. Die Third-Moment-Geschichte ist dafür ein praktisches Anschauungsbeispiel, auch wenn die Kundenstory selbst keine Kostenzahlen nennt.

Ehrlich gesagt, das ist der Teil der Geschichte, den ich am sympathischsten finde. Kein Wundermodell, kein Zauberwort. Ein Profil, ein Blick auf Zeitstempel, und die Erkenntnis: Hier steht jemand die ganze Zeit im Flur und klopft an die Tür.

Caching und Memory-Packing mit Codex

Was hat Codex dann konkret getan? Laut Kundenstory profilierte es zunächst den Backtest und analysierte dessen Eingaben und Nutzung. Danach identifizierte es zwei Maßnahmen: eine Caching-Optimierung und eine Memory-Packing-Technik. Es experimentierte mit Lösungen und spielte den Fix in die Produktion. Die Dauer sank laut OpenAI-Kundenstory „von etwa 3 Stunden auf etwa 3 bis 5 Minuten“ (Übersetzung). Das senkte nach Angabe der Story den Tokenverbrauch und die Kontextverschmutzung und gab den Agenten mehr Token-Budget für weitere Experimente frei.

Für Lesende, die mit den Begriffen nicht täglich arbeiten, hier zwei Alltagsvergleiche. Beides sind meine Erklärungen, nicht Aussagen der Quelle, und was genau Third Moment im Code geändert hat, verrät die Story nicht.

Caching heißt: Was schon einmal berechnet oder geladen wurde, wird zwischengespeichert, statt es jedes Mal neu zu holen. Stellen Sie sich eine Küche vor, in der jemand für jedes Gericht die Zwiebeln neu schält, obwohl ein Beutel geschälter Zwiebeln im Kühlschrank liegt. Memory-Packing bedeutet, Daten kompakter im Arbeitsspeicher abzulegen. Das Bild dazu: Sie packen den Koffer neu, damit alles hineinpasst, ohne dass Sie zweimal zum Auto laufen müssen. Je weniger Daten bewegt werden müssen, desto schneller geht es, besonders bei Datenmengen, die ein Jahr Order-Level-Daten umfassen.

Entscheidend ist aber der Mechanismus, nicht die Technik. Die Kundenstory beschreibt einen Kreis: Agenten arbeiten, ihre Verläufe werden aufgezeichnet, ein Codex-Lauf mit GPT‑5.6 analysiert diese Aufzeichnungen, findet einen Engpass in der Umgebung und repariert ihn. Danach arbeiten die Agenten in einer besseren Umgebung weiter. Das Werkzeug wird also nicht nur benutzt, es verbessert auch das Terrain, auf dem alle anderen laufen. Wie ein Handwerker, der nach Feierabend die Werkstatt umräumt, damit am nächsten Arbeitstag alles schneller geht.

Jetzt zu den Zahlen, und hier lohnt sich Sorgfalt. Die Kundenstory enthält zwei Angaben, die leicht durcheinandergeraten:

• die Kachel „97 % Reduktion der Backtest-Zeit mit Codex“ in der Kennzahlen-Box,
• die Textstelle „von etwa 3 Stunden auf etwa 3 bis 5 Minuten“.

Beide stammen aus derselben Kundenstory. Ob die 97 Prozent genau diesen einen Backtest meinen oder einen Durchschnitt über mehrere Fälle, sagt die Quelle nicht. Auch die Messmethode nennt sie nicht. Ich rechne deshalb nur nach, ob die Angaben zueinander passen, und behaupte nichts darüber hinaus.

dm-Rechnung, Rechenweg: Drei Stunden sind 180 Minuten. 97 Prozent Reduktion bedeuten, dass 3 Prozent übrig bleiben, also 180 × 0,03 = 5,4 Minuten. Das liegt am oberen Rand der genannten „3 bis 5 Minuten“. Die beiden Angaben sind damit rechnerisch miteinander vereinbar. Das beweist nicht, dass sie dieselbe Messung beschreiben, es zeigt nur, dass sich beide nicht widersprechen.

Zweite dm-Rechnung: Nimmt man die Mitte der Spanne, also 4 Minuten, ergibt 180 ÷ 4 = 45. Rechnerisch ist der Lauf in diesem Beispiel also etwa 45-mal schneller. Wohlgemerkt: Das ist unsere Rechnung mit den ungefähren Werten der Kundenstory (Herstellerangaben), kein gemessener Wert und keine Aussage von OpenAI oder Third Moment. Bei „approximately“-Angaben auf beiden Seiten ist die Zahl eher eine Größenordnung als eine Präzisionsangabe.

Und der Haken, den ich auch selbstironisch zugeben kann: Der Vergleich „3 Stunden gegen 3 Minuten“ klingt immer beeindruckend. Wer schon einmal eine Abfrage mit einem fehlenden Index beschleunigt hat, weiß aber, dass sich solche Faktoren oft leicht einstellen, wenn ein Engpass wirklich dumm war. Das ist keine Kritik an Third Moment, sondern eine Einordnung: Der große Hebel war hier kein klügeres Modell, sondern das Aufspüren einer Stelle, an der etwas Vermeidbares passierte.

Wie nützlich das für den ganzen Betrieb ist, zeigt eine weitere Zahl, wieder laut OpenAI-Kundenstory: Third Moment verbrauchte an einem einzigen Tag 1 Billion OpenAI-Tokens. Bei solchen Mengen ist jede unnötige Statusabfrage eine winzige Verschwendung, die sich mit tausenden Agenten multipliziert. Ob und wie viel die Optimierung am Gesamtverbrauch ausgemacht hat, nennt die Quelle nicht, und Kosten gibt sie ebenfalls nirgends an. Wer die Story als Preisbeleg liest, liest zu viel hinein.

Die dritte dm-Rechnung ist eine Gedankenübung, um Größenordnungen greifbar zu machen: 10.000 Agenten × 36 Stunden = 360.000 Agentenstunden. Das gilt nur, falls alle 10.000 Agenten die volle Mindestdauer von 36 Stunden laufen würden. Die Quelle sagt das ausdrücklich nicht. Sie nennt 10.000 gleichzeitig laufende Agenten und separat 36 bis 48 Stunden pro Session. Dass beides gleichzeitig und vollständig zusammenfällt, ist eine Annahme, keine Angabe. Die Rechnung dient nur der Vorstellung, wie viel „Wartezeit“ sich in so einem Betrieb anstauen könnte, wenn jeder Agent nur ein bisschen zu oft nachfragt.

Das Harness über dem Harness

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptClose-up of a monitor with an abstract backtest chart of a trading strategy finishing quickly, an hourglass on the desk with almost no sand fallen, developer hands at a keyboard. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Kommen wir zur Architektur, dem Teil, der mich als Bastler wirklich fesselt. Laut Kundenstory läuft für die quantitative Forschung das Standard-Codex-Harness in einer Docker-Umgebung. Jeder Agent bekommt darin ein Terabyte an Daten, Dokumentation und ein Research-Repository mit Modulen für Feature Engineering, GPU-gestütztes Modelltraining, Handelsstrategien und Simulation. Die Hardware dahinter nennt die Quelle nicht.

Dockerisiert heißt: Jeder Agent arbeitet in einer abgeschlossenen Box, in der er Werkzeuge und Daten findet, ohne die Außenwelt anzufassen. Eine Werkbank mit fest verschraubtem Werkzeug, nur eben digital. Das Harness stellt laut Story die Handgriffe bereit: planen, Ziele setzen, Subagenten starten, den Kontext verdichten. Ein Agent kann also einen Teil seiner Arbeit an Unter-Agenten delegieren und seinen eigenen Speicher aufräumen, wenn er voll wird. Gerade bei Sessions von 36 bis 48 Stunden (laut Third Moment) ist das Verdichten des Kontexts keine Spielerei, sondern Pflicht, sonst läuft das Gedächtnis voll.

Dann kommt die Schicht, die den Titel dieses Abschnitts erklärt. Third Moment kennt offenbar ein bekanntes Problem: Agenten hören manchmal auf, bevor die Aufgabe erledigt ist. Die Lösung laut Kundenstory: Codex wird als Subagent innerhalb eines äußeren Harness behandelt, das von GPT‑6 Sol oder GPT‑6.1 Sol angetrieben wird. Wenn eine Aufgabe unvollendet bleibt, prüft dieses äußere Harness den Verlauf und entscheidet, ob es erneut versucht, den Job beendet oder an Menschen zur Prüfung eskaliert.

Stellen Sie sich einen Schichtleiter vor, der nicht selbst am Band steht, sondern durch die Halle geht. Bleibt ein Arbeitsplatz verwaist, schaut er sich an, was dort passiert ist, und entscheidet dann: noch einmal anfangen lassen, Schluss machen oder die Meisterin holen. Dieses Bild ist meine Veranschaulichung, die Quelle beschreibt nur die drei Optionen. Wie das äußere Harness den Verlauf bewertet, wie lange es wartet oder welche Schwellen es nutzt, steht nirgends.

Das Muster halte ich für lehrreich: Die Intelligenz sitzt nicht nur im einzelnen Agenten, sondern auch in der Aufsicht über viele Agenten. Wer 10.000 Läufe gleichzeitig am Laufen hält, kann nicht jeden Abbruch von Hand nachverfolgen. Eine automatische Entscheidungsschicht, die im Zweifel an Menschen eskaliert, ist dann keine Kür, sondern Betriebsnotwendigkeit. Das ist meine Einschätzung, keine Aussage der Kundenstory.

Interessant ist auch die Modellwahl. Laut Jeffrey Yan, Mitgründer von Third Moment, ist GPT‑6.1 Sol „derzeit unser meistgenutztes Modell, wegen seiner Token-Effizienz“. Es erledigt Aufgaben mit den wenigsten Tokens, bei einer Leistung, die laut Yan der von GPT‑6 Astra ähnelt (Übersetzung, Einschätzung von Third Moment). Wer sich für dasselbe Modell im Entwickleralltag interessiert: digital-magazin.de hat darüber berichtet, wie GPT-6.1 Sol in Copilot auftaucht. Die Third-Moment-Story ist eine andere Nutzung, aber dasselbe Modell.

Der Mitgründer Adam Khakhar sagt es so: „In einer einzelnen Session kann GPT-6.1 Sol einen zusammenhängenden Faden computergestützter Forschung über Tage an Rechenzeit halten, ohne den Faden zu verlieren“ (Übersetzung; Aussage eines Mitgründers im Kundenstory-Zitat). Bei „ohne den Faden zu verlieren“ lohnt sich Skepsis in der Sache, nicht gegen die Person. Das ist eine Selbsteinschätzung, kein Messwert.

Dazu passt die Beschreibung der Modellgenerationen. Laut Adam konnten Modelle vor GPT‑5.5 nur Experimente ausführen, die ein Mensch vorgab. Mit GPT‑5.5 und GPT‑5.6 im Codex-Harness konnten sie Ergebnisse nutzen, um Folgeexperimente zu entwerfen. Mit GPT‑6 Astra, GPT‑6 Sol und GPT‑6.1 Sol können Agenten laut Adam den Ursachen über hunderte parallel laufende Experimente mit Subagenten auf den Grund gehen. In einer Session habe GPT‑6.1 Sol außerdem die Wirkung nicht angezeigter Trades an einer Börse identifiziert, bei der sie einen unerwartet großen Anteil am Volumen ausmachten. „Ein nicht offensichtliches Ergebnis, das unser Forschungsteam zunächst nicht bedacht hatte“, sagt Adam (Übersetzung). Wie gut das Ergebnis ist, kann ich nicht prüfen. Interessant ist, dass es die Story als Beleg für unerwartete Forschungsrichtungen anführt.

Ein Hinweis für alle, die jetzt an Gewinnversprechen denken: Die Agenten arbeiten laut Kundenstory daran, ein von Third Moments Ingenieurinnen und Ingenieuren gebautes Basis-Handelssystem zu verbessern. Sie testen Strategien auf historischen Daten, bewerten, ob eine Verbesserung bedeutsam oder nur Rauschen ist, und wählen anhand jedes Ergebnisses das nächste Experiment. Laut Adam hat ihre Arbeit das Basissystem verbessert, ohne dass die Story irgendeine Zahl dazu nennt. Ich greife das nicht auf und leite daraus nichts ab. Eine Anlageempfehlung ist das ohnehin nicht.

Dann gibt es noch eine kleine Aufgabenteilung bei den Modellen, die ich nett finde. Laut Kundenstory vergleicht Third Moment Modelle in den Bereichen Optimierung, maschinelles Lernen und quantitative Forschung, jeweils auf höchster Reasoning-Stufe, und prüft, wie gut sie sich in Repositories bewegen, effizienten Code schreiben und eine Untersuchung durchhalten. Aktuell kommt GPT‑6 Luna in die Tests. Bei einem Benchmark sollen Agenten die Aktualisierungslatenz eines Live-Scoreboard-Dienstes senken, ohne dessen Ausgaben zu verändern. Gemessen wird der Speedup als Durchschnittslaufzeit einer von Fachleuten gebauten Lösung geteilt durch die des Modells, auf derselben Hardware und mit korrektem Ergebnis. GPT‑6 Astra lieferte laut Adam den größten Speedup. Konkrete Zahlen dazu nennt die Story nicht.

Für gezielte Aufgaben, etwa Prüfungen auf bestimmte Sicherheitslücken im Simulationssystem, nutzt das Team laut Story effizientere Modelle wie GPT‑5.6 Terra. Für tiefe Recherche hält Adam stärkeres Reasoning auch bei höheren Kosten für gerechtfertigt: „Im Bereich der quantitativen Finanzen ist der Wert, ein interessantes Signal zu finden, extrem hoch“ (Übersetzung). Das ist die Sicht eines Mitgründers, keine allgemeine Regel, und sie sagt nichts über tatsächliche Kosten.

Wer sich das Codex-Harness selbst ansehen will, findet den Code im öffentlichen GitHub-Repository von OpenAI Codex. Ich behaupte damit nicht, dass Third Moment genau diese Variante in genau dieser Konfiguration nutzt. Die Story spricht vom „Default Codex Harness“, mehr nicht.

Daybreak vor dem Start

Der Abschnitt der Story, der mir als Nerd fast am meisten zu denken gibt, ist der kürzeste. Mit 10.000 autonom laufenden Agenten muss Third Moment laut OpenAI die Sicherheit seiner Forschungsumgebungen in großem Maßstab testen. Das Team nutzt dafür die Cybersecurity-Plattform Daybreak und automatisiert die Tests, bevor Simulationen starten.

Was wird geprüft? Laut Kundenstory untersuchen die Tests, ob ein Agent aus seiner Forschungsumgebung ausbrechen und ins weitere Netzwerk gelangen könnte. Adam Khakhar sagt: „Mit Daybreak können wir Agenten selbst Penetrationstests an der Simulation durchführen lassen und die Infrastruktur und deren Sicherheit prüfen“ (Übersetzung). Und: „Ohne Daybreak könnten wir das nicht autonom in diesem Maßstab testen“ (Übersetzung). Wie diese Tests im Einzelnen ablaufen, steht nicht in der Quelle, und ich werde dazu nichts ausmalen. Das gehört nicht in einen Artikel, und es wäre auch spekulativ.

Warum ist die Aussage trotzdem wichtig? Weil sie das Problem benennt, das mit jeder Autonomie-Stufe wächst. Ein Agent, der 36 bis 48 Stunden (laut Third Moment) alleine arbeitet, hat Zeit, Dinge zu tun, die niemand beobachtet. Eine Sandbox hilft nur, wenn sie dicht ist, und dass sie dicht ist, muss jemand vor dem Start prüfen. Dass Third Moment diese Prüfung vor Simulationsbeginn ansiedelt und automatisiert, ist aus Betriebssicht plausibel. Ob sie wirksam ist, kann ich nicht beurteilen, denn die Quelle nennt weder Befunde noch Fehlerraten.

Wer sich für das Ausbruch-Thema aus der Entwicklerperspektive interessiert, dem empfehle ich unseren Text zu VerCellBreak und dem Sandbox-Egress. Dort geht es um ausgehenden Datenverkehr aus Sandboxes, ein Thema, das die Daybreak-Prüfung („Zugriff auf das weitere Netzwerk“) von der anderen Seite betrachtet. Gleich vorweg: Beide Geschichten sind unabhängig voneinander. Ich verbinde sie nur thematisch.

Und wenn Agenten sich auf lange Strecken selbst überlassen bleiben, stellt sich auch die Frage nach der Fehlerquote. Ein verwandtes Stück bei uns dreht sich um die Fehlerquote bei Computer-Use-Agenten. Auch hier gilt: eigenes Thema, andere Quelle, keine Vermischung. Aber wer 10.000 Agenten betreibt, hat vermutlich ein starkes Interesse daran, dass Fehler nicht unbemerkt durchrutschen, und genau dafür steht ja das äußere Harness mit seiner Eskalation an Menschen.

Was die Kundenstory nicht misst

Jetzt zur unbequemen Hälfte. Eine Kundenstory ist eine Erzählung des Anbieters über einen Kunden, in der der Kunde vorkommt und zitiert wird. Sie erscheint auf der Website des Anbieters, bei OpenAI mit dem Etikett „Customer Story“ samt Firmengröße, Region, Branche und eingesetzten Produkten. Das ist ein legitimes Format, es ist nur kein unabhängiger Test. Es gibt keine Kontrollgruppe, keinen externen Prüfer und keine veröffentlichten Rohdaten.

Was in der Story nicht steht, ist deshalb genauso aufschlussreich wie das, was drinsteht. Die folgende Liste ist unsere Einordnung (dm), keine Angabe der Quelle:

• Die Messmethode der 97 Prozent. Es bleibt offen, ob es sich um einen Einzelfall, einen Durchschnitt oder einen Bestwert handelt.
• Kosten. Weder Tokenpreise noch Gesamtausgaben noch Einsparungen werden genannt.
• Hardware. Das Terabyte Daten wird erwähnt, welche Rechner dahinter stehen, nicht.
• Rendite. Auch der Satz, das Basis-Handelssystem sei verbessert worden, kommt ohne Zahl aus.
• Ein unabhängiger Vergleich, etwa mit anderen Modellen oder Harnesses.

Das heißt nicht, dass die Angaben falsch wären. Es heißt, dass Sie sie als das lesen sollten, was sie sind: Herstellerangaben und Aussagen des Kunden, die miteinander konsistent sind, aber nicht überprüft. Meine Faustregel für solche Texte: Ich glaube der Mechanik mehr als der Zahl. Dass ein Agent, der auf einen Dreistunden-Job wartet, Tokens mit Statusabfragen verschwendet, ist einleuchtend. Ob der Fix am Ende 45-mal oder 30-mal schneller war, ist mir fast egal, solange die Richtung stimmt.

Ein zweiter Punkt: Die Story ist auch eine Verkaufsgeschichte für die neuen Modelle. Sie nennt GPT‑6 Astra, GPT‑6 Sol, GPT‑6.1 Sol, Codex und Daybreak im Untertitel, im Fließtext, in den Zitaten. Das ist normal, und die Zitate der Mitgründer klingen wie das, was man in solchen Texten erwartet. Ich lese zum Beispiel „GPT-6.1 Sol ist derzeit unser meistgenutztes Modell“ als Angabe von Jeffrey Yan über Third Moments eigene Nutzung. Als Aussage über den Markt oder über Qualität taugt sie nicht.

Dazu kommt der Ausblick. Third Moment plant laut Kundenstory, von einzelnen Untersuchungen zu hunderttausenden zusammenarbeitenden Subagenten zu wachsen. Die Roadmap sieht Billionen von Tokens vor, die Ketten aus Dutzenden voneinander abhängiger Experimente tragen, mit dem Ziel, Agenten autonom zu verbessern, sobald neue Herausforderungen auftreten. Das ist ein Plan, kein Ist-Zustand. Die 10.000 Agenten sind das, was laut Story läuft, die hunderttausend sind das, was kommen soll. Beim Lesen von Roadmaps gilt dieselbe Vorsicht wie bei Pressemitteilungen: Zukunft ist kein Beleg.

Interessant finde ich dennoch die Anwendungsbeispiele, die die Story für die Zukunft skizziert. Für einen Einzelhändler könnten es bessere Lieferkettenentscheidungen sein, wenn Bestand knapp ist oder ein Zulieferer sich verspätet. Für ein Engineering-Team könnte es das Aufspüren von Performance-Engpässen in einer großen Codebasis sein. Für ein dokumentenlastiges Unternehmen könnte es heißen, Stellen zu finden, an denen Zusagen in einem Dokument nicht zu den Ergebnissen in einem anderen passen. Alles Möglichkeiten, die die Story als Ambition beschreibt, nicht als erreichte Ergebnisse.

Und was ist mit dem Satz, der am Ende der Story steht? Adam Khakhar sagt: „Menschen können in eine viel hebelstärkere Position kommen, in der sie darüber nachdenken, wie man Forschung betreibt und die Forschung selbst optimiert, statt die Forschung tatsächlich selbst zu machen“ (Übersetzung). Schöner Gedanke, und ich verstehe, warum er sich gut liest. Mich beschäftigt eher die Gegenfrage: Wer prüft die Agenten, wenn Menschen nur noch die Forschungsmethode überdenken? Das äußere Harness eskaliert im Zweifel an Menschen, laut Story. Wie oft das passiert, bleibt offen.

Was bleibt also? Für mich eine einfache Erkenntnis mit Bastlerherz. Wer Agenten im großen Stil laufen lässt, sollte seine Aufmerksamkeit nicht nur auf das Modell richten, sondern auf alles, was um das Modell herum Zeit und Tokens frisst. Ein Backtest, der drei Stunden dauert, ist ein Wartezimmer, und in Wartezimmern wird gefragt, wie lange es noch dauert. Die Story erzählt, wie das Wartezimmer kleiner wurde. Wie groß es vorher wirklich war und wie klein es jetzt ist, wissen wir nur aus Herstellerhand. Das ist mein Maßstab für die nächsten Kundenstories: Ich lese sie gern, ich nehme die Mechanik mit, und ich lasse die Zahlen im Anführungszeichen stehen.

Häufige Fragen

Wie viele Agenten betreibt Third Moment laut OpenAI-Kundenstory?

Laut OpenAI-Kundenstory vom 14. Oktober laufen bei Third Moment Research 10.000 Agenten gleichzeitig. Die autonomen Research-Sessions dauern laut Third Moment 36 bis 48 Stunden. Daraus lässt sich nicht ableiten, dass jeder einzelne Agent die volle Zeit läuft, denn die Quelle verknüpft beide Angaben nicht ausdrücklich.

Wie viel schneller wurde der Backtest laut Kundenstory?

Laut OpenAI-Kundenstory sank die Dauer eines Backtests über ein Jahr Order-Level-Daten des US-Aktienmarkts von etwa 3 Stunden auf etwa 3 bis 5 Minuten. In der Kennzahlen-Box nennt die Story außerdem 97 Prozent weniger Backtest-Zeit mit Codex. Zur Messmethode macht die Quelle keine Angaben. Unsere Rechnung mit der Mitte der Spanne (3 Stunden geteilt durch 4 Minuten) ergibt etwa das 45-Fache; das ist eine dm-Rechnung und keine Angabe der Quelle.

Welches Modell hat den Engpass gefunden?

Laut Kundenstory hat Third Moment Codex mit GPT‑5.6 eingesetzt, dem damals neuesten GPT-Modell, um aufgezeichnete Simulationsverläufe zu analysieren. Die GPT‑6-Modelle (Astra, Sol, 6.1 Sol) liefern laut Story das Reasoning für die Forschungsarbeit, und das äußere Harness läuft auf GPT‑6 Sol oder GPT‑6.1 Sol.

Was prüft Daybreak laut Third Moment?

Laut Third Moment testet Daybreak vor dem Start der Simulationen, ob ein Agent aus seiner Forschungsumgebung ausbrechen und auf das weitere Netzwerk zugreifen könnte. Die Tests laufen laut Story automatisiert und in großem Maßstab. Details zum Vorgehen nennt die Quelle nicht.