GPT-5.6 Sol Ultrafast vs. GPT-5.6 Sol: Gleiche Gewichte, unterschiedliche Service-Stufe

GPT-5.6 Sol Ultrafast ist kein neues Modell, und dies ist keine Launch-Story. Der Anbieter kündigte den Modus am 13. August 2026 an, und am selben Tag erschien der Wert ultrafast im öffentlichen OpenAPI-Schema des Unternehmens, innerhalb der ServiceTierResponses-Beschreibung der Spezifikation – die den Tier nach eigener Formulierung auf den Endpoint gpt-5.6-sol beschränkt und ihn als zugriffskontrolliert kennzeichnet. Was diese Seite wieder in unsere Warteschlange gebracht hat, ist kleiner und spezifischer: Am 25. September 2026 erweiterte Commit fe4f7a1 diesen Wert in zwei weitere Enumerationen, den Service-Tier-Parameter auf Anfrageebene und das Service-Tier-Richtlinienfeld des Agenten. Sechs Wochen nach der Ankündigung steht der Tier immer noch auf der Warteliste, hat weiterhin keinen veröffentlichten Preis und ist jetzt in mehr Teile der API-Oberfläche verdrahtet, als er tatsächlich bedienen kann. GPT-5.6 Sol Ultrafast und GPT-5.6 Sol sind dasselbe Modell; das Einzige, was dieser Vergleich entscheiden kann, ist, wer den Pointer kontrolliert und wer Ihnen die Kosten genannt hat.

Die Gegenüberstellung in der Überschrift ist ungewöhnlich. GPT-5.6 Sol Ultrafast und GPT-5.6 Sol sind dasselbe Modell. Dieselben Gewichte, derselbe Checkpoint, dasselbe Reasoning-Verhalten, dasselbe Kontextfenster von 1,05 Millionen Token, dieselbe maximale Ausgabe von 128K, dieselben Antworten. OpenAIs eigene Darstellung lautet „mehr nützliche Arbeit pro Sekunde“, nicht „ein klügeres Modell“. Das Einzige, was sich zwischen den beiden Spalten dieses Vergleichs unterscheidet, ist, wie die Token erzeugt werden und wie die Stufe in deinem Request-Body heißt – was diesen Vergleich zum saubersten Kontrollexperiment im aktuellen Lineup macht und zugleich zu dem, der am schwersten auszuwählen ist, weil für eine der beiden Stufen überhaupt kein Preis veröffentlicht ist.

Was hat sich diese Woche tatsächlich geändert?

Der Beleg für die September-Änderung ist ein Commit, kein Blogbeitrag. OpenAI pflegt openai-openapi, das Repository, das das maschinenlesbare Schema für seine API veröffentlicht, und Commit fe4f7a1 – datiert auf 2026-09-25 – fügt ultrafast zu zwei Aufzählungen hinzu: der an Agenten gebundenen Service-Tier-Richtlinie und dem Feld auf Anfrageebene, das die Spezifikation als „der für Modellanfragen verwendete Service-Tier“ beschreibt. Das ist eine Erweiterung, kein Debüt: Vor diesem Commit lauteten diese beiden Listen auto, default, flex, priority, fast, und diese Stufe war bereits seit dem 13. August im Schema. Der Commit ist bemerkenswert wegen des Feldes, das er erreicht hat – das Richtlinienfeld, mit dem ein Agent konfiguriert wird, eine andere Oberfläche als eine Überschreibung pro Anfrage.

Die maßgebliche Beschreibung stammt aus dem Commit vom 13. August, nicht aus diesem, und sie ist die spezifischste Aussage, die OpenAI irgendwo über die Stufe veröffentlicht hat. Zusammen mit dem neuen Wert heißt es in der Spezifikation: „Wenn sie auf ‚ultrafast‘ gesetzt wird, wird die Anfrage mit der zugriffskontrollierten Dienststufe Ultrafast Processing verarbeitet. Diese Stufe ist derzeit für gpt-5.6-sol verfügbar; eine darüber ausgelieferte Antwort zeigt service_tier=ultrafast.“

