OpenAI startet die Agents API: Was Cloud-Agenten jetzt können

Was OpenAI am 10. September veröffentlicht hat

Die Agents API ist eine neue verwaltete Schnittstelle für Cloud-Agenten. Eine Anwendung beschreibt Aufgabe, Modell, Werkzeuge und Ausführungsumgebung; OpenAI betreibt den Codex-Harness, verwaltet die Agenten-Session und liefert Ereignisse sowie Ergebnisse zurück. Der Startstatus ist ausdrücklich Public Beta und damit noch keine allgemein verfügbare, vollständig stabilisierte Produktionsfreigabe.

OpenAI nennt die API für alle Entwickler verfügbar. Im Unterschied zu einem einzelnen Modellaufruf kann eine Session über mehrere Arbeitsschritte und Kontextfenster bestehen, nach Unterbrechungen fortgesetzt und während der Ausführung gesteuert werden. Die Anwendung kann Fortschritt als Ereignisstrom verfolgen oder Webhooks für Statusänderungen verwenden.

Ereignisdatum: 10. September 2026. Bestätigt ist eine öffentliche Beta. OpenAI kündigt schnelle Änderungen bis zur allgemeinen Verfügbarkeit an.

Der Codex-Harness ist mehr als ein weiterer API-Endpunkt

Bei klassischen Modell-APIs baut das Entwicklungsteam große Teile der Agentenlogik selbst: Kontext verwalten, Werkzeugaufrufe koordinieren, Fehler auffangen und lange Abläufe wieder aufnehmen. Die Agents API verschiebt diese Aufgaben in einen von OpenAI betriebenen Harness. Er kann frühere Arbeit zusammenfassen, die Session fortsetzen, Werkzeuge verfügbar machen und Teilaufgaben koordinieren.

Die Kernlogik des Codex-Harness ist öffentlich im OpenAI-Codex-Repository einsehbar. Das schafft Transparenz über die Grundlage, bedeutet aber nicht, dass der komplette verwaltete Dienst einschließlich Infrastruktur und Betriebsprozessen als lokal identische Open-Source-Distribution bereitsteht. Wer eine feste Laufzeitversion benötigt, sollte die angebotene Versionierung und Änderungen während der Beta genau dokumentieren.

Langlebige Sessions halten Arbeit und Kontext zusammen

Eine Session ist eine dauerhafte Instanz eines Agenten. Sie enthält Konfiguration, Eingaben, Ereignisse und erzeugte Arbeitsergebnisse. OpenAI verwaltet Kontextkomprimierung und Wiederaufnahme, sodass Anwendungen längere Aufgaben nicht nach jedem Kontextfenster von vorn zusammensetzen müssen.

Dauerhaft heißt nicht unbegrenzt laufender Computer. Bei OpenAI-gehosteten Sandboxes kann die Umgebung nach einer Stunde ohne Aktivität und Keep-alives gelöscht werden; dieser Zeitraum ist laut Dokumentation nicht konfigurierbar. Veröffentlichte Artefakte bleiben abrufbar, und benötigte Ergebnisse sollten vor dem Löschen einer Session gesichert werden.

Werkzeuge und Subagenten erweitern den Aktionsraum

Der Harness unterstützt MCP-Verbindungen, eigene Funktionen und integrierte Werkzeuge wie Websuche. Tool Search kann Werkzeugdefinitionen erst bei Bedarf laden; programmgesteuerte Werkzeugaufrufe können mehrere Operationen parallel ausführen und Ergebnisse vor der Rückgabe in den Modellkontext filtern.

Mit Multi-Agent-Unterstützung kann der Hauptagent unabhängige Teilaufgaben an Subagenten verteilen. Jeder Subagent arbeitet in einem eigenen Kontext, während der Hauptagent die Ergebnisse zusammenführt. Das ist besonders für Recherche, Analyse und Softwarearbeit interessant, erhöht aber zugleich Zahl der Modellaufrufe, mögliche Fehlerpfade und den Prüfaufwand.

Leistungswerte aus den Kundenzitaten der Startseite sind Erfahrungsberichte ausgewählter Unternehmen. Sie sind keine unabhängigen Benchmarks und lassen sich nicht pauschal auf andere Workloads übertragen.

Drei Wege für die Ausführungsumgebung

