OpenAI hat den Codex „zerlegt und verkauft“.

Denn dieses Mal hat OpenAI den Codex „zerlegt und verkauft“.

Die Reihe von Funktionen, die ursprünglich hinter dem Codex verborgen waren und dafür verantwortlich waren, dass der Agent weiter arbeiten, Tools aufrufen, den Kontext verwalten und mehrere Agenten koordinieren konnte, wurden extrahiert und in eine Cloud-API gepackt, damit alle Entwickler sie aufrufen können.

Codex als Service?

Tatsächlich hat OpenAI den Codex schon seit langem demontiert.

Bereits im April 2025, als OpenAI o3 und o4-mini zum ersten Mal veröffentlichte, stellte es die Codex-CLI als Open Source zur Verfügung. Es ähnelt ein wenig der OpenAI-Version von Claude Code, die direkt im lokalen Terminal installiert wird. Wie der Agent ausgeführt wird und wie die Tools aufgerufen werden, ist auf GitHub übersichtlich aufgeführt. Wenn Sie bereit sind, sich die Mühe zu machen, können Sie es zurücknehmen, modifizieren und selbst ausführen.

Aber damals wurden die Dinge einfach ausgegeben. Ob Sie sie nutzen können und wie Sie sie nutzen möchten, ist immer noch Ihre eigene Sache.

Einen Monat später wurde die Codex-Cloud-Version, das Produkt, mit dem wir heute vertraut sind, offiziell eingeführt. Benutzer können ihm das Code-Warehouse übergeben, und jede Aufgabe entspricht einer unabhängigen Cloud-Sandbox. Codex kann den Code ändern, Tests ausführen, Fehler beheben und mehrere Aufgaben gleichzeitig erledigen.

Einige Monate später, im Oktober 2025, veröffentlichte OpenAI das Codex SDK.

Vereinfacht ausgedrückt ist das SDK ein Toolkit für Entwickler, sodass Codex nicht nur als eigenständiges Produkt verwendet, sondern auch in Anwendungen anderer Leute integriert werden kann. Das SDK ermöglicht es Entwicklern, mit wenigen Zeilen TypeScript-Code denselben Agenten zu starten, der die Codex-CLI steuert, eine strukturierte Ausgabe zu erhalten, den Aufgabenstatus beizubehalten und die Ausführung nach einer Pause fortzusetzen.

Das SDK eignet sich jedoch hauptsächlich zum Aufrufen von Codex in Programmen und erschließt noch nicht die vollständigen Codex-Interaktionsmöglichkeiten. Es eignet sich sehr gut für Hintergrundworkflows, automatisierte Skripte und serverseitige Programme. Wenn Sie jedoch einen vollständigen Client wie Codex IDE erstellen möchten, ist dies immer noch etwas schwierig.

Deshalb veröffentlichte OpenAI im Februar 2026 offiziell den Codex App Server und erläuterte erstmals systematisch und klar das Harness im Codex.

OpenAI erklärte klar und deutlich, dass Codex Web, CLI, IDE-Erweiterungen und Mac App unterschiedliche Produkte zu sein scheinen, in Wirklichkeit jedoch dasselbe Codex Harness darunter läuft, das die Schicht ist, die für Agent Loop, Thread, Tool-Ausführung, Authentifizierung und Verwaltungsstatus verantwortlich ist.

App Server fügt diesem kompletten Harness-Set eine bidirektionale JSON-RPC-Schnittstelle hinzu. JetBrains, Xcode oder andere Clients müssen keine Agentenschleife neu erstellen. Sie können den App Server direkt starten, um den gesamten Codex zu steuern.

Mit App Server können andere Produkte direkt an das komplette Codex Harness angebunden werden.

An diesem Punkt gibt es jedoch noch ein letztes Problem, das gelöst werden muss.

Das SDK steuert den lokalen Codex-Agenten und der App-Server selbst ist ebenfalls ein residenter Prozess, der von Entwicklern gestartet und gewartet werden muss. Obwohl das Problem der Integration von Codex in das Produkt gelöst wurde, ist es immer noch etwas schwierig, es stabil in einen Online-Dienst zu integrieren.

Um ein konkreteres Beispiel zu geben: Wenn Sie App Server verwenden, um Ihre eigene Coding Agent-Website zu erstellen, wurde das Frontend mit Codex verbunden, aber wenn der Benutzer auf „Dieses Warehouse reparieren“ klickt, müssen Sie immer noch einen Weg finden, eine große Anzahl nachfolgender Betriebs- und Infrastrukturprobleme zu lösen.