Lesen Sie diesen Satz zweimal, denn er klärt zwei Fragen, die diese Vergleichsseite sonst offenlassen müsste. Die Stufe ist auf ein einziges Modell beschränkt – das Flaggschiff GPT-5.6 Sol und nichts sonst im Lineup –, und sie ist zugangsbeschränkt statt offen, was zu OpenAIs Darstellung einer Preview mit Warteliste passt. Außerdem verrät er Ihnen, woran Sie erkennen würden, dass Sie sie erhalten haben: Die Antwort gibt zurück, welche Stufe die Anfrage tatsächlich bedient hat, sodass ein Rückfall auf die Standardverarbeitung im Response-Body sichtbar ist und nicht aus der Latenz erschlossen werden muss. Dieselbe Beschreibung findet sich sowohl im Standard- als auch im Beta-Responses-Schema – und das seit dem 13. August.

Ein zweites, schwächeres Signal kam am nächsten Tag. Ein Bericht vom 26. September beschreibt einen neuen Speed-Selektor – Fast, Standard und Ultrafast –, der in den Responses API Playground kommt, wobei eine breitere Verfügbarkeit von Ultrafast nach der Entwicklerkonferenz DevDay von OpenAI erwartet wird. Wir haben den Selektor selbst nicht gesehen, und OpenAI hat keine Rollout-Mitteilung veröffentlicht, daher sollten Sie dies als einen Bericht aus einer einzigen Quelle und nicht als bereits ausgelieferte Funktion behandeln. Die Teile, die heute überprüfbar sind, sind die zwei Stellen im öffentlichen Schema und die Tatsache, dass für die Stufe keine Preisliste erschienen ist.

Was sich nicht geändert hat, ist ebenso wichtig. Es gibt weiterhin keinen Ultrafast-Preis. Die Preisseite von OpenAI, gelesen am 27. September, enthält die vier Tabs, die sie zuvor hatte — Standard, Batch, Flex und Fast —, und die Zeichenfolge „ultrafast" erscheint dort nirgends. Der Zugang wird nach wie vor als begrenzte Vorschau für ausgewählte Kunden beschrieben, die mit wachsender Kapazität ausgeweitet wird. Die Stufe steht im Vertrag und gleichzeitig nicht in der Preisliste, und das ist der ehrliche Stand der Dinge.

Die beiden Stufen, Seite an Seite

Da keine Fähigkeit diese beiden voneinander trennt, verengt sich der Vergleich fast vollständig auf Serving und Abrechnung. Jede unten stehende Zeile führt beide Seiten in einer Zeile auf.

• Modell — GPT-5.6 Sol Ultrafast nutzt denselben GPT-5.6 Sol Checkpoint wie die GPT-5.6 Sol Standardverarbeitung, derselbe Checkpoint, keine Destillation, keine Größenreduktion.

• Ausgabedurchsatz — bis zu 750 Ausgabe-Tokens pro Sekunde, bis zu 14× Standard, laut OpenAIs Ankündigung vom 13. August im Vergleich zur standardmäßigen Verarbeitung von GPT-5.6 Sol auf GPU-Clustern, also die Zahl, an der die 14× gemessen wird.

• Hardware — Cerebras-Wafer-Scale-Chips, Gewichte resident im On-Chip-SRAM, das erste Produkt von OpenAIs im Januar 2026 geschlossener Compute-Partnerschaft mit Cerebras, die Berichten zufolge etwa 10 Milliarden US-Dollar über drei Jahre wert sein soll, im Vergleich zur konventionellen GPU-Inferenz, bei der ein Großteil der Zeit für das Verschieben von Gewichten zwischen Speicher und Recheneinheit draufgeht.

• Preis — nicht veröffentlicht mit Stand vom 27. September 2026 vs. 4,00 $ Input / 20,00 $ Output pro Million Tokens, OpenAIs aktueller Aktionspreis, plus 0,40 $ pro Million für gecachten Input.

• Verfügbarkeit — Wartelisten-basierte begrenzte Vorschau für ausgewählte Kunden im Vergleich zum Standard-Zugang, der von jedem mit einem API-Schlüssel aufgerufen werden kann.

• Antworten, die du zurückbekommst — im Prinzip identisch vs. im Prinzip identisch; wenn sie beim selben Prompt auseinandergehen, ist das ein Befund, kein Feature.

Die Geschwindigkeitsangabe und die Obergrenze dafür