Entwickler können eine von OpenAI verwaltete Linux-Sandbox, eigene Infrastruktur oder eine integrierte Partnerumgebung wählen. Die gehostete Variante bringt Python, Node.js und Kommandozeilenwerkzeuge mit und kann Pakete, Eingabedateien, Skills und Plugins erhalten. Für eigene Images, private Netzwerke oder besondere Rechenanforderungen verweist OpenAI auf selbst gehostete oder Partner-Sandboxes.

Bei gehosteten Sandboxes ist ausgehender Netzwerkzugriff standardmäßig aktiviert, sofern keine strengere Vorlagenregel greift. Er lässt sich vollständig deaktivieren oder auf eine Liste exakter Hosts begrenzen. Für sensible Abläufe sollte die Standardkonfiguration deshalb nicht ungeprüft übernommen, sondern auf die tatsächlich benötigten Ziele reduziert werden.

• Netzwerkzugriff deaktivieren, wenn die Aufgabe keine externen Dienste benötigt
• Bei eingeschränktem Zugriff auch Subdomains und Weiterleitungsziele einzeln prüfen
• Pakete und Laufzeitabhängigkeiten auf feste Versionen setzen
• Ausgaben in einem definierten Verzeichnis speichern und vor dem Löschen sichern
• Eigene oder Partner-Sandboxes wählen, wenn private Netze oder spezielle Images erforderlich sind

Eine Sandbox ersetzt keine sparsame Rechtevergabe

Agent-generierter Code kann innerhalb der Umgebung auf dort verfügbare Dateien und Variablen zugreifen. OpenAI empfiehlt deshalb getrennte Schlüssel: Der Anwendungsschlüssel bleibt außerhalb der Sandbox, während der Executor nur einen eingeschränkten Umgebungsschlüssel erhält. Langfristige Zugangsdaten sollten in einem Secret Manager liegen und nach Möglichkeit über einen Credential Broker nur für genehmigte Ziele und Anfragen eingesetzt werden.

Werkzeuge, Webinhalte und MCP-Server erweitern die Angriffsfläche. Eine manipulierte Quelle kann versuchen, den Agenten zu unerwünschten Aktionen zu bewegen. Für schreibende oder irreversible Schritte braucht es daher eigene Freigaberegeln, minimale Berechtigungen, kontrollierte Netzwerkziele und eine Prüfung der erzeugten Aktionen. Die Existenz einer Sandbox allein belegt nicht, dass verbundene Konten oder externe Systeme vor Fehlentscheidungen geschützt sind.

• Anwendungsschlüssel nie in Dateien, Quellcode, Logs oder die Agentenumgebung legen
• Für jede Verbindung nur die minimal erforderlichen Lese- oder Schreibrechte vergeben
• Drittanbieter-Zugangsdaten über einen Broker statt direkt in die Sandbox geben
• E-Mail-Versand, Deployments, Käufe und Löschungen ausdrücklich freigeben lassen
• Schlüssel bei Verdacht auf Offenlegung sofort sperren oder rotieren

Datenresidenz und Zero Data Retention sind klare Grenzen

Die Agents API speichert Session-Zustand, damit Arbeit über mehrere Runden fortgesetzt werden kann. Sessions und veröffentlichte Artefakte lassen sich laut Dokumentation löschen. Für Datenschutz- und Compliance-Prüfungen ist jedoch entscheidend, dass die API aktuell nur Datenresidenz in den Vereinigten Staaten unterstützt.

Zero Data Retention wird derzeit nicht unterstützt. Eine selbst gehostete Sandbox ändert diese Einstufung ausdrücklich nicht, weil Session- und Harness-Daten weiterhin über den verwalteten API-Dienst laufen. Organisationen mit europäischen Speicheranforderungen, besonderen Geheimhaltungsregeln oder ZDR-Pflicht sollten deshalb vor einem Produktiveinsatz Datenarten, Rechtsgrundlage, Aufbewahrung und Löschprozess vollständig klären.

Offizielle Produktgrenze zum Stand 12. September 2026: nur US-Datenresidenz und keine ZDR-Unterstützung. Self-Hosting der Sandbox hebt diese Einschränkung nicht auf.

Kein API-Aufpreis bedeutet nicht kostenloser Agentenbetrieb

OpenAI verlangt nach eigener Aussage keine zusätzliche Grundgebühr für die Agents API. Abgerechnet werden die ausgewählten Modelle zu ihren API-Raten, OpenAI-Werkzeuge zu deren Standardpreisen und gehostete Sandboxes zu Containerpreisen. Hinzukommen können Kosten von MCP-Diensten, Partner-Sandboxes oder anderen Drittanbietern.

