OpenAI bringt Codex und GPT-5.5 auf Amazon Bedrock

AWS hat am 1. Juni 2026 angekündigt, dass GPT-5.5, GPT-5.4 und Codex von OpenAI allgemein auf Amazon Bedrock verfügbar sind. Nach Angaben des Unternehmens lassen sich die Modelle für Produktions-Workloads einsetzen; auch Codex kann seine Inferenz über Bedrock beziehen.

Für Unternehmen mit einer bereits freigegebenen Bedrock-Umgebung verkürzt das den Weg in den Betrieb. Der Modellzugang kann über dieselbe Cloud-Plattform laufen, die intern schon für Abrechnung und Sicherheitsvorgaben vorgesehen ist.

Codex nutzt Bedrock als Inferenzschicht

Codex lässt sich laut AWS über die Codex App und die CLI sowie über Integrationen für Visual Studio Code, JetBrains und Xcode verwenden. Die eigentliche Änderung liegt unter der Oberfläche: Modellanfragen können über Amazon Bedrock laufen.

Die Integration spart einen separaten Zugang. Ein Plattformteam muss für den Coding-Agenten nicht zwingend eine weitere Abrechnungs- und Modellverbindung neben der bestehenden AWS-Umgebung etablieren.

Für Codex auf Bedrock gelten nach Angaben von AWS Pay-per-Token-Preise. Eine separate Launch-Meldung des Unternehmens bezeichnet sie als entsprechend den OpenAI-First-Party-Raten und nennt die Anrechnung auf bestehende AWS-Commitments. Für die Beschaffung kann diese Einordnung wichtiger sein als eine zusätzliche Editor-Funktion, weil die Nutzung in vorhandenen Cloud-Verträgen sichtbar wird.

GPT-5.5 und GPT-5.4 sind allgemein verfügbar

Auch GPT-5.5 und GPT-5.4 stehen laut AWS allgemein auf Bedrock bereit. Das Unternehmen beschreibt GPT-5.5 als OpenAIs leistungsfähigstes Modell und nennt unter anderem Coding sowie mehrstufige autonome Aufgaben als Einsatzfelder. Die Modelle laufen demnach auf der Bedrock-Inferenz-Engine.

Der Status „allgemein verfügbar“ ist entscheidend. AWS spricht ausdrücklich von Produktions-Workloads, sodass Plattformverantwortliche den Zugang anders bewerten können als eine Preview mit eingeschränkter Verfügbarkeit.

Ein Qualitätssiegel ist das nicht. Die Ankündigung belegt weder die Eignung für jede Codebasis noch die Zuverlässigkeit eines konkreten Agenten-Workflows. Blockchain.News bestätigt in seinem Bericht vor allem die öffentliche Einordnung als OpenAI-Start auf Bedrock und liefert im verfügbaren Ausschnitt kaum zusätzliche technische Details.

Was sich beim Rollout ändert

Ein Coding-Agent berührt schnell mehr als den Modellzugang. Sobald Codex ein Repository analysiert, Änderungen vorbereitet und einen Pull Request anlegt, werden Berechtigungen und Review-Grenzen Teil des Systems.

Bedrock kann dabei als kontrollierter Zugang zur Inferenz dienen. AWS verweist auf die Sicherheits- und Governance-Funktionen der Plattform. Die Verantwortung für das Repository bleibt jedoch im Unternehmen: Welche Dateien darf der Agent lesen, welche Änderungen darf er vorbereiten und wer gibt sie frei?

Die Trennung ist wichtig. Ein freigegebener Bedrock-Zugang schützt nicht automatisch Geheimnisse im Quellcode und ersetzt keine Prüfung erzeugter Änderungen. Er bringt den Modellaufruf näher an bestehende AWS-Prozesse; die Agentenrechte müssen weiterhin separat begrenzt werden.

Ein sinnvoller Test vor dem Rollout

AWS verweist für die regionale Verfügbarkeit auf die Bedrock-Regionsseite. Vor einer Einführung müssen Plattformteams deshalb prüfen, ob Modell und Inferenzweg in der benötigten Region bereitstehen und zu den internen Vorgaben passen.

Der Modellzugang ist nur der Anfang.

Für einen belastbaren Test reicht ein abgegrenztes Repository ohne produktive Geheimnisse. Codex sollte dort eine überschaubare Änderung vorbereiten, während das Team kontrolliert, welche Inhalte an Bedrock gehen, wie die Kosten im AWS-Konto erscheinen und ob der Review-Prozess jede Änderung vor dem Merge stoppt. Dieser Ablauf zeigt schneller als eine Feature-Liste, ob die Integration in der eigenen Entwicklungsumgebung trägt.

Codex wird durch Bedrock nicht leistungsfähiger als das zugrunde liegende Modell. Für Unternehmen, die ihren KI-Zugang bereits über AWS steuern, lässt sich der Coding-Agent damit aber einfacher in vorhandene Plattformprozesse einordnen. Aus einem separaten Werkzeug kann so ein kontrollierbarer Bestandteil der Entwicklungsumgebung werden.