OpenAI öffnet die Agents API und verkauft die Harness hinter Codex

OpenAI hat zwei Jahre lang Entwicklern Modellaufrufe verkauft, in jüngerer Zeit auch ein Framework, um Agenten zu verdrahten. Am 10. September 2026 begann das Unternehmen, etwas anderes zu verkaufen: die Maschinerie dazwischen. Die Firma öffnete ihre Agents API in der öffentlichen Beta und gab jedem Entwickler Zugriff auf die verwaltete „Codex harness“ – die Agentenschleife und die Infrastruktur hinter Codex – über einen einzigen API-Aufruf.

Zum Weiterlesen: ServiceNows Aktie fiel um 27 Prozent, als die KI-Furcht die Softwareaktien erfasste · Cloudflare übernimmt Deno, um Workers selbst hostbar zu machen.

Das Angebot ist bewusst eng gefasst und für Teams, die langlebige Agenten gebaut haben, sofort erkennbar. Man beschreibt die Aufgabe, das Modell, die Tools und die Ausführungsumgebung. Alles andere führt OpenAI aus. Dazu gehören die Teile, die die meisten Teams unterschätzen, bis sie Monate in einem Build stecken: eine Sitzung am Leben halten, ein überlaufendes Kontextfenster verwalten, fehlgeschlagene Schritte wiederholen und Arbeit koordinieren, die länger überdauern muss als ein einzelner Anfrage-Antwort-Zyklus.

Es ist ein Produktisierungsschritt ebenso wie ein technischer. OpenAI ist nicht mehr nur der Lieferant der Intelligenz, die ein Agent nutzt; nun will das Unternehmen die Laufzeitumgebung sein, in der der Agent lebt.

Der Teil, den OpenAI tatsächlich verkauft

OpenAI bietet in diesem Bereich bereits Bausteine an. Die Responses API lässt Entwickler Modelle mit integrierten Fähigkeiten wie Websuche, Dateisuche und Computer Use kombinieren, und das Agents SDK hilft, Agenten-Workflows zu definieren und zu orchestrieren. Was diese Tools Ihnen überlassen, ist die Infrastruktur rund um das Modell – Laufzeit, Sitzungsverwaltung, Wiederholungen, Sandbox-Lebenszyklus und Zustand.

Die Agents API absorbiert diese Schicht in einen verwalteten Dienst. Wie Anirban Ghoshal von InfoWorld berichtet, bündelt der Dienst Orchestrierung, Kontextverwaltung und Ausführungsinfrastruktur in einer API, wobei OpenAI die Harness hostet und wartet. Das Wertversprechen, auf das Analysten immer wieder zurückkommen, ist eine Verringerung der Engineering-Komplexität: keine Queue, keine Zustandsdatenbank, keine Sandbox-Flotte, keine Kompaktierungsroutine und keine Wiederholungsrichtlinie, die ein Team besitzen und für die es Bereitschaftsdienst leisten muss.

Der API-Dokumentation zufolge unterstützt die verwaltete Harness:

• das Ausführen von Befehlen und Code in einer Sandbox.
• das Anwenden relevanter Skills und Anweisungen.
• die Verbindung mit externen Daten über Tools oder MCP-Server.
• die Steuerung des Agenten während der Arbeit.
• das Zusammenfassen früherer Arbeit zur Verwaltung des Kontextfensters.
• das Aufteilen von Arbeit in Teilaufgaben und die Delegation an Subagenten.
• das Fortsetzen einer Sitzung an der Stelle, an der sie aufgehört hat.

Anwendungen liefern weiterhin die Tools und entscheiden, wo die Arbeit läuft. Alles oberhalb dieser Linie ist jetzt OpenAIs Problem.

