OpenAI verlagert den Agenten-Ausführungsrahmen in die Responses API

Der Ausführungsrahmen läuft nicht mehr auf dem Client

Die zentrale strukturelle Änderung betrifft den Ort, an dem die Ausführungsschleife läuft. OpenAI merkt an, dass die Responses API bei der Nutzung mit eigenen Tools „die Kontrolle an den Client zurückgibt, und der Client einen eigenen Ausführungsrahmen zum Ausführen der Tools benötigt". Mit dem Shell-Tool und dem gehosteten Container wandert dieser Rahmen serverseitig.

Die beschriebene Schleife ist konkret: Das Modell schlägt einen oder mehrere Shell-Befehle vor, die API leitet sie an eine Container-Laufzeitumgebung weiter, streamt die Ausgabe zurück und speist sie erneut in den Kontext der nächsten Anfrage ein. Das wiederholt sich, bis das Modell eine Antwort ohne weitere Befehle liefert. Nichts in dieser Schleife erfordert, dass der Entwickler einen Container betreibt, auf Ausgaben pollt oder Wiederholungslogik verdrahtet.

Für Frontend- und Client-Teams verändert das die Definition einer Anfrage grundlegend. Ein einzelner Prompt kann sich laut dem Beitrag „zu einem End-to-End-Workflow entfalten" – eine Skill wird entdeckt, Daten werden abgerufen, in SQLite umgewandelt, abgefragt und ein Artefakt erzeugt –, ohne dass der Client irgendeinen der Zwischenzustände verwaltet.

Wie die Schleife schnell und begrenzt bleibt

Zwei Details verhindern, dass die Schleife ins Stocken gerät oder den Kontext überflutet. Erstens kann das Modell mehrere Shell-Befehle in einem Schritt vorschlagen, und die API führt sie gleichzeitig in separaten Container-Sitzungen aus, wobei die unabhängigen Ausgabeströme als strukturierte Tool-Ausgaben zusammengeführt zurückgegeben werden. Das genannte Beispiel: paralleles Durchsuchen von Dateien, Abrufen von Daten und Validieren von Zwischenergebnissen.

Zweitens legt das Modell eine Ausgabegrenze pro Befehl fest. Die API setzt diese durch und liefert ein begrenztes Ergebnis, das Anfang und Ende bewahrt und ausgelassene Inhalte kennzeichnet – der Beitrag zeigt ein Beispiel mit einer Grenze von 1.000 Zeichen und einer Markierung „1000 chars truncated" in der Mitte. Das ist eine bewusste Antwort auf das Anti-Pattern, bei dem große Tabellen und Terminal-Logs das Kontextbudget aufzehren.

Das Shell-Tool selbst ist breiter angelegt als der bisherige, rein auf Python beschränkte Code-Interpreter. Es bringt grep, curl und awk von Haus aus mit, und laut dem Beitrag kann es Go- oder Java-Programme ausführen oder einen NodeJS-Server starten – die Ausführungsfläche ist also eine Unix-Kommandozeile, keine einzelne Sprachlaufzeit.

Komprimierung – und die Codex-Feedbackschleife, die sie hervorgebracht hat

Lang laufende Aufgaben füllen das Kontextfenster, daher hat OpenAI eine native Komprimierung eingeführt. Trainierte Modelle erzeugen ein „Compaction Item", das den vorherigen Zustand in einer verschlüsselten, token-effizienten Darstellung bewahrt; das nächste Fenster übernimmt dieses Item sowie besonders wertvolle Teile des vorherigen. Verfügbar ist dies als serverseitige automatische Komprimierung mit konfigurierbarem Schwellenwert oder über einen eigenständigen /compact-Endpunkt, wobei die serverseitige Variante kleine Überschreitungen toleriert, statt Anfragen nahe der Grenze abzulehnen.

Die konkreteste Aussage des Beitrags betrifft die Art, wie das System entstanden ist. Codex hat den Komprimierungsmechanismus sowohl mitentwickelt als auch als früher Nutzer eingesetzt:

Wenn eine Codex-Instanz auf einen Komprimierungsfehler stieß, haben wir eine zweite Instanz gestartet, um die Sache zu untersuchen. Das Ergebnis: Codex erhielt allein durch die Arbeit an diesem Problem ein natives, wirksames Komprimierungssystem.Montana Labs

OpenAI stellt das als einen Lernprozess dar, den Codex gemeinsam mit den Ingenieuren durchläuft. Es ist zugleich ein Hinweis darauf, wie diese Grundbausteine intern validiert werden, bevor sie ausgeliefert werden – der Komprimierungspfad ist derselbe, auf den Codex angewiesen ist, um lange Coding-Sitzungen durchzuhalten.

Das Sicherheitsmodell, das Entwickler übernehmen, statt es neu zu erfinden

Der Netzwerkzugriff der Container läuft über einen vorgeschalteten Egress-Proxy: Alle ausgehenden Anfragen durchlaufen eine zentrale Richtlinienebene, die Allowlists durchsetzt und den Datenverkehr dabei beobachtbar hält. Zugangsdaten werden über eine domänenbezogene Secret-Injection beim Egress bereitgestellt – Modell und Container sehen nur Platzhalter, die eigentlichen Geheimniswerte bleiben außerhalb des für das Modell sichtbaren Kontexts und werden nur für freigegebene Ziele angewendet.

Genau das ist der Teil, bei dem Client-Teams beim Bau ihrer eigenen Agenten-Sandbox am häufigsten Fehler machen. Indem OpenAI Zugangsdatenverwaltung und Netzwerkrichtlinien auf die Plattform verlagert, übernimmt das Unternehmen die Verantwortung für die Angriffsfläche rund um Datenlecks und Exfiltration, die sonst in der Infrastruktur jedes einzelnen Entwicklers läge.

Was ein client-seitiger Entwickler jetzt noch verantwortet – und was nicht mehr

Die konkrete Konsequenz dieser Ankündigung ist eine Verkleinerung des Aufgabenbereichs auf Client-Seite. Orchestrierung, Sandbox-Ausführung, Ausgabenbegrenzung, Kontextkomprimierung, Netzwerkrichtlinien und Secret-Scoping sind jetzt Plattform-Grundbausteine. Skills – versionierte Ordnerpakete mit einer SKILL.md – erlauben es Teams, wiederkehrende mehrstufige Muster als wiederverwendbare Logik zu bündeln, die das Modell mit einfachen Shell-Befehlen wie ls und cat selbst entdeckt.

Was auf Entwicklerseite bleibt, ist gestalterische Arbeit: Eingaben im Container-Dateisystem statt im Prompt bereitstellen, SQLite-Tabellen so beschreiben, dass das Modell nur relevante Zeilen abfragt, und Skills verfassen, die Konventionen kodieren. Der Kompromiss ist klar – weniger Infrastruktur zum Betreiben, dafür eine stärkere Abhängigkeit von OpenAIs Laufzeitumgebung und den Modellen GPT-5.2 und neuer, da nur diese trainiert sind, Shell-Befehle vorzuschlagen. Teams, die bereits robuste Ausführungsrahmen aufgebaut haben, sollten abwägen, was sie in puncto Portabilität aufgeben gegenüber dem, was sie nicht mehr selbst pflegen müssen.