Dann kam der 19. August. An diesem Tag vereinte OpenAI die im vergangenen Jahr geöffnete CLI, SDK und App Server in der Plattformerzählung „Open Codex Harness“ und wertete Codex deutlich von einem Produkt zu einer Plattform auf.

Dann, am 10. September (US-Zeit), also gestern, wurde die Agents API offiziell für öffentliche Tests geöffnet.

Dieses Mal müssen Entwickler der API nur vier Dinge mitteilen – Aufgaben, Modelle, Tools und laufende Umgebungen –, um direkt einen Agenten zu erstellen. Codex Harness, das für die Kontextkomprimierung bei langen Sitzungen, die Werkzeugplanung und die Zusammenarbeit mit Subagenten verantwortlich ist, wird von OpenAI selbst gehostet und verwaltet.

Sie können sogar den Computer auswählen, auf dem der Agent tatsächlich arbeitet. Sie können wählen, ob Sie die Sandbox von OpenAI, Ihre eigene Infrastruktur oder Umgebungen von Drittanbietern wie Cloudflare, E2B und Modal verwenden möchten. Harness wird von OpenAI bereitgestellt und die Ausführungsumgebung wird vom Entwickler bestimmt.

Die offizielle Aussage ist sehr klar: Für die Agents API selbst fallen keine zusätzlichen Kosten an. Mit anderen Worten: Für Harness-Hosting, die Verwaltung langer Sitzungen und andere Funktionen fallen keine separaten Gebühren für die Agent-Plattform an.

Entwickler zahlen auf der Grundlage der tatsächlich verwendeten Modell-Tokens und Tools; Bei Nutzung der OpenAI-eigenen Hosting-Sandbox werden die Rechenressourcen separat berechnet.

Seit mehr als einem Jahr macht OpenAI das Gleiche: Codex Schicht für Schicht von einem bestimmten Produkt in wiederverwendbare Funktionen aufzuteilen, während sich Entwickler immer weniger Sorgen um sich selbst machen müssen.

Wenn man dieser Produktlinie einen Namen geben muss, ist sie tatsächlich dem damaligen SaaS sehr ähnlich, nur dass dieses Mal nicht Software, sondern Codex betreut wird.

Codex als Service.

Das Geschirr hat auch begonnen, sich zu verzweigen

Natürlich ist OpenAI nicht der Einzige, der Harness im Auge hat.

Als DeepSeek Harness (im Folgenden als DSH bezeichnet) veröffentlicht wurde, wurde eine sehr laute Gleichung aufgestellt:

Agent = Modell + Harness.

Nach Ansicht von DeepSeek stellt das Modell nur die Hälfte des Agenten dar, und die andere Hälfte ist das Harness, das dafür verantwortlich ist, dass es die Umgebung versteht, Tools aufruft, den Status verwaltet und weiterhin Aufgaben ausführt. Nur wenn sich beide abstimmen, kann der Agent seine Aufgaben tatsächlich erfüllen.

DSH hat Harness zu einem hochmodularen offenen Framework gemacht: Modelle, Tools, Skills, Sitzungen, Sandboxes, Speicher, Agent Loop, Terminplanung und sogar die Benutzeroberfläche können alle ersetzt werden.

Der Slogan „Alles ist ein Plug-in“ ist nicht nur ein Witz. Es ist am besten, wenn jeder Plug-Ins schreibt und sich an DSH anpasst. Unabhängig davon, ob DeepSeek oder andere Modelle oben laufen, kann am Ende derselbe Satz Kabelbäume darunter verwendet werden.

Dies ist ein interessanter Kontrast zu der Richtung, die OpenAI derzeit einschlägt.

Obwohl OpenAI auch das Codex-Harness als Open-Source-Lösung bereitgestellt hat, geht die Agents-API offensichtlich in die andere Richtung: Sie können Ihr eigenes Harness verwenden oder das Open-Source-Harness verwenden, aber wenn Sie es als störend empfinden, können Sie es einfach ignorieren und es mir überlassen, es für Sie zu arrangieren.

