Am 19. August veröffentlichte OpenAI im Entwickler-Blog einen Beitrag mit dem Titel "Codex as a platform" und positionierte Codex neu: weg von "Coding-Assistent fürs Terminal", hin zu "quelloffener Ausführungsschicht, auf der andere direkt aufbauen können".
Der Artikel beginnt mit einem oft übersehenen Punkt: Die meisten Nutzer kennen Codex über die Desktop-App, die Kommandozeile oder ein IDE-Plugin — doch alle drei Zugänge teilen sich dasselbe zugrunde liegende System, das längst auf GitHub liegt (Repository openai/codex, Apache-2.0-Lizenz, aktuell 109.000 Stars). Der eigentliche Schritt von OpenAI ist eine Neupositionierung: vom "internen Implementierungsdetail unseres Produkts" zum "Fundament für eure Produkte".
Was das Modell umgibt
Im englischen Original steht dafür der Begriff harness, in der Fachwelt meist als Ausführungsrahmen oder Steuerungsgerüst übersetzt. OpenAIs Definition fällt schlicht aus:
"That surrounding execution system is the harness."
Das umgebende Ausführungssystem ist der Harness.
Aufgeschlüsselt übernimmt dieser Rahmen: Kontext sammeln, Aufgaben in ausführbare Schritte zerlegen, Sitzungszustand über mehrere Runden hinweg pflegen, Tools aufrufen, innerhalb konfigurierter Sandbox- und Berechtigungsgrenzen laufen, an den richtigen Stellen für menschliche Freigaben anhalten und Ergebnisse schließlich ans Fachsystem zurückgeben. Mit den Modellgewichten hat das nichts zu tun, wirkt sich aber direkt auf die Benchmark-Werte aus. OpenAI verweist dazu auf eigene ARC-AGI-3-Zahlen von Ende Juli: Allein durch zwei Schalter auf Harness-Ebene — beibehaltenes Reasoning und Kontextkomprimierung — stieg der Wert von GPT-5.6 Sol auf dem öffentlichen Testset von 13,3 auf 38,3 Prozent, während die Zahl der Ausgabe-Tokens auf etwa ein Sechstel sank. Das Modell blieb unverändert, verändert wurde die Schicht drumherum.
Drei Integrationsstufen nach Eingriffstiefe
OpenAI unterteilt die Integration klar in drei Ebenen, sodass Entwickler je nach Anwendungsfall wählen können, statt alles zwangsläufig in ein Chatfenster zu pressen.
codex exec richtet sich an Skripte, CI-Jobs und einmalige Hintergrundaufgaben: Ein klar begrenzter Agentenlauf wird ausgeführt, liefert ein strukturiertes Ergebnis und ist fertig. Das Codex SDK richtet sich an Anwendungen, die Codex-Aufgaben direkt im Code starten, fortsetzen und als Stream lesen müssen. Der Codex app-server ist die tiefste Integrationsstufe: Die Anwendung verbindet sich mit einem lokal laufenden Codex-Prozess, hält die Sitzung dauerhaft offen, empfängt einen Event-Stream, kann jederzeit eingreifen, stellt dem Agenten eigene Tools bereit und übernimmt selbst die Behandlung von Freigabeanfragen.
Um zu zeigen, wie app-server funktioniert, hat OpenAI gleich eine Beispielanwendung namens Relay gebaut — ein fiktives Dashboard zur Behandlung von Frachtausnahmen. Nutzer schreiben keine Prompts, sondern wählen eine Sendung aus und klicken auf einen Button wie "Compare recovery"; die Anwendung liefert den relevanten Kontext, Codex ruft über ein von der Anwendung selbst bereitgestelltes MCP-Tool aktuelle Daten ab und erläutert Optionen; für eine tatsächliche Umbuchung ist zwingend eine menschliche Freigabe nötig, erst nach dem Speichern der Aktion aktualisiert die Anwendung ihre eigene Fachansicht.
Diese Designentscheidung wird im Artikel unverblümt begründet: Man solle kein universelles Chatfenster an die Stelle von Leitständen, Zeitleisten, Karten oder Ticketoberflächen setzen — genau dort verschaffen sich Menschen einen Überblick, treffen Entscheidungen und behalten das Gefühl der Kontrolle.
Wer es bereits einsetzt
OpenAI nennt drei öffentliche Beispielgruppen. GitHub und JetBrains haben Codex in ihre jeweiligen IDE-Workflows integriert; Cisco nutzt das Codex SDK im App Builder von Cloud Control; Thrive Holdings und Crete haben Codex in ihren Steuervorbereitungsprozess eingebaut — in der Pilotphase wurden 7.000 Steuererklärungen bearbeitet, die Vorbereitungszeit sank um rund ein Drittel.
Diese letzte Zahl wirkt vergleichsweise solide. Steuervorbereitung ist ein typischer Fall mit hoher Wiederholung, geringer Fehlertoleranz und strenger Compliance — eine belastbare Pilotgröße samt vergleichbarer Effizienzkennzahl ist aussagekräftiger als vage Formulierungen wie "deutlich gesteigerte Produktivität". OpenAI betont zugleich, dass dieses Muster nicht nur Engineering-Teams dient: Support-Triage, Betriebskoordination, Priorisierung von Sicherheitsvorfällen, Vertriebsrecherche — überall dieselbe Form: Die Anwendung liefert Kontext, Tools und Freigabeschritte, Codex übernimmt die Schleife dazwischen.
Wo Open Source endet
Ein unterstrichener Satz im Artikel bringt es auf den Punkt: Offen sind der Harness und die Integrationsflächen, Modellzugriff und gehostete Dienste werden weiterhin separat abgerechnet.
Zusammen mit den drei Integrationsstufen wird OpenAIs Kalkül deutlich. Die Ausführungsschicht wird kostenlos, prüfbar und anpassbar herausgegeben — jeder kann sie in eigene Produkte einbauen. Doch bei jedem Durchlauf einer Agentenschleife fließen weiterhin Tokens über die OpenAI-API. Je nützlicher der offene Teil und je mehr Produkte ihn einbetten, desto größer das Volumen auf Modellseite. Das ist derselbe Zug wie bei Anthropic, das MCP zum De-facto-Standard für Tool-Integration gemacht hat — nur gibt OpenAI diesmal etwas deutlich Gewichtigeres aus der Hand: die gesamte Laufzeitumgebung.
Für Teams, die Agentenprodukte bauen, liegt der unmittelbare Nutzen darin, sich einen Teil doppelter Arbeit zu sparen. Sitzungszustand, Event-Stream, Tool-Aufrufe, Unterbrechungen für Freigaben — die meisten Teams haben das schon einmal selbst implementiert und danach mühsam nachjustiert. Jetzt gibt es eine im großen Maßstab erprobte, zeilenweise nachvollziehbare Referenzimplementierung. Grob gerechnet: Wenn allein Änderungen auf Harness-Ebene die Ausgabe-Tokens auf ein Sechstel drücken, lassen sich mit demselben Budget fünf zusätzliche Durchläufe fahren — allein das dürfte für viele Teams Grund genug sein, den Quellcode gründlich zu lesen.
Der Preis dafür liegt ebenso offen zutage: Je tiefer die Integration, desto enger die Bindung an OpenAIs Abrechnungsmodell. Besonders deutlich zeigt sich das bei app-server — das geht über eine reine API-Aufrufbeziehung hinaus und holt praktisch den Prozess des Anbieters direkt ins eigene Produkt.
Quellen: OpenAI-Entwickler-Blog "Codex as a platform", CocoLoop, GitHub-Repository openai/codex; Lizenz, Star-Zahl und die drei Integrationsstufen wurden anhand des Repositorys und der offiziellen Dokumentation geprüft, ARC-AGI-3-Werte und Token-Reduktion basieren auf OpenAIs eigenen Angaben.