OpenAI hat Codex „in einzelne Bestandteile aufgeteilt und separat verkauft“
OpenAI hat gestern auf einen Schlag vier große Maßnahmen ergriffen.
Agents API, GPT-Live-1 API, Data Agent, ChatGPT for Financial Services – an einem einzigen Tag überspannen sie vier Produktlinien in den Bereichen Agenten, Sprache, Daten und Finanzwesen, von denen jede es wert ist, separat ausführlich erörtert zu werden.
Aber unter diesen vier Maßnahmen ist das Agents API wahrscheinlich das am meisten beachtenswerte.
Denn dieses Mal hat OpenAI Codex „zerlegt und einzeln angeboten“.
Die Fähigkeiten, die ursprünglich hinter Codex verborgen waren und dafür verantwortlich sind, dass Agenten kontinuierlich arbeiten, Tools aufrufen, Kontexte verwalten und mehrere Agenten zusammenwirken lassen, wurden herausgelöst, als Cloud-API verpackt und allen Entwicklern zur Nutzung bereitgestellt.
01 Codex als Service?
Eigentlich hat OpenAI schon lange damit begonnen, Codex zu zerlegen.
Bereits im April 2025, kurz nach der Veröffentlichung von o3 und o4-mini, hat OpenAI Codex CLI als Open-Source-Code veröffentlicht. Es ähnelt der OpenAI-eigenen Version von Claude Code und wird direkt im lokalen Terminal ausgeführt. Wie Agenten laufen und wie sie Tools aufrufen, ist vollständig auf GitHub offengelegt. Wenn Sie bereit sind, sich damit auseinanderzusetzen, können Sie es selbst herunterladen, anpassen und betreiben.
Aber zu diesem Zeitpunkt wurden die Funktionen lediglich bereitgestellt, ob und wie Sie sie nutzen, lag ganz in Ihrer Hand.
Einen Monat später wurde die Cloud-Version von Codex, also das Produkt, das wir heute kennen, offiziell eingeführt. Nutzer können ihre Code-Repositorys an sie übergeben, wobei eine Aufgabe einer unabhängigen Cloud-Sandbox entspricht. Codex kann selbstständig Code ändern, Tests durchführen, Fehler beheben und gleichzeitig mehrere Aufgaben bearbeiten.
Einige Monate später, im Oktober 2025, veröffentlichte OpenAI das Codex SDK.
Einfach ausgedrückt ist das SDK ein Toolkit für Entwickler, das es ermöglicht, Codex nicht nur als eigenständiges Produkt zu verwenden, sondern auch in Anwendungen Dritter zu integrieren. Das SDK erlaubt es Entwicklern, mit wenigen Zeilen TypeScript-Code denselben Agenten zu starten, der Codex CLI antreibt, strukturierte Ausgaben zu erhalten, den Aufgabenstatus beizubehalten und die Ausführung nach einer Pause fortzusetzen.
Allerdings eignet sich das SDK hauptsächlich für den Aufruf von Codex in Programmen und hat die vollständigen Interaktionsfähigkeiten von Codex noch nicht vollständig freigegeben. Es eignet sich sehr gut für Backend-Workflows, Automatisierungsskripte und serverseitige Programme. Wenn Sie jedoch einen vollständigen Client wie die Codex IDE erstellen möchten, gibt es noch einige Schwierigkeiten.
Daher veröffentlichte OpenAI im Februar 2026 offiziell den Codex App Server und erläuterte zum ersten Mal systematisch den Harness-Mechanismus in Codex.
OpenAI hat klar erklärt, dass Codex Web, CLI, IDE-Erweiterung und Mac App zwar wie unterschiedliche Produkte aussehen, aber im Hintergrund alle denselben Codex Harness ausführen – die Ebene, die für die Agenten-Schleife, Threads, Tool-Ausführung, Authentifizierung und Zustandsverwaltung verantwortlich ist.
Der App Server fügt diesem gesamten Harness eine bidirektionale JSON-RPC-Schnittstelle hinzu. JetBrains, Xcode oder andere Clients müssen keine eigene Agenten-Schleife neu entwickeln, sondern können den App Server direkt starten, um den vollständigen Codex zu steuern.
Mit dem App Server können andere Produkte direkt an den vollständigen Codex Harness angeschlossen werden.
Aber bis zu diesem Schritt gab es noch ein letztes ungelöstes Problem.
Das SDK steuert den lokalen Codex-Agenten, und der App Server selbst ist ebenfalls ein permanenter Prozess, der von Entwicklern gestartet und aufrechterhalten werden muss. Obwohl das Problem der Integration von Codex in Produkte gelöst wurde, ist es immer noch schwierig, es stabil als Onlinedienst zu betreiben.
Um ein konkretes Beispiel zu nennen: Wenn Sie mit dem App Server eine eigene Coding-Agent-Website erstellen und das Frontend bereits an Codex angeschlossen haben, müssen Sie alle anschließenden umfangreichen Betriebs- und Infrastrukturprobleme nach dem Klick des Nutzers auf „Dieses Repository reparieren“ noch selbst lösen.
Dann, am 19. August (US-Zeit), hat OpenAI die im vergangenen Jahr schrittweise freigegebenen Komponenten CLI, SDK und App Server in die Plattform-Narration des „offenen Codex Harness“ integriert und Codex explizit von einem einzelnen Produkt zu einer Plattform aufgewertet.
Anschließend, am 10. September (US-Zeit), also gestern, wurde das Agents API offiziell zur öffentlichen Testphase freigegeben.
Dieses Mal müssen Entwickler dem API nur vier Dinge mitteilen – Aufgabe, Modell, Tools und Ausführungsumgebung – um direkt einen Agenten zu erstellen. Der Codex Harness, der für die Kontextkomprimierung bei langen Sitzungen, die Tool-Steuerung und die Zusammenarbeit von Subagenten verantwortlich ist, wird von OpenAI selbst gehostet und gewartet.
Sogar die Maschinen, auf denen der Agent tatsächlich arbeitet, können selbst ausgewählt werden: Ob Sie die Sandbox von OpenAI, Ihre eigene Infrastruktur oder Drittumgebungen wie Cloudflare, E2B oder Modal nutzen, ist ganz Ihnen überlassen. Der Harness wird von OpenAI bereitgestellt, die Ausführungsumgebung wird von den Entwicklern festgelegt.
Die offizielle Angabe ist eindeutig: Für das Agents API selbst fallen keine zusätzlichen Gebühren an. Das bedeutet, dass für Fähigkeiten wie Harness-Hosting und Verwaltung langer Sitzungen keine zusätzliche Plattformgebühr für Agenten erhoben wird.
Entwickler zahlen nach den tatsächlich genutzten Modell-Tokens und Tools; bei Nutzung der gehosteten Sandbox von OpenAI werden die Rechenressourcen separat berechnet.
Wenn man diesen mehr als einjährigen Verlauf zusammenfasst, hat OpenAI stets dasselbe Ziel verfolgt: Codex schrittweise von einem konkreten Produkt zu wiederverwendbaren Fähigkeiten zu zerlegen und gleichzeitig den Aufwand für Entwickler stetig zu senken.
Wenn man dieser Produktlinie einen Namen geben möchte, ähnelt sie stark dem SaaS-Konzept früherer Jahre – nur dass hier nicht Software als Service bereitgestellt wird, sondern Codex.
Codex as a Service.
02 Der Harness wird ebenfalls verzweigt
Nicht nur OpenAI hat es auf den Harness abgesehen.
Bei der Veröffentlichung von DeepSeek Harness (im Folgenden als DSH abgekürzt) wurde eine sehr einprägsame Gleichung aufgestellt: Agent = Modell + Harness.
Aus Sicht von DeepSeek ist das Modell nur die Hälfte des Agenten. Die andere Hälfte ist der Harness, der dafür sorgt, dass der Agent die Umgebung versteht, Tools aufruft, Zustände verwaltet und Aufgaben kontinuierlich ausführt. Nur wenn beide Komponenten zusammenwirken, kann der Agent Aufgaben wirklich erfüllen.
DSH hat den Harness selbst zu einem hochgradig modularen offenen Framework gemacht: Modell, Tools, Skills, Sitzungen, Sandbox, Speicher, Agenten-Schleife, Planung und sogar die Benutzeroberfläche können ausgetauscht werden.
Das Motto „Alles ist ein Plugin“ ist kein leeres Versprechen: Es wird erwartet, dass möglichst viele Nutzer Plugins entwickeln und an DSH anpassen, sodass unabhängig davon, welches Modell (DeepSeek oder ein anderes) ausgeführt wird, derselbe Harness als Grundlage dienen kann.
Dies bildet einen interessanten Kontrast zu dem Weg, den OpenAI derzeit einschlägt.
Obwohl OpenAI den Codex Harness ebenfalls als Open-Source-Code veröffentlicht hat, entwickelt sich das Agents API offensichtlich in eine andere Richtung: Sie können Ihren eigenen Harness verwenden, den Open-Source-Harness nutzen oder sich bei Bedarf vollständig zurücklehnen und die gesamte Verwaltung OpenAI überlassen.
Daher ist es eher als „Dienstleistung“ zu verstehen. OpenAI übernimmt das Hosting und die fortlaufende Wartung des Harness, Entwickler müssen nur entscheiden, was der Agent tun soll, welche Tools er nutzt und wo er ausgeführt wird. Sogar wenn das Modell aktualisiert wird und Anpassungen am Harness erforderlich sind, übernimmt OpenAI dies zukünftig mit.
In gewisser Weise zeichnen sich auf der Harness-Ebene derzeit zwei Richtungen ab:
Die von DeepSeek vertretene Richtung zielt eher auf den Aufbau eines offenen Ökosystems ab, bei dem jede Komponente als Plugin gestaltet wird und Entwickler sie selbst zusammenbauen können. Die von OpenAI vertretene Seite hingegen setzt auf Cloud-Dienste: Wenn Sie die Ressourcen und Anforderungen bereitstellen, erledigen wir den Rest für Sie.
Man könnte sogar sagen, dass die eine Seite den Harness so ähnlich wie Linux gestalten möchte, während die andere Seite ihn zu etwas Ähnlichem wie AWS entwickeln will.
Natürlich ist das nur eine Metapher. OpenAI hat den Codex Harness ebenfalls als Open-Source-Code veröffentlicht, und es ist durchaus möglich, dass DeepSeek zukünftig weitere Hosting-Dienste anbietet. Zumindest im aktuellen Stadium unterscheiden sich die Schwerpunkte der Produkte beider Seiten jedoch deutlich.
Interessanterweise ist Anthropic auf dem Weg, den Harness zu einem Dienst zu machen, OpenAI sogar einen Schritt voraus.
Bereits im September 2025 hat Anthropic das Claude Agent SDK veröffentlicht und die Tools, Kontextverwaltung, Berechtigungssysteme und Subagent-Fähigkeiten hinter Claude Code für Entwickler freigegeben, sodass andere mit diesen Funktionen ebenfalls Agenten erstellen können.
Dieses Jahr im April hat es sogar vor OpenAI das Produkt Claude Managed Agents auf den Markt gebracht. Sitzungen, Harness und Sandbox wurden in drei unabhängige Ebenen unterteilt: Anthropic übernimmt das Hosting von Harness und langen Aufgaben, die Sandbox kann sowohl von Anthropic bereitgestellt als auch an andere Ausführungsumgebungen angeschlossen werden. Dieser Ansatz ist dem heutigen Agents API bereits sehr ähnlich, Anthropic selbst definiert es als „einen Hosting-Dienst für langfristige Agentenaufgaben“.
In gewisser Weise setzt OpenAI mit diesem Schritt den Weg fort, den Anthropic bereits beschritten hat. Der Unterschied besteht nur darin, dass OpenAI über ein ausgereifteres „produktives“ Codex verfügt.
Aber da Codex und Claude Code seit langem unterschiedliche Produktwahrnehmungen hervorrufen, sind die Ergebnisse auch bei derselben zugrundeliegenden Idee völlig verschieden. Claude Code vermittelt das Gefühl, dass Entwickler im Terminal gemeinsam mit dem Agenten Code schreiben, während die Codex App von Anfang an auf die Benutzeroberfläche zur „gleichzeitigen Überwachung mehrerer langfristiger Agenten“ abzielt.
Nebenbei bemerkt ist Google bereits ebenfalls in diese Richtung eingestiegen. Auf der I/O-Konferenz im Mai dieses Jahres hat Gemini API Managed Agents eingeführt und ebenfalls Antigravity Harness und Sandbox als Hosting-Dienst bereitgestellt. Aber Google hat noch weitere Trümpfe in der Hand, auf die wir später eingehen werden.
Im Endeffekt ist es jedoch nicht so wichtig, wer zuerst kommt… Am Ende wird derjenige den größten Marktanteil gewinnen, der seinen eigenen Harness zu der standardmäßigen Basiskomponente für Entwickler macht.
03 Wer ist der große Gewinner?
Letztendlich stellt sich die Frage: Warum konkurrieren alle Modellanbieter derzeit um den Harness?
Wie die von DSH aufgestellte Gleichung zeigt: Agent = Modell + Harness. Das Modell kann dem Agenten sagen, was als Nächstes zu tun ist, aber um eine Aufgabe von Anfang bis Ende auszuführen, muss er auch wissen, wo sich die Dateien befinden, welches Tool aufgerufen werden soll, wie Fehler wiederhergestellt werden und wo das Ergebnis am Ende gespeichert wird.
Mit anderen Worten: Das Modell bestimmt die Obergrenze der Fähigkeiten eines Agenten, während der Harness zunehmend darüber entscheidet, ob er die Aufgabe tatsächlich abschließen kann.
Sobald sich die Wettbewerbsdimension von „Intelligenz“ zu „Ausführungsfähigkeit“ verschiebt, sind nicht unbedingt die KI-Unternehmen im Vorteil, die die besten Modelle entwickeln.
Denn wenn der Agent tatsächlich mit der Arbeit beginnt, sind die erforderlichen Ressourcen – E-Mails, Dokumente, Besprechungen, Kommunikation, Zugriffsberechtigungen und mehr – häufig im Besitz von traditionellen Plattformunternehmen.
Der in letzter Zeit intensiv geführte „Kampf um Büroagenten“ im Inland ist ein typisches Beispiel: Die Vorteile, die große Technologiekonzerne im Zeitalter der Internetplattformen angesammelt haben, waren früher meist nur Teilfunktionen ihrer jeweiligen Ökosysteme. Im Zeitalter der Agenten sind diese Ressourcen jedoch genau die Tools, die Agenten für ihre Arbeit benötigen.
Bei der Entwicklung von Büroagenten geht es oberflächlich betrachtet darum, wer den intelligentesten und leistungsfähigsten KI-Mitarbeiter anbieten kann. Im Hintergrund werden jedoch die angesammelten Plattformvorteile neu genutzt. Wer über mehr Unternehmensdaten, Dokumente, Tools und Berechtigungen verfügt, kann leichter sicherstellen, dass