Die Unterscheidung zwischen einem Framework und einem verwalteten Dienst ist der Kern. Das seit März 2025 verfügbare Agents SDK gibt Entwicklern eine Reihe von Bibliotheken, die sie selbst betreiben. Die Agents API ist das gehostete Gegenstück: ein Dienst, bei dem der Anbieter die Schleife betreibt. Frameworks tauschen Flexibilität gegen Kontrolle; verwaltete Laufzeitumgebungen tauschen Kontrolle gegen weniger eigenen Code. Was OpenAI ausdrücklich sagt, ist, dass dies dieselbe Harness ist, die das Unternehmen intern nutzt – keine reine Entwickler-Reimplementierung –, was eine bedeutsame Aussage über Praxisbewährung ist, auch wenn die Beta-Einschränkungen weiter unten bedeuten, dass sie noch kein gleichwertiger Ersatz für jede Arbeitslast ist.

Sitzungen, die bestehen bleiben, und ein Kontext, der sich selbst komprimiert

Die API ist laut den Docs um vier Konzepte herum organisiert: den agent (Modell, Anweisungen, Tools und MCP-Server), die environment (eine optionale Sandbox für Dateien, Befehle und Skills), die session (eine dauerhafte Agenteninstanz, die auf neue Eingaben reagiert) und events and items (die gesendeten Eingaben und die erzeugten Ausgaben).

Dauerhaftigkeit ist die Schlagzeile. Eine Sitzung kann Minuten, Stunden oder Tage laufen, wobei OpenAI den Zustand speichert, sodass Entwickler Arbeit über mehrere Züge hinweg fortsetzen können, ohne den Gesprächskontext neu aufzubauen. Die Kontextkompaktierung ist automatisch: Wenn sich eine Sitzung ihrem Limit nähert, wird früherer Inhalt verdichtet, ohne dass der Entwickler Kompaktierungslogik schreiben muss. Ist der Multi-Agenten-Modus aktiviert, wird die Kompaktierung unabhängig auf den Root-Agenten und jeden Subagenten angewandt, damit ihre Kontexte sich nicht gegenseitig stören.

Die Koordination der Subagenten folgt demselben verwalteten Muster. Der Root-Agent kann Subagenten erzeugen, ihnen begrenzte Aufgaben übergeben, auf Ergebnisse warten und eine endgültige Antwort zusammenführen, wobei Simon Carters Beitrag einen Standardwert max_concurrent_subagents von drei als empfohlenen Ausgangspunkt nennt. Eine Sitzung kann außerdem nach einem Fehler fortgesetzt, bei Nichtbedarf gelöscht oder mitten in einem Zug gesteuert werden – Letzteres ist wichtig für alles, was Produktionssysteme berührt.

Der Quickstart macht die Form konkret: ein Coding-Assistent, der tree.py schreibt, es ausführt und einen Verzeichnisbaum meldet, wobei OpenAI den Agenten, seine Konversation und die Sandbox verwaltet. Das erste funktionierende Beispiel ist ein einziger SDK-Aufruf.

Operativ folgen Anwendungen einer Sitzung, indem sie Ausgaben streamen oder Webhooks abonnieren, sodass sie erfahren, wann ein Agent fertig ist oder Eingaben benötigt, statt blind zu pollen. Die Docs warnen, dass ein abgeschlossener Zug nicht garantiert, dass jedes Tool erfolgreich war – Ereignisse, die mit turn.failed, turn.cancelled oder session.failed enden, zeigen einen Fehler oder Abbruch an –, und dass ein unterbrochener Stream wiederhergestellt werden sollte, indem die gespeicherten Items der Sitzung abgerufen werden, bevor ein neuer Versuch unternommen wird. Diese Anleitung erinnert daran, dass die Verwaltung eines langlebigen Agenten ebenso sehr Fehlerbehandlung wie Modellqualität ist – genau die Arbeit, die OpenAI nun zu übernehmen anbietet.

Drei Orte, an denen die Arbeit laufen kann

Die Ausführungsumgebung ist eine der wenigen Entscheidungen, die die API dem Entwickler tatsächlich überlässt, und es gibt drei Optionen:

