AIREITERDer OpenAI DevDay 2026 war mehr als eine Bühne für neue Modelle. Im Rückblick vom 29. September verknüpft OpenAI ein günstigeres Arbeitsmodell mit einer verwalteten Agenten-Laufzeitumgebung, cloudbasierten Entwicklungsumgebungen und einem dauerhaft aktiven Consumer-Agenten. Für Entwickler liegt die eigentliche Neuerung in der Architektur: Immer mehr Bestandteile rund um das Modell – Sitzungen, Tools, Umgebungen und Hintergrundausführung – wandern in von OpenAI verwaltete Produkte.
Das Entwickler-Fazit
GPT-6.1 Sol ist die derzeit klarste API-Neuheit mit kurzfristigem Nutzwert. OpenAI führt das Modell unter gpt-6.1-sol; es unterstützt die Responses API, Tool-Aufrufe, Computer Use und MCP. Die Agents API ist eine öffentliche Beta zum Bau verwalteter Agenten nach dem Codex-Prinzip. Codex Cloud macht asynchrones Programmieren zu einem gehosteten Workflow. Dots demonstriert dieselbe strategische Richtung für Endkunden, ist aber kein Ersatz für eine Entwickler-API.
Die praktische Empfehlung lautet daher: Sol und die Agents API zuerst testen, Codex Cloud dort einsetzen, wo Remote-Ausführung Abstimmungsaufwand spart, und Dots eher als Produktsignal denn als stabile Integrationsoberfläche betrachten.
Was tatsächlich gestartet ist – und was noch ausgerollt wird
Der offizielle DevDay-Rückblick beschreibt mehr als 20 Neuheiten. Für Entwickler sind allerdings nicht alle vier relevanten Produkte gleich weit.
| Produkt | Funktion | Wovon Entwickler ausgehen sollten |
|---|---|---|
| GPT-6.1 Sol | Kostengünstigeres Modell für Programmierung, Computer Use und professionelle Aufgaben | Als gpt-6.1-sol in der API verfügbar; Zugriff hängt von Tarif und Produkt ab |
| Agents API | Verwaltetes Codex-Harness mit Tools, Sitzungen, Orchestrierung und gehostetem Computer Use | Öffentliche Beta |
| Codex Cloud | Remote-Entwicklungsumgebungen für delegierte Programmieraufgaben, die sich wiederverwenden lassen | Schrittweiser Produkt-Rollout; Limits und Integrationen unterscheiden sich |
| Dots | Dauerhaft aktiver Agent mit Cloud-Computer und verbundenen Apps | Beta beziehungsweise schrittweiser Rollout mit Tarif- und Markteinschränkungen |
Für den API-Zugriff ist die Modelldokumentation von OpenAI die maßgebliche Quelle. Den Beta-Status der Agents API beschreibt die Ankündigung zur Agents API. Keine der beiden Seiten sollte als Zusage identischer Kontingente oder regionaler Verfügbarkeit für jedes Konto verstanden werden.
GPT-6.1 Sol macht Agenten-Schleifen günstiger
In der Ankündigung zu GPT-6.1 Sol beschreibt OpenAI Sol als Weiterentwicklung von GPT-6 Sol. Bei Programmieraufgaben und Computer Use soll es an die Leistung von Astra heranreichen, dabei aber geringere Betriebskosten verursachen. RuntimeWire berichtet für die von OpenAI veröffentlichten Preise 2 Dollar pro Million Eingabe-Token, 0,10 Dollar pro Million gecachter Eingabe-Token und 10 Dollar pro Million Ausgabe-Token. Wiederkehrender Kontext wird damit deutlich günstiger, wenn eine Anwendung gecachte Eingaben wiederverwenden kann, statt den Kontext jedes Mal neu zu übertragen.
| Kostenpunkt | Auf dem DevDay genannter Preis für GPT-6.1 Sol |
|---|---|
| Eingabe | 2 $ / Million Token |
| Gecachte Eingabe | 0,10 $ / Million Token |
| Ausgabe | 10 $ / Million Token |
Diese Preisstruktur kommt Agenten-Workflows mit langen Anweisungen, Tool-Verläufen oder wiederkehrendem Projektkontext entgegen. Sie macht jedoch nicht jede Aufgabe billig: Ausgabelastige Schleifen, Wiederholungsversuche, Browser-Aktionen und externe Tool-Kosten können die Rechnung dominieren. OpenAIs Formulierung „nahe an Astra“ ist eine qualitative Einordnung und ersetzt keinen Test mit dem eigenen Repository, den eigenen Tool-Schemata und dem verfügbaren Fehlertoleranz-Budget.
Ein sinnvoller erster Versuch besteht darin, 20–50 repräsentative Aufgaben mit Sol und dem aktuell produktiv eingesetzten Modell auszuführen. Erfasst werden sollten erfolgreiche Abschlüsse, die Reparaturrate bei Tool-Aufrufen, Latenz und Gesamtzahl der Token. So zeigt sich, ob der niedrigere Token-Preis auch nach dem zusätzlichen Orchestrierungsaufwand bestehen bleibt.
Agents API: Vom Modellaufruf zur verwalteten Ausführung
Die Agents API ist die folgenreichste Entwickler-Ankündigung, weil sie über die reine Modellauswahl hinausgeht. OpenAI beschreibt ein verwaltetes Codex-Harness, das Sitzungen, Orchestrierung, Kontextkomprimierung und Wiederherstellung übernimmt. Entwickler liefern dafür die Tools und Ausführungsumgebungen.
Die Ankündigung der öffentlichen Beta und die Berichte zum Start nennen Codeausführung, Dateibearbeitung, MCP-Verbindungen, die Delegation an andere Agenten sowie Computer Use über einen von OpenAI gehosteten Browser. Die API richtet sich an die Laufzeitumgebung eines Agenten – nicht bloß an einen responses.create-Aufruf mit einem längeren System-Prompt.
Für Authentifizierung, Geschäftsberechtigungen, Tool-Design, Freigaberichtlinien, Observability, Domain-Allowlisting, Bestätigungen für sensible Aktionen, Audit-Logs und reproduzierbare Fehlerfälle bleibt die jeweilige Anwendung verantwortlich. Gehostetes Computer Use kann den Aufwand für Browser-Infrastruktur reduzieren, ersetzt diese Kontrollen aber nicht.
„Gibt es Neuigkeiten zur Performance von Sol 6.1 im Vergleich zu Opus 5.5?“ – u/Ashamed-Subject-8573 in einer Diskussion auf r/codex
Diese Frage zeigt die Lücke zwischen Keynote und produktivem Einsatz. Entscheidend sind das Verhalten des bereitgestellten Modells, die Zuverlässigkeit der Tools und die Kosten im eigenen Workload – nicht nur ein Vergleich in der Überschrift. Die Agents API sollte daher als Beta-Laufzeitumgebung bewertet werden und nicht als Beleg dafür, dass jeder Agenten-Workload in OpenAIs verwalteten Stack gehört.
Codex Cloud macht die Laufzeitumgebung zum Produktbestandteil
Codex Cloud erweitert Coding-Agenten über das aktive Terminal des Entwicklers hinaus. Die Berichterstattung zum Start beschreibt wiederverwendbare Umgebungen mit den Repositories, Abhängigkeiten, Tools und Zugriffseinstellungen eines Projekts. Aufgaben können remote vom Desktop, aus dem Web oder per Mobilgerät laufen. Der Entwickler kann später an derselben Arbeit weitermachen, auch wenn der Laptop längst geschlossen ist.
Die Auswirkungen sind vor allem organisatorischer Natur:
- Lange Aufgaben werden asynchron. Code-Reviews, Testreparaturen oder Migrationen können weiterlaufen, ohne dass eine lokale Sitzung geöffnet bleiben muss.
- Umgebungen lassen sich teilen. Teams können einen freigegebenen Workspace definieren, statt für jede Aufgabe Abhängigkeiten erneut einzurichten.
- Übergaben zwischen Mensch und Agent werden einfacher. Entwickler können Diffs prüfen, Sitzungen fortsetzen und entscheiden, was tatsächlich gemergt wird.
- Sicherheit wird zur Deployment-Aufgabe. Repository-Zugriff, Secrets, ausgehender Netzwerkverkehr und Cloud-Identität brauchen klare Richtlinien.
Der DevDay-Rückblick von OpenAI und das bereits erwähnte Produktinventar nennen außerdem eine Agents-Ansicht für die Codex CLI, Sprachsteuerung, Code-Reviews am Desktop und Codex Security Cloud für verbundene GitHub-Repositories. Zusammengenommen wirkt Codex damit weniger wie Autovervollständigung und mehr wie eine remote betriebene Ebene für Engineering-Prozesse.
Codex Cloud ersetzt nicht automatisch die lokale Entwicklungsumgebung. Teams müssen weiterhin Repository-Unterstützung, Installation von Abhängigkeiten, Netzwerkzugriff, Umgang mit Secrets, Sitzungsdauer und die Reproduzierbarkeit fehlgeschlagener Aufgaben prüfen. Für den Einstieg eignen sich risikoarme Wartungsaufgaben besser als produktive Migrationen oder Änderungen an releasekritischem Code.
Dots ist der Beleg für die Consumer-Richtung – nicht die Entwickler-API
Dots zeigt, wohin OpenAI seine Agentenprodukte entwickeln will: zu einem dauerhaft aktiven Assistenten mit eigenem Cloud-Computer, verbundenen Anwendungen, persistentem Kontext und Hintergrundaufgaben. Die Ankündigung zu Dots und die Workspace-Dokumentation beschreiben verbundene Dienste und kontrollierten Zugriff. Berichte zum Start nennen außerdem Wege über ChatGPT, Slack und Microsoft Teams in berechtigten Tarifen und Märkten.
Für Entwickler steht Dots damit für Delegation statt schrittweiser Prompt-Eingabe – wirft aber weiterhin offene Fragen zu Autonomie und Datenschutz auf. Die Workspace-Dokumentation von OpenAI bestätigt, dass der Zugriff über Workspace- und Tarifeinstellungen gesteuert wird; Berichte zum Start nennen ChatGPT, Slack und Microsoft Teams in berechtigten Märkten. Dots ist kein Entwicklervertrag: Vor der Entscheidung für einen gehosteten Agenten sollten Kontrolle, Datenstandort, Tool-Berechtigungen, Auditierbarkeit und Wechselkosten mit der Agents API verglichen werden.
Eine sinnvolle Einführungsreihenfolge für Engineering-Teams
Die vier Neuheiten lassen sich in einer nachvollziehbaren Reihenfolge evaluieren:
- GPT-6.1 Sol mit echten Aufgaben benchmarken. Verwendet Repository-Aufgaben, strukturierte Tool-Aufrufe und repräsentativen Kontext. Berücksichtigt gecachte Eingaben im Kostenmodell.
- Einen eng begrenzten Workflow mit der Agents API bauen. Geeignet sind reversible Aufgaben wie Issue-Triage, Testdiagnose oder Aktualisierungen der Dokumentation. Bevor die Berechtigungen ausgeweitet werden, sollten Freigabestufen greifen.
- Asynchrones Programmieren gezielt nach Codex Cloud verlagern. Testet zunächst eine wiederverwendbare Umgebung mit nicht sensiblen Repositories und dokumentiert anschließend Vorgaben für Secrets und Netzwerkzugriff.
- Dots als Signal für die Produktentwicklung nutzen. Beobachtet Berechtigungen, Integrationen und Verfügbarkeit, macht Dots aber nicht zur Abhängigkeit der eigenen Anwendungsarchitektur.
- Eine Portabilitätsschicht beibehalten. Tool-Definitionen, Prompts, Evaluierungsfälle und Freigabelogik gehören ins eigene Repository. So lässt sich eine Preview-API ersetzen, falls sich Limits oder Verhalten ändern.
Für Sol gibt es einen API-Modelleintrag und veröffentlichte Preise. Die Agents API ist ausdrücklich eine öffentliche Beta. Codex Cloud ist ein gehosteter Workflow mit noch offenen Betriebsfragen. Dots eignet sich am wenigsten als Grundlage für einen Entwicklervertrag.
FAQ
Ist GPT-6.1 Sol in der API verfügbar?
Ja. Die Entwicklerseite zum Modell führt gpt-6.1-sol für die API auf, einschließlich der Responses API und tool-orientierter Funktionen. Zugriff und Limits können je nach Konto und Rollout variieren.
Ist die Agents API allgemein verfügbar?
Nein. OpenAI hat die Agents API als öffentliche Beta angekündigt. Vor dem Einsatz für unumkehrbare Aktionen in der Produktion sollten Evaluierung, Logging und ein Fallback-Weg eingerichtet werden.
Ist Dots eine API, die Entwickler aufrufen können?
Nein. Dots ist ein Agentenprodukt von OpenAI mit eigenem Rollout und eigenen Tarifregeln. Für den Bau verwalteter Agenten ist die Agents API die relevante Entwickleroberfläche.
Ersetzt Codex Cloud eine lokale Entwicklungsumgebung?
Nicht standardmäßig. Codex Cloud ergänzt die lokale Arbeit um Remote-Ausführung und wiederverwendbare Umgebungen. Teams müssen jedoch Repository-Zugriff, Abhängigkeiten, Secrets, Netzwerkrichtlinien, Persistenz und Review-Abläufe selbst validieren.
Was sollten Teams vor der Verlagerung produktiver Arbeit prüfen?
Zu prüfen sind das bereitgestellte Modell, die Kosten inklusive Wiederholungsversuchen und Tool-Aufrufen, der Umgang mit Daten, Berechtigungsgrenzen, Fehlerbehandlung, Observability, regionale Verfügbarkeit sowie ein Ausstiegsszenario für den Fall, dass sich eine Beta-Funktion ändert.
Den entscheidenden Zielkonflikt sollten Entwickler nicht übergehen
Der Zielkonflikt ist klar: Verwaltete Sitzungen und Browser reduzieren den Infrastrukturaufwand. Selbst verwaltete Laufzeiten bieten dafür mehr Kontrolle über Daten, Zugangsdaten, Debugging und Modellwechsel. Startet mit Sol und der Agents API und setzt Codex Cloud anschließend nur dort ein, wo der operative Vorteil eindeutig ist.