OpenAI macht Ultrafast zum Standard bei Incidents – Belege für den Zeitgewinn fehlen

OpenAI macht Ultrafast zum Standard bei Incidents

Ultrafast, ein Hochgeschwindigkeitsmodus in Codex, gilt bei OpenAI-Ingenieuren in der Incident-Response als Standard. So steht es in einem Beitrag des Unternehmens. Begründet wird das mit dem Zeitdruck: Bei einem Störfall wartet niemand gern minutenlang auf eine Antwort, während das Problem wächst. Mit Ultrafast lassen sich mehrere mögliche Ursachen parallel untersuchen, ohne die Aufmerksamkeit zu zersplittern.

Der Text gehört zu einer Reihe, in der OpenAI interne Anwendungsbeispiele für die eigene Technik und die eigenen APIs vorstellt. Nach eigenen Angaben nutzt das Unternehmen die Werkzeuge intern; geteilt werden sie als illustrative Beispiele. Das ist Herstellerdarstellung und keine unabhängige Auswertung. Wann Ultrafast eingeführt wurde, geht aus dem Material nicht hervor.

Codex im Slack-Channel durchsucht mehrere Ursachen zugleich

Aaron Friel, Member of the Technical Staff bei OpenAI, übernimmt bei Incidents oft die Koordination. Er eröffnet einen Slack-Channel und lässt Codex dort überwachen, untersuchen und eingehende Fragen beantworten. Meist gebe es bei einem Incident viele Stellen, an denen etwas schiefgelaufen sein könne. Entscheidend sei, die richtige Nadel im richtigen Heuhaufen zu finden. Mit Ultrafast könne er „im Grunde alle Heuhaufen gleichzeitig durchsuchen“ und schneller reagieren.

Das ist eine subjektive Selbsteinschätzung. Einen Messwert nennt der sichtbare Ausschnitt nicht.

AJ Trbojevic, Member of the Technical Staff und Datacenter Security Architect, sagt, Untersuchungen zu Sicherheitsproblemen hätten früher ein bis zwei Stunden gedauert. Der Satz bricht im vorliegenden Ausschnitt ab, die neue Dauer fehlt. Die im Titel des Beitrags genannte Verkürzung auf Minuten lässt sich anhand des Ausschnitts nicht nachvollziehen.

Reviewer-Test: Vorteil je nach Aufgabe zwischen etwa 2,6- und nahezu 8-fach

Ultrafast werde laut einem Reviewer als achtmal schneller als der Standardmodus und viermal schneller als der reguläre Fast-Modus beworben. Die OpenAI-Primärquelle nennt diese Faktoren im Ausschnitt nicht. Sie stammen allein vom Reviewer.

Dessen Test zeigt ein uneinheitliches Bild. Je nach Aufgabe lag der Vorteil zwischen etwa dem 2,6-Fachen (19 statt 50 Minuten) und nahe dem 8-Fachen (1:43 Minuten statt 13). Bei der aufwendigsten Aufgabe lag der Limitverbrauch zugleich bei rund dem 4,25-Fachen. Ein Reddit-Nutzer wiederum sieht den Endpunkt kaum über 100 Tokens pro Sekunde und keinen Fortschritt gegenüber Fast und Standard.

Die Zahlen widersprechen sich nur scheinbar. Die Quellen messen Verschiedenes: OpenAI beschreibt die Wanduhrzeit bei Incident-Arbeit mit parallelen Untersuchungen, der Reviewer Einzelaufgaben unterschiedlicher Komplexität, der Forenbeitrag den Token-Durchsatz. Der Achtfach-Wert dürfte ein Bestwert sein, der nur bei manchen Aufgaben erreicht wird. Alle Angaben sind Einzelfälle ohne gemeinsame Methodik; ein direkter Vergleich mit den Angaben von OpenAI ist daher nicht möglich.

Offen bleiben Technik, Tarife und Aktivierung

Ungeklärt bleiben nach den vorliegenden Belegen die technische Umsetzung, die Tarife, die Aktivierung und das Einführungsdatum von Ultrafast. In der API-Preisdokumentation wurde „Priority processing“ am 30. Juli 2026 in „Fast mode“ umbenannt. In Anfragen funktionieren service_tier „priority“ und „fast“. Ultrafast ist dort im vorliegenden Ausschnitt nicht erwähnt.

Für Teams mit Incident-Rolle heißt das: Sie müssten höheren Limitverbrauch gegen Tempo abwägen, ohne belastbare Vergleichsdaten. Belastbar wäre erst eine Messreihe mit Zahl der Incidents, Methode und Ausgangsbasis.