Die Zahl in der Überschrift ist 14×, und sie verdient dieselbe Sorgfalt, die der Rest dieser Seite bekommt. OpenAI gibt bis zu 750 Ausgabe-Tokens pro Sekunde an, verglichen mit der Standardverarbeitung – ein Durchsatzwert für Ausgabe-Tokens, nicht die Behauptung, dass jede Anfrage 14-mal schneller abgeschlossen wird. Die End-to-End-Zeit enthält außerdem die Eingabeverarbeitung und das eigene Reasoning des Modells, wobei die Wafer-Scale-Hardware keines davon im gleichen Verhältnis komprimiert. Deshalb bezeichnet das Unternehmen 14× als Maximum und nicht als Messwert.

Die veröffentlichten Vergleiche beruhen auf Anbieterangaben auf beiden Seiten des Vergleichs, und einer davon erstreckt sich über die Stacks zweier Anbieter. Ein Durchlauf von Humanity's Last Exam mit 2.500 Fragen wird mit einer Abschlusszeit von 11 Stunden 11 Minuten auf Ultrafast angegeben – gegenüber 78 Stunden 27 Minuten für Claude Fable 5 – bei vergleichbarer Genauigkeit. Das heißt, OpenAI und Cerebras erzählen uns von einem Benchmark, der das Modell eines Konkurrenten einschließt, und unabhängige Berichterstattung über den Start zitierte einen enger gefassten, grob 11× schnelleren Generierungsgeschwindigkeitsvergleich für denselben Durchlauf, während Cerebras' eigene Zahlen etwa 7× für die Gesamttestzeit implizieren. Die Diskrepanz zwischen 14×, 11× und 7× ist kein Widerspruch; sie ist das, was passiert, wenn drei Parteien unterschiedliche Teile einer Arbeitslast messen. Cerebras berichtet separat von 5,6× End-to-End bei GDP-Val ohne messbaren Qualitätsverlust. Nichts davon wurde von einer dritten Partei reproduziert.

Die Preisliste hat eine Lücke.

Hier hört die Symmetrie zwischen den beiden Stufen auf. GPT-5.6 Sol hat vier veröffentlichte Preislisten, und Ultrafast ist keine davon.

• Standard GPT-5.6 Sol — 4,00 $ / 20,00 $ pro Million Token, mit zwischengespeichertem Input zu 0,40 $ und einer Long-Context-Stufe zu 8,00 $ / 30,00 $, sobald der Input etwa 272K Token überschreitet.

• Fast mode — 8,00 $ / 40,00 $, genau das Doppelte des Standardtarifs. Dies ist die Stufe, die am 30. Juli 2026 von Priority processing umbenannt wurde, und die API akzeptiert entweder service_tier: "priority" oder service_tier: "fast". Sie bringt eine um bis zu etwa 2,5× höhere Ausgabegeschwindigkeit.

• Batch und Flex — 2,00 $ / 10,00 $, pauschal 50 % Rabatt auf den Standardpreis im Austausch für eine lockerere Terminplanung.

• Ultrafast — keine Preisliste. Keine Leerstelle, die wir mit einer Vermutung gefüllt haben; eine Leerstelle, die OpenAI hinterlassen hat.

Diese Fast-Mode-Zeile ist der einzige echte Anhaltspunkt, gegen den man Ultrafast bepreisen kann, und für jeden, der ein Budget plant, ist sie ernüchternd: Die eine Geschwindigkeitsstufe, die OpenAI tatsächlich beziffert hat, kostet exakt doppelt so viel wie der Standardtarif für zweieinhalbfache Geschwindigkeit. Ultrafast ist ein größeres Geschwindigkeitsversprechen, das auf knapperer Hardware beruht – Cerebras-Waferkapazität ist kein Massengut –, daher besteht an der Richtung des letztendlichen Aufpreises kein Zweifel. An seiner Höhe schon. Solange es keine Preisliste gibt, ist jeder irgendwo zitierte Wert für „GPT-5.6 Sol Ultrafast price“ jemandes Schlussfolgerung, einschließlich jeder Schlussfolgerung von uns.

Wie du es tatsächlich nennen würdest

Die Schemaänderung verrät Ihnen die Gestalt des späteren Aufrufs. Wenn die Stufe dem Muster der anderen folgt, kommt sie als zusätzliches Feld bei einer Anfrage an, die Sie ohnehin schon stellen: Sie behalten das Modell gpt-5.6-sol, behalten Ihren Prompt und fügen den Stufen-Selektor hinzu – genauso wie Fast mode heute ausgewählt wird, indem priority gegen fast getauscht wird. An Ihrer Antwortauswertung ändert sich nichts, weil sich am Modell nichts ändert. Das ist der ganze Reiz einer Serving-Stufe gegenüber einem Modellwechsel und der Grund, warum eine Vergleichsseite wie diese so wenig zu vergleichen hat.

