OpenAI Agents API: Was der Codex-Harness übernimmt
OpenAI betreibt die Codex-Agentenschleife für deine Anwendung. Ich erkläre den Unterschied zum SDK, die gespeicherten Daten und die verbleibenden Kosten.
OpenAIs Agents API ist seit dem 10. September 2026 als öffentliche Beta verfügbar. Entwickler können damit die verwaltete Codex-Infrastruktur in eigenen Anwendungen nutzen. OpenAI betreibt die Agentenschleife, während die Anwendung Aufgaben liefert und Ergebnisse empfängt. Der Vorteil liegt in weniger eigener Infrastruktur rund um das Modell; Entscheidungen über Werkzeuge und Zugriffe bleiben beim Entwickler. [1] [2]
Was unterscheidet die Agents API von Responses und dem Agents SDK?
Der wichtigste Unterschied ist, wer den Agenten betreibt. Bei der Agents API hostet OpenAI den Harness. Beim Agents SDK führt dein Code ein Framework aus, das die Schleife steuert. Bei direkter Nutzung der Responses API übernimmt deine Anwendung mehr Verantwortung für die Schritte zwischen den Modellantworten. OpenAIs Architektur- und SDK-Dokumentation grenzen diese Wege ausdrücklich ab. [2] [9]
Ein Harness ist die Software rund um ein Modell, die eine Aufgabe voranbringt: Sie liefert Kontext, ruft Werkzeuge auf und steuert den nächsten Modellaufruf. Ein einzelner Aufruf ist nur ein Teil dieser Arbeit. OpenAI nennt Sitzungsverwaltung, Kontextkomprimierung und parallele Delegation als Bestandteile des verwalteten Angebots. Kontextkomprimierung verkürzt den angesammelten Kontext, damit der Agent bei wachsenden Gesprächen weiterarbeiten kann. [1]
| Verantwortung | Responses API | Agents SDK | Agents API |
|---|---|---|---|
| Agentenschleife | Deine Anwendung | SDK in deiner Laufzeitumgebung | Von OpenAI gehostet |
| Typischer Grund für die Wahl | Jeden Schritt steuern | Mit einem Agentenframework bauen | Verwalteten Harness nutzen |
| Anwendungsspezifische Regeln | Definierst du | Definierst du | Definierst du |
Ich sehe darin eine Betriebsentscheidung. Wenn die Pflege der Schleife dein Produkt aufhält, kann es sinnvoll sein, OpenAI damit zu beauftragen. Wenn dagegen die Kontrolle über jeden Übergang dein Produkt ausmacht, solltest du diesen Tausch vor einer Migration prüfen. Eine neue API macht eine bestehende SDK-Anwendung nicht überflüssig.
Eine Reddit-Diskussion in r/artificial am 10. September enthielt beide Reaktionen: Interesse an Agenten als Infrastruktur und Fragen zur Sandbox-Grenze. Das ist ein nützlicherer Ausgangspunkt als die Frage, ob noch ein Agentenframework gerade gefragt ist. Entscheidend ist, welche Verantwortung du abgeben möchtest. [8]
Behält eine persistente Sitzung alle Dateien des Agenten?
Eine persistente Sitzung bewahrt das Gespräch und die gespeicherte Arbeit des Agenten auf. Die Ausführungsumgebung hat aber eine eigene Lebensdauer. OpenAIs Architektur trennt Anwendung, gehosteten Harness und Umgebung. Alle drei als einen dauerhaft bestehenden Computer zu behandeln, wäre ein Fehler. [2] [3]
In der Umgebung führen Werkzeuge Code aus und greifen auf einen Arbeitsbereich zu. OpenAI kann sie hosten, oder der Entwickler stellt sie bereit. Ein Agent kann auch ohne diese Umgebung arbeiten: Die dokumentierte Option none bietet weder integriertes Bash noch das apply-patch-Werkzeug oder ein Workspace-Dateisystem. Entfernte MCP-Werkzeuge über HTTP bleiben möglich. MCP ist das Protokoll, über das externe Werkzeuge angebunden werden. [2]
Laut Sitzungsdokumentation soll dieselbe Sitzungskennung für Folgeaufgaben wiederverwendet werden. Außerdem unterscheidet OpenAI gespeicherte Sitzungseinträge von Live-Ereignissen: Ein unterbrochener Stream spielt verpasste Ereignisse nicht vollständig nach. Beim Wiederverbinden muss die Anwendung daher gespeicherte Einträge abrufen. Das technische Detail wirkt sich direkt auf das Produkt aus. Die Oberfläche muss den tatsächlichen Aufgabenstand wiederherstellen, statt aus fehlenden Ereignissen auf fehlende Aktivität zu schließen. [3]
Für Dateien würde ich die Übergabe ausdrücklich festlegen: Was muss der Agent erzeugen, wohin kopiert die Anwendung es und welches Ergebnis bedeutet, dass die Aufgabe erledigt ist? Das gehört zum Produktentwurf, auch wenn der Anbieter die Sitzung verwaltet. Ein erfolgreiches Gespräch ist noch kein zuverlässig ausgeliefertes Arbeitsergebnis.
Haben parallele Subagenten eigene Berechtigungen?
Die dokumentierten Subagenten teilen Dateisystem und Umgebung des Koordinators und erben den konfigurierten Werkzeugzugriff. Ich würde sie als Arbeitsinstanzen innerhalb desselben Sicherheitsbereichs behandeln. OpenAI nennt außerdem eine konkrete Beta-Einschränkung: Subagenten unterstützen keine Function Tools. [4]
Das ist für den Anwendungsentwurf relevant. Ein Function Tool stellt eigene Anwendungsfunktionen bereit; entfernte MCP-Werkzeuge sind ein anderer Integrationsweg. Hängt eine Aufgabe von einer eigenen Funktion ab, darfst du nicht voraussetzen, dass der Subagent durch die Delegation dieselben Fähigkeiten wie der Koordinator erhält. Prüfe den unterstützten Werkzeugzugriff, bevor du ihm das gesamte Ergebnis überträgst.
Ich würde mit unabhängigen Aufgaben und klaren Ergebnissen beginnen, etwa der Untersuchung unterschiedlicher Module. Die abschließende Integration bliebe beim Koordinator. Gemeinsame Dateien erleichtern die Zusammenarbeit, ermöglichen aber auch überlappende Änderungen. Parallelität hilft, wenn die Ergebnisse zusammenpassen, ohne dass Agenten gegenseitig ihre Arbeit rückgängig machen müssen.
Auch das Kostenmodell ändert sich. OpenAI weist darauf hin, dass zusätzliche Subagenten mehr Token verbrauchen können. Ein kürzerer Durchlauf kann insgesamt mehr Arbeit enthalten. „Früher fertig“ und „günstiger“ sollten deshalb getrennt gemessen werden. [4]
Welche Sicherheits- und Datenentscheidungen bleiben bei dir?
Die Berechtigungen der Umgebung bleiben entscheidend, weil vom Agenten ausgeführter Code auf die dort verfügbaren Dateien, Zugangsdaten und Netzwerkressourcen zugreifen kann. OpenAIs Sandbox-Leitfaden empfiehlt, ausgehende Verbindungen einzuschränken und den API-Schlüssel der Anwendung außerhalb der Ausführungsumgebung zu halten. Der Betrieb der Schleife legt nicht fest, welche Geschäftssysteme der Agent verändern darf. [5]
Für einen Code-Review-Assistenten würde ich mit Zugriff auf das Repository und einem Ort für Findings beginnen. Die Erlaubnis, Deployments auszuführen oder Kundendatensätze zu ändern, wäre eine eigene Produktentscheidung. Die wichtige Grenze ist die Aktion, die deine Anwendung ermöglicht, nicht die vorsichtige Selbstdarstellung des Agenten.
Ein zustandsbehafteter Dienst kann gut zu wiederkehrenden Nutzern und laufenden Aufgaben passen. Die Anwendung braucht dann aber einen bewusst festgelegten Lebenszyklus für diesen Zustand. Ich würde als Teil der Funktion entscheiden, wann Sitzungen aufbewahrt oder gelöscht werden sollen, bevor sie sich unbegrenzt ansammeln.
Was kostet die Agents API?
OpenAI verlangt laut Ankündigung keine zusätzliche Gebühr für die Agents API. Bezahlt werden die Token und Werkzeuge, die Agenten nutzen. Das relevante Budget umfasst damit die gesamte Aufgabe samt wiederholten Modellaufrufen und delegierter Arbeit. Ein Agent mit langer Laufzeit arbeitet dadurch nicht kostenlos weiter. [1]
Die Preisseite trennt Modell-Token von Werkzeugkosten. Gehostete Ausführungscontainer werden nach Ressourcen und Zeit abgerechnet; Werkzeuge wie die Websuche können zusätzliche Gebühren pro Aufruf verursachen. Eine Kostenschätzung sollte deshalb die gewählte Ausführungsumgebung enthalten, nicht nur die Ausgabe-Token des Modells. [10]
Die Dokumentation zur Beobachtbarkeit nennt eine wichtige Einschränkung der angezeigten Zähler. Nutzungswerte für Sitzungen und Turns können unvollständig sein oder sich ändern. OpenAI sagt ausdrücklich, dass diese Werte keine endgültige Rechnung sind. Sie helfen, einen Lauf zu verstehen; die tatsächlichen Ausgaben sollten mit den Abrechnungsdaten abgeglichen werden. [7]
Meine erste Evaluation wäre deshalb eine kleine, wiederholbare Aufgabe mit einer klaren Abschlussbedingung. Ich würde festhalten, ob das Ergebnis die Prüfung besteht, welche externen Aktionen stattgefunden haben und was die abgeschlossene Aufgabe kostet. Anschließend würde ich das mit meiner bestehenden Anwendung vergleichen, einschließlich ihres Wartungsaufwands.
Die Agents API kommt infrage, wenn der Betrieb der Agenteninfrastruktur das Produkt belastet. Die erste Frage ist konkret: Welche Verantwortung für Schleife, Zustand und Ausführung kann OpenAI übernehmen, ohne deiner Anwendung benötigte Kontrolle zu nehmen?