Ein Agent kann für eine Aufgabe viele Modellaufrufe ausführen. Subagenten, Wiederholungen, lange Historien und Werkzeugergebnisse erhöhen die Tokenmenge. Die dokumentierten Nutzungsfelder sind Best-Effort-Werte, können zeitweise fehlen und stellen keine endgültige Rechnung dar. Belastbare Kostenvergleiche müssen deshalb eine vollständige Aufgabe einschließlich Fehlversuchen und Nebenleistungen messen.

Was während der Public Beta noch offen bleibt

OpenAI stellt viele Funktionen bereit, veröffentlicht zum Start aber keine allgemeine Erfolgsquote für reale Agentenaufgaben. Wie zuverlässig lange Sessions bei wechselnden Werkzeugen, fehlerhaften Webseiten, rate-limitierten Diensten oder widersprüchlichen Anweisungen arbeiten, hängt stark vom jeweiligen System ab und muss separat evaluiert werden.

Auch die Betriebsoberfläche hat Beta-Grenzen: Detaillierte Traces sind im Plattform-Dashboard sichtbar, aber Trace-Abruf und externe Trace-Exporter gehören laut Dokumentation nicht zur öffentlichen Beta-API. Teams sollten deshalb prüfen, ob Ereignisstrom, Session-Historie und eigene Telemetrie ihre Anforderungen an Auditierbarkeit und Fehleranalyse erfüllen.

• Keine herstellerunabhängige Erfolgsquote über unterschiedliche Aufgabentypen
• Keine Zusage unveränderter Schnittstellen bis zur allgemeinen Verfügbarkeit
• Trace-Export nicht Teil der öffentlichen Beta-API
• Nur US-Datenresidenz und keine Zero Data Retention
• Gesamtkosten hängen von allen Modell-, Werkzeug-, Sandbox- und Drittanbieteraufrufen ab

So lässt sich die Agents API belastbar testen

Ein sinnvoller Pilot beginnt mit einer reversiblen, klar messbaren Aufgabe und Testdaten. Vor dem Lauf werden erlaubte Werkzeuge, Netzwerkziele, Zeit- und Kostenlimits sowie Aktionen festgelegt, die menschliche Freigabe benötigen. Danach werden nicht nur Endergebnis, sondern auch Werkzeugaufrufe, Subagentenarbeit, Fehler, Eingriffe und Tokenverbrauch ausgewertet.

Der Vergleich sollte gegen den bisherigen Prozess oder eine einfachere API-Lösung erfolgen. Relevant sind Erfolgsquote, Qualität, Laufzeit, Kosten pro abgeschlossener Aufgabe und Schwere möglicher Fehlaktionen. Erst nach wiederholbaren Ergebnissen sollten produktive Daten, Schreibrechte oder weitere Systeme hinzukommen.

• Mit einer begrenzten Aufgabe und nicht sensiblen Testdaten starten
• Ein festes Erfolgsmaß und Abbruchbedingungen vor dem Lauf definieren
• Netzwerk, Tools und Schlüssel auf das Minimum begrenzen
• Root-Agent, Subagenten, Wiederholungen und Drittanbieter gemeinsam bepreisen
• Fehlerfälle und manipulierte Werkzeugausgaben bewusst testen
• Session und Artefakte nach dem Test kontrolliert löschen

Die MindrAils-Einordnung

Die Agents API ist ein wichtiger Plattformstart, weil OpenAI nicht nur ein stärkeres Modell, sondern den operativen Unterbau für lange, werkzeuggestützte Agenten anbietet. Teams können damit schneller experimentieren, ohne Kontextverwaltung, Subagenten-Orchestrierung und Wiederaufnahme vollständig selbst zu bauen.

Der Komfort verlagert Verantwortung, hebt sie aber nicht auf. Datenresidenz, fehlende ZDR-Unterstützung, externe Werkzeuge, lesbare Umgebungsschlüssel und variable Kosten bleiben Architekturentscheidungen des Betreibers. Die Beta ist deshalb am überzeugendsten als kontrollierte Agentenplattform für klar eingegrenzte Aufgaben, nicht als Freifahrtschein für autonome Zugriffe auf produktive Systeme.