Wir betrachten es also eher als eine „Dienstleistung“. OpenAI ist für das Hosting und die kontinuierliche Wartung von Harness verantwortlich. Entwickler müssen lediglich entscheiden, was der Agent tun soll, welche Tools er verwenden und wo er ihn ausführen soll. Selbst wenn das Modell in Zukunft aktualisiert wird und sich Harness entsprechend ändert, bereitet OpenAI auch die gemeinsame Paketierung vor.

In gewisser Weise gibt es auf der Harness-Ebene zwei vage Routen:

Der von DeepSeek dargestellte Weg ähnelt eher dem Aufbau eines offenen Ökosystems, bei dem jeder Teil in ein Plug-in umgewandelt wird, das Entwickler selbst zusammenstellen können. Während die von OpenAI vertretene Partei so ist, als würde man auf Cloud-Dienste wetten, Geld und Nachfrage schaffen, und ich werde Ihnen helfen, den Rest zu lösen.

Wir können sogar denken, dass der eine Harness immer mehr wie Linux machen möchte und der andere Harness immer mehr wie AWS machen möchte.

Natürlich ist das nur eine Metapher. OpenAI verfügt auch über Open-Source-Codex Harness, und es ist für DeepSeek nicht unmöglich, in Zukunft weitere Hosting-Dienste anzubieten. Aber zumindest zu diesem Zeitpunkt ist der Fokus der beiden Produkte offensichtlich unterschiedlich.

Interessanterweise ist Anthropic OpenAI tatsächlich einen Schritt voraus, wenn es darum geht, Harness in einen Dienst umzuwandeln.

Bereits im September 2025 brachte Anthropic das Claude Agent SDK auf den Markt und öffnete Entwicklern die Tools, das Kontextmanagement, das Berechtigungssystem und die Subagentenfunktionen hinter Claude Code, sodass andere diese Dinge als Agenten nutzen können.

Im April dieses Jahres wurden Claude Managed Agents noch früher als OpenAI eingeführt. Sitzung, Harness und Sandbox sind in drei unabhängige Schichten aufgeteilt: Anthropic ist für das Hosting von Harness und langen Aufgaben verantwortlich. Die Sandbox kann von Anthropic bereitgestellt oder mit anderen Ausführungsumgebungen verbunden werden. Diese Idee kommt der heutigen Agenten-API tatsächlich ziemlich nahe. Anthropic selbst definiert es als „einen Hosting-Dienst für langfristige Agentenaufgaben“.

In gewisser Weise schreitet OpenAI also weiter auf dem Weg voran, den Anthropic dieses Mal eingeschlagen hat. Der Unterschied besteht darin, dass OpenAI einen stärker „produktisierten“ Codex hat.

Da Codex und Claude Code jedoch seit langem unterschiedliche Produkteindrücke hervorrufen, rufen sie, auch wenn sie die gleiche Geschichte erzählen, sehr unterschiedliche Gefühle hervor. Bei Claude Code geht es eher darum, Entwickler im Terminal sitzen zu lassen und gemeinsam mit dem Agenten Code zu schreiben, während Codex App von Anfang an die Schnittstelle „mehrere langfristige Agenten gleichzeitig überwachen“ betont.

Google ist diesem Weg übrigens bereits beigetreten. Auf der I/O-Konferenz im Mai dieses Jahres stellte Gemini API Managed Agents vor, die auch Antigravity Harness und Sandbox in verwaltete Dienste verwandelten. Aber die Karten von Google hören hier nicht auf, worauf wir später noch eingehen werden.

Allerdings scheint es nicht so wichtig zu sein, wer zuerst kommt ... Am Ende wird natürlich derjenige, der sein Harness zur Standardebene für Entwickler macht, den größten Kuchen essen können.

Wer ist der große Gewinner?

Warum fangen Model-Unternehmen schließlich jetzt an, sich Harness zu schnappen?

Genau wie die von DSH gegebene Gleichung, Agent = Modell + Harness, kann das Modell dem Agenten sagen, was als nächstes zu tun ist, aber um eine Aufgabe wirklich von Anfang bis Ende auszuführen, muss es immer noch wissen, wo sich die Datei befindet, welches Tool aufgerufen werden muss, wie es bei Auftreten eines Fehlers wiederhergestellt werden kann und wo die Ergebnisse schließlich geschrieben werden.

Mit anderen Worten: Das Modell bestimmt die Obergrenze der Fähigkeiten des Agenten und Harness bestimmt zunehmend, ob es den Job abschließen kann.

Sobald sich die Dimension des Wettbewerbs von „Intelligenz“ zu „Ausführung“ verlagert, sind die KI-Unternehmen mit den besten Modellen möglicherweise nicht mehr diejenigen mit den größten Vorteilen.

Denn nachdem der Agent tatsächlich seine Arbeit aufgenommen hat, liegen die Dinge, die er benötigt – E-Mails, Dokumente, Besprechungen, Kommunikation, Kontoberechtigungen usw. – oft in den Händen traditioneller Plattformunternehmen.

Der kürzlich hitzige „Büroagentenkrieg“ in China ist tatsächlich ein sehr typisches Beispiel: Die Dinge, die große Unternehmen im Zeitalter der Internetplattformen anhäuften, waren früher eher nur ein Teil der Funktionen in ihren jeweiligen Ökosystemen, aber im Zeitalter der Agenten sind diese Dinge zufällig die Werkzeuge, die Agenten aufrufen müssen, wenn sie wirklich arbeiten.

Heutzutage arbeitet jeder als Bürokaufmann. Oberflächlich betrachtet sind sie intelligenter und leistungsfähiger als die KI-Mitarbeiter aller anderen. Hinter den Kulissen nutzen sie tatsächlich die Plattformvorteile, die sie in der Vergangenheit gesammelt haben. Wer über mehr Unternehmensdaten, Dokumente, Tools und Berechtigungen verfügt, wird es leichter haben, die Arbeit dem Agenten überlassen zu können.

Modellunternehmen müssen Zugang zu Portalen erhalten, die sie nicht haben, und Unternehmen, die seit mehr als zehn Jahren Bürosoftware und Internetplattformen herstellen, verfügen bereits über diese Portale.

Mit anderen Worten:

KI-Unternehmen wollen sich wieder mit der realen Welt verbinden, und Plattformunternehmen haben bereits einen Schlüsselbund in der Hand.

Wenn wir in dieser Richtung einen „Familien-Bucket“-Player mit den meisten Vorteilen finden müssen, ist Google wahrscheinlich der am meisten übertriebene Anbieter.

Von TPU, Cloud-Infrastruktur, Gemini bis hin zu Suche, Workspace, Chrome und Android deckt Google fast alle wichtigen Aspekte der KI ab, von der zugrunde liegenden Technologie bis hin zu Endbenutzern. Suche, Gmail, Kalender, Drive, YouTube, Karten und andere Produkte bilden auf natürliche Weise eine digitale Umgebung, die von Agenten aufgerufen werden kann. Diese Assets waren in der vorherigen Generation des Internets unabhängige Portale, aber in der Agenten-Ära können sie in dieselbe Aufgabe umorganisiert werden.

Tatsächlich hat Google damit begonnen, die in verschiedenen Produkten verstreuten Agentenfunktionen in dasselbe Ausführungssystem auf der Basis zu integrieren. Gemini Spark, Managed Agents in der Gemini API und sogar einige Agent-Erlebnisse in der Suche nutzen nach und nach das gleiche Antigravity Harness.

Aber auf der Benutzerseite sind die Dinge immer noch etwas chaotisch.

Heute verfügt Google auch über Gemini Spark, Workspace Studio, Antigravity, Gemini Enterprise und Information Agents in der Suche. Sie sind mit unterschiedlichen Nutzern und Szenarien konfrontiert, doch wenn normale Menschen eine komplexe Angelegenheit an Google übergeben möchten, wissen sie immer noch nicht, an wen sie sich wenden sollen.

Google verfügt bereits über die meisten Voraussetzungen, um all dies zu erreichen. Was fehlt, ist eine ausreichend einfache Produktantwort.

Und wenn Google diese Angelegenheit wirklich versteht – sei es die Schaffung einer einheitlichen Agenten-Workbench oder die Durchdringung des gesamten Google-Ökosystems mit demselben Agenten-Ausführungssystem, damit sich Benutzer daran gewöhnen, „Google zu finden, wenn sie Probleme haben“, wird sich die Wettbewerbslandschaft des globalen Agenten-Marktes wahrscheinlich erneut ändern.

Selbst wenn Google diesen „Familieneimer“ wirklich in einen Agenten steckt, werden inländische Nutzer ihn höchstwahrscheinlich zuerst nur ansehen können.

Werfen wir zunächst einen Blick auf den inländischen Agentenkrieg und sehen, wie er als nächstes ausgetragen wird.