Was Sie heute nicht tun können, ist, es aufzurufen. Der Aufzählungswert existiert; die dahinterstehende Kapazität nicht – für die meisten Konten. Die praktische Frage für die nächsten Wochen ist also nicht, welche der beiden Stufen Sie wählen sollen – sondern, was Sie ausführen sollen, solange die Wahl nicht verfügbar ist.

Das ist eine Frage, die ein Gateway besser beantwortet als eine Warteliste. Die Standard-Stufe des Modells ist ab sofort auf OrcaRouter live als openai/gpt-5.6-sol, bereitgestellt zum eigenen Tarif des Anbieters mit null Aufschlag auf Tokens, über den OpenAI-kompatiblen Endpunkt unter api.orcarouter.ai/v1 — sodass OpenAIs Aktionspreise von $4 / $20 und die Long-Context-Stufe von $8 / $30 direkt durchgereicht werden, statt von uns neu bepreist zu werden, und eine Änderung daran bei uns am selben Tag ankommt, an dem sie bei OpenAI ankommt. Derselbe Schlüssel trägt 200+ Modelle, was hier mehr als sonst zählt: Da man nicht service_tier: "ultrafast" setzen kann und dann eine Antwort bekommt, besteht die Art und Weise, heute Latenz zu kaufen, darin, die Arbeit anders zu routen — schicke die interaktiven Aufrufe an dasjenige Modell im Katalog, das deine Qualitätshürde am schnellsten überspringt, und halte die Nachtstapel auf der günstigsten Spur, die besteht. Wenn die Stufe dann öffnet, ist der Router die Stelle, an der man den Schalter umlegen würde, und bis dahin ist es der Unterschied zwischen einer Warteliste und einem Plan.

Welches gehört in die Produktion?

Ignorieren Sie das Wort „versus“ für einen Moment, denn hier gibt es keine Qualitätsentscheidung zu treffen. Wenn Sie auf Kosten pro Token optimieren, ist GPT-5.6 Sol in der Standardvariante die Antwort, und die Batch-Lane mit 50 % Rabatt ist die Antwort für alles, was warten kann. Wenn Sie darauf optimieren, wie lange ein Mensch vor einem Spinner sitzt, ist Ultrafast die Antwort, sobald Sie darauf zugreifen können – und die Workloads, die OpenAI für die Preview nennt, zeigen genau, warum: Incident Response mit offenen Logs und Diffs bei einem laufenden Ausfall, Betrugsprüfungen gegen Daten in Bewegung, Support-Gespräche, in denen eine halbe Sekunde Stille wie ein defektes Produkt wirkt, und Forschungsschleifen, die früher über Nacht liefen und nun in eine Arbeitssitzung komprimiert werden.

Das verräterische Zeichen ist die Form Ihres Request-Graphen, nicht die Größe Ihres Prompts. Eine einzelne lange Generierung bringt auf dem Papier den 14-fachen Gewinn und in der Praxis deutlich weniger, weil sich Eingabeverarbeitung und Reasoning nicht in diesem Verhältnis komprimieren lassen. Vierzig sequenzielle Tool-Aufrufe hinter einer für den Nutzer sichtbaren Aktion bringen etwas, das dem vollen Multiplikator viel näher kommt, weil jeder dieser Roundtrips Latenz ist, die der Nutzer aussitzt. Wenn Ihr Workload wie der zweite aussieht, ist die Tier für Sie gedacht; wenn er wie der erste aussieht, wäre die Standard-Lane ohnehin in Ordnung gewesen.

Zwei Dinge, auf die man achten sollte, und keines davon ist ein Gerücht, das wir von hier aus klären könnten. Erstens, die Preisliste: Eine Premium-Stufe ohne Preis lässt sich nicht budgetieren, und der Präzedenzfall von Fast-mode legt nahe, dass sie nicht klein ausfallen wird. Zweitens, ob die Warteliste rund um DevDay tatsächlich aufgehoben wird, wie berichtet – denn ein service_tier-Wert, den die meisten Konten nicht nutzen können, ist Dokumentation, nicht Verfügbarkeit, und der Unterschied zwischen beidem ist der Unterschied zwischen einem Plan und einem Versprechen.