1. Eine von OpenAI gehostete Sandbox – dieselbe Sandboxing-Infrastruktur hinter Codex, konfigurierbar mit Dateien, Paketen, Skills und Plugins und zu Standard-Container-Preisen abgerechnet.
2. Eine selbst gehostete Sandbox – führen Sie codex exec-server in Ihrer eigenen Umgebung aus. Sie registriert sich mit einem eingeschränkten Schlüssel und verbindet sich ausgehend per WebSocket, sodass kein eingehender Port geöffnet werden muss.
3. Partner-Sandboxes – Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop und Vercel werden alle unterstützt, sodass Unternehmen Compute in ihrer eigenen VPC behalten und ihren eigenen Ansatz für Dateien, Secrets und Konfiguration wählen können.

Die Harness selbst ist laut Carters Bericht zusätzlich über das Codex-Repository Open Source, sodass Teams unabhängig von der gewählten Laufzeitumgebung nachvollziehen können, wie sie funktioniert.

Die Wirtschaftlichkeit: keine Gebühr für die Harness

Die Preisgestaltung ist ungewöhnlich einfach, und sie dürfte die Entscheidung über die Einführung am stärksten beeinflussen. OpenAI erhebt keine zusätzliche Gebühr für die Agents API selbst. Die Modellnutzung wird zu den Standard-API-Preisen des gewählten Modells abgerechnet, OpenAI-Tools nutzen ihre Standardpreise, und von OpenAI gehostete Sandboxes werden zu Standard-Container-Preisen abgerechnet. Compute, das Sie selbst betreiben oder an einen Partneranbieter übergeben, wird von demjenigen abgerechnet, der es betreibt.

Für Teams, die zwischen Bauen und Kaufen abwägen, entfällt damit eine häufige Quelle des Zögerns: Es gibt keine separate Harness-Steuer, die sonst gegen die Kosten für die interne Entwicklung der Laufzeitumgebung gerechtfertigt werden müsste. Der Handel besteht darin, dass der Austausch der verwalteten Teile, sobald sie einmal etabliert sind, aufwendiger ist als der Wechsel eines Modell-Endpunkts.

Die entscheidenden Grenzen: US-only-Residenz und kein ZDR

Die Beta-Einschränkungen sind keine Fußnoten. Während der öffentlichen Beta ist die Datenresidenz auf die USA beschränkt, und der Dienst unterstützt kein Zero Data Retention (ZDR) – eine Einschränkung, die selbst dann gilt, wenn ein Team seine eigene selbst gehostete Sandbox bereitstellt. OpenAI hat keinen öffentlichen Zeitplan für eine Ausweitung der Residenz genannt.

Diese Kombination ist für einen großen Teil des Marktes ein echtes Hindernis. Gesundheitswesen, Finanzdienstleistungen, Rechtswesen und europäische Arbeitslasten hängen häufig davon ab, Daten in einer bestimmten Jurisdiktion zu halten und vertragliche Garantien zu haben, dass Prompts und Ausgaben nicht gespeichert werden. InfoWorld zitiert Analysten, die genau diesen Punkt machen – einer merkt an, die ZDR-Lücke könnte die Einführung in regulierten Sektoren begrenzen, ein anderer beobachtet, dass in der EU ansässige Teams vor jeder geplanten Migration eine harte Einschränkung prüfen müssten. Startups, SaaS-Unternehmen und bereits auf OpenAI standardisierte Großunternehmen sind dagegen die wahrscheinlichsten frühen Nutzer.

Wettbewerb und die Lock-in-Frage

Die verwaltete Agenten-Laufzeitumgebung ist bereits eine überfüllte Kategorie, was deshalb wichtig ist, weil es den Rahmen von „Kann OpenAI das?“ zu „Warum OpenAIs Version wählen?“ verschiebt.

• Anthropics Claude Managed Agents ist seit April 2026 in öffentlicher Beta.
• AWS' Amazon Bedrock AgentCore erreichte im Juni 2026 die allgemeine Verfügbarkeit für seine verwaltete Harness und leistet dieselbe Art von Arbeit – Schleife, Tool-Ausführung, Kontext, Zustand und Wiederherstellung –, während Kunden jedes Modell nutzen und Anbieter mitten in einer Sitzung wechseln können, ohne den Kontext zu verlieren.
• Microsofts Foundry Agent Service und LangGraph liegen laut InfoWorld in derselben Nachbarschaft.

Der Wettbewerbsunterschied ist die Portabilität. Eine verwaltete Harness, die gegenüber mehreren Modellen offen ist, senkt die Wechselkosten; eine, die an die Modelle, Kontextverwaltung, Tools, Orchestrierung und Ausführungsumgebung eines einzigen Anbieters gebunden ist, erhöht sie. Von InfoWorld zitierte Analysten nennen Lock-in als größte Sorge und merken an, dass eine tiefere Abhängigkeit die Verhandlungsposition eines Unternehmens bei Preisen und Bedingungen schwächen kann. Unternehmen mit Multi-Modell-Strategien bevorzugen möglicherweise eine unabhängige Harness oder eine hybride Aufteilung.

Zugang und eine Migrationsuhr

Der Zugang steht jedem Entwickler offen. Das Erstellen eines Anwendungs-API-Schlüssels erfordert api.agents.read und api.agents.write für Sitzungsoperationen sowie api.responses.write für die Modellinferenz. Anfragen tragen den Header OpenAI-Beta: agents=v1; die offiziellen SDKs fügen ihn automatisch hinzu für diejenigen, die eine Client-Bibliothek statt cURL verwenden.

An den umfassenderen Wandel ist zudem eine Frist geknüpft. OpenAI stellt Agent Builder und Evals am 30. November 2026 ein und verweist codebasierte Workflows auf das Agents SDK und die Agents API. Teams, die eines der beiden Tools nutzen, haben ein begrenztes Zeitfenster, um eine Migration zu planen, und die Ankunft der verwalteten API gibt ihnen ein Ziel, auf das sie sich zubewegen können – oder einen Grund, den Ansatz ganz zu überdenken.

Was zu beobachten ist

• Residenz und Aufbewahrung. Ob OpenAI regionale Datenresidenz oder einen ZDR-Weg hinzufügt, ist die einzelne Einschränkung, die die Einführung im Unternehmen am ehesten bestimmen dürfte. Ein Zeitplan wurde nicht genannt, also achten Sie in der Data-Controls-Dokumentation der API darauf.
• Reale Kosten im Maßstab. „Keine Harness-Gebühr“ ist auf einer Preisseite sauber. Die aussagekräftige Zahl sind die Gesamtkosten, sobald langlebige Sitzungen, Sandbox-Containerstunden und Token-Verbrauch zusammengerechnet werden, besonders im Vergleich zu selbst gehosteten und Partner-Laufzeitumgebungen.
• Modell-Portabilität. Ob die Agents API Modelle jenseits von OpenAIs eigenen unterstützt – oder einen Anbieterwechsel mitten in der Sitzung ermöglicht, wie Bedrock AgentCore wirbt –, wird entscheiden, wie viel Lock-in Teams tatsächlich eingehen.
• Die Einstellung am 30. November. Beobachten Sie, wie schnell Agent-Builder- und Evals-Nutzer in das Agents SDK und die Agents API gelenkt werden und ob die Migrationspfade tragen.
• Wettbewerbsdruck. Da Anthropic und AWS bereits vergleichbare verwaltete Laufzeitumgebungen ausliefern, beobachten Sie, ob OpenAI über Funktionen, Preis oder Offenheit konkurriert – und ob die Haltung „keine zusätzliche Gebühr“ die allgemeine Verfügbarkeit übersteht.

Aufmacherbild: Entwickler an Laptops bei einem Coding-Event. Foto von Matthew (WMF), via Wikimedia Commons, CC BY-SA 3.0.