GPT-6.1 Sol vs. GPT-6 Sol: Was eine Woche Mehrarbeit gebracht hat – und was nicht

Wenn Sie GPT-6 Sol heute in Produktion einsetzen und versuchen zu entscheiden, ob GPT-6.1 Sol eine Migration wert ist, hängt die Antwort vollständig davon ab, welche Ihrer Kosten größer ist – und die beiden Modelle sind so gebaut, dass die Antwort fast nie „beides“ lautet. GPT-6 Sol erschien am 22. September 2026 zu 2,00 US-Dollar pro Million Input-Tokens, 0,20 US-Dollar für zwischengespeicherte Tokens und 10,00 US-Dollar für Output. GPT-6.1 Sol erschien am 29. September 2026 zu 2,00 US-Dollar für Input, 0,10 US-Dollar für zwischengespeicherte Tokens und 10,00 US-Dollar für Output, mit einer vom Anbieter gemeldeten Verbesserung um 6,4 Prozentpunkte bei komplexen Software-Engineering-Aufgaben bei geringerem Reasoning-Aufwand. Die Input- und Output-Preise blieben unverändert. Der Cache-Satz halbierte sich. Diese eine geänderte Zeile ist der gesamte finanzielle Fall, und alles andere ist ein Argument zur Leistungsfähigkeit, das zu diesem Zeitpunkt im Lebenszyklus des Releases aus genau einer Quelle stammt.

Drei Dinge haben sich geändert. Eines davon ist eine Rechnung.

Zieht man das Marketing ab, ist das Delta zwischen diesen beiden Deployments kurz genug, um es im Kopf zu behalten.

• Cached Input — 0,10 $ pro Million Tokens bei GPT-6.1 Sol gegenüber 0,20 $ bei GPT-6 Sol. Gemessen statt behauptet, und die einzige Änderung, die sich als reine Arithmetik niederschlägt.
• Leistungsfähigkeit, laut Anbieter — OpenAI meldet einen Vorsprung von 6,4 Punkten auf DeepSWE v1.1 bei geringerem Reasoning-Aufwand und geringeren Kosten, mehr als die doppelte Punktzahl auf Terminal-Bench Science 0.1 bei maximalem Aufwand, sieben Punkte auf dem Offline-Set von OSWorld 2.0 bei maximalem Aufwand, 4,8 Punkte auf AutomationBench bei mittlerem Aufwand und eine Quote faktischer Fehler, die bei einem absichtlich fehlerinduzierenden Prompt-Set von 11,4 % auf 7,7 % sinkt. Nichts davon wurde reproduziert.
• Reasoning-Leiter — GPT-6.1 Sol unterstützt low, medium, high, xhigh und max, und unterstützt none nicht; GPT-6 Sol unterstützt alle sechs. Das ist das Delta, das Code bricht, und genau das, was niemand in einen Launch-Post schreibt.

Alles andere ist identisch oder nahezu identisch: dasselbe 1.050.000-Token-Kontextfenster, dieselbe 128.000-Token-Ausgabeobergrenze, dieselbe Cache-Schreibrate von 2,50 $, dieselbe 272K-Token-Repricing-Schwelle, oberhalb derer eine gesamte Anfrage mit 2× Input und Cache sowie 1,5× Output abgerechnet wird, dieselbe Responses-API-Voraussetzung für Tool Calling und dasselbe Fehlen von Fine-Tuning-Unterstützung. Der Wissensstichtag verschob sich vom 20. April auf den 30. April 2026 – zehn Tage, eine Zahl, die einem verrät, wie sehr es sich hierbei eher um eine Überarbeitung als um einen Neuaufbau handelte.

Warum die Cache-Line mehr wert ist, als sie aussieht

Ein halbierter Cache-Lesevorgang ist ein seltsamer Aufhänger für ein Produkt-Refresh – bis man sich ansieht, wie Agent-Traffic tatsächlich aussieht. Eine Agent-Schleife sendet bei jedem Turn ein stabiles Präfix erneut – System-Prompt, Tool-Schemas, abgerufenen Kontext, Gesprächsverlauf –, und in einer langen Sitzung wird dasselbe Präfix Dutzende oder Hunderte Male abgerechnet. Das ist der Traffic, bei dem eine Cache-Rate aufhört, ein Rundungsfehler zu sein, und zum dominierenden Posten auf der Rechnung wird.

Rechnen wir einmal eine einzelne lange Agenten-Sitzung durch. Angenommen, ein Präfix mit 120.000 Tokens wird über 40 Turns hinweg wiederverwendet, also 4,8 Millionen gecachte Eingabe-Tokens pro Sitzung, plus bescheidene 150.000 neue Ausgabe-Tokens. Bei GPT-6 Sol werden die Cache-Lesevorgänge mit 0,96 $ und die Ausgabe mit 1,50 $ berechnet — rund 2,46 $ pro Sitzung. Bei GPT-6.1 Sol werden für dieselbe Sitzung 0,48 $ für Cache-Lesevorgänge und dieselben 1,50 $ für die Ausgabe berechnet: etwa 1,98 $. Pro Sitzung beträgt der Unterschied 48 Cent, was keine Entscheidung rechtfertigt. Rechnet man das auf hunderttausend Sitzungen pro Monat hoch, sind es 48.000 $ — was sehr wohl eine ist.

Zwei Vorbehalte sorgen dafür, dass das ehrlich bleibt. Zwischengespeicherte Lesevorgänge werden nur dann zum Cache-Tarif abgerechnet, wenn der Präfix tatsächlich trifft, sodass Ihre tatsächlich erzielte Ersparnis Ihre Trefferquote multipliziert mit der Differenz ist, nicht die Differenz selbst. Und der Präfix muss unter 272.000 Tokens liegen, damit überhaupt die Standardtarife gelten: Überschreiten Sie diese Grenze, wird die gesamte Anfrage mit 2× Input und Cache sowie 1,5× Output neu bepreist, was eine Ersparnis von 10 Cent beim Präfix erdrücken kann. Sitzungen mit langem Kontext sind diejenigen, bei denen die Cache-Rechnung am wenigsten wahrscheinlich wie im Prospekt aussieht.

Die Benchmark-Lücke ist real, und sie kommt von einer Stelle.

Der Launch-Post von OpenAI ist ungewöhnlich konkret, was seine Evaluierungen angeht, was ein Punkt zu seinen Gunsten ist, und jede einzelne dieser Zahlen ist der Anbieter, der sein eigenes Modell bewertet, was der Punkt dagegen ist. Das Muster über sie hinweg ist konsistent: Der Vergleich, der die Runde macht, ist immer gegen GPT-6 Astra, und der Astra-Vergleich ist immer ein Kostenvergleich. Bei DeepSWE v1.1 lautet die Behauptung, bei ungefähr einem Fünftel der Kosten mit Astra gleichzuziehen. Bei GDP.pdf nähert es sich dem State-of-the-Art von Astra bei ungefähr einem Fünftel der Kosten pro Aufgabe. Bei OSWorld 2.0 liegt es innerhalb von 2,1 Punkten von Astra bei ungefähr einem Siebtel der Kosten pro Aufgabe. Bei Faktenrichtigkeit liegt es innerhalb von 1,9 Punkten von Astra bei weniger als einem Fünftel der Kosten pro Aufgabe. Das ist kein Zufall der Formulierung; es ist die Produktthese, und es ist eine These über den Preis, nicht über Fähigkeitsführerschaft.

Die eine Stelle, an der OpenAI auf seine eigene Deutung verzichtet, ist anerkennenswert: Bei Terminal-Bench Science 0.1 heißt es klar und deutlich, dass GPT-6 Astra mit 68,1 % weiterhin den Spitzenwert unter den getesteten Modellen hält und für die schwierigste wissenschaftliche Forschung verwendet werden sollte. Ein Launch-Beitrag, der dir sagt, wann du das teurere Geschwistermodell kaufen solltest, ist ein Launch-Beitrag mit einer gewissen Disziplin.

Speziell im Vergleich zu GPT-6 Sol ist der ehrliche Stand des Vergleichs dieser – es gibt keinen unabhängigen Score für eines der beiden Modelle in dieser Konfiguration. Artificial Analysis hat eine vollständige Evaluation von GPT-6 Sol bei maximalem Reasoning-Aufwand: einen Intelligenzindex von 48, 1,06 US-Dollar pro Index-Aufgabe, 77 Millionen generierte Ausgabe-Tokens gegenüber einem Board-Median von 88 Millionen und einen Coding-Agent-Index von 57 bei 2,99 US-Dollar pro Aufgabe. Mit Stand 30. September gibt es überhaupt keinen Eintrag für GPT-6.1 Sol; der Slug des Modells liefert einen 404, und die Zeichenfolge erscheint nicht im Live-Leaderboard. Der einzige heute verfügbare gemessene Drittanbieter-Vergleich ist also der zwischen GPT-6 Sol und Modellen anderer Labore – nicht zwischen GPT-6 Sol und seinem eigenen Nachfolger. Wer Ihnen jetzt ein 6.1-gegen-6.0-Diagramm zeigt, zeigt Ihnen OpenAIs Folie.

Die Migration ist eine String-Änderung, außer dort, wo sie es nicht ist.

OpenAIs eigene Migrationshinweise für die GPT-6-Familie sind es wert, gelesen zu werden, bevor Sie die Kennung umstellen, denn zwei Punkte darin brechen funktionierenden Code. Der erste ist die Reasoning-Leiter: Wenn eine Anfrage reasoning_effort: "none" sendet, lehnt GPT-6.1 Sol sie ab, und die dokumentierte Abhilfe besteht darin, mit low zu beginnen und anhand repräsentativer Aufgaben zu vergleichen, statt anzunehmen, die niedrigste Einstellung sei gleichwertig. Workflows, die none als Latenz-Basiswert nutzten, verlieren diese Baseline. Der zweite ist Tool-Calling: GPT-6.1 Sol unterstützt Chat Completions, aber kein Tool-Calling darüber – Tools erfordern die Responses API. Wenn Ihr Stack Funktionen auf /v1/chat/completions aufruft, tauschen Sie keinen String aus, sondern portieren einen Endpunkt. Die eigene Anweisung des Anbieters an Entwickler, die bereits GPT-6 Sol verwenden, lautet, diese Hinweise vor dem Wechsel zu prüfen, was ein klares Signal dafür ist, dass dies nicht die Drop-in-Aktualisierung ist, die der Abstand von einer Woche impliziert.

Die übrigen Parameter verhalten sich gleich: Reasoning-Effort, strukturierte Ausgaben, Streaming, Prompt-Caching und das Tool-Set werden alle übernommen, und dieselbe 272K-Neupreisregel gilt für beide Modelle identisch.model auf gpt-6.1-sol, behalte deine Effort-Einstellung dort bei, wo sie unterstützt wurde, und entferne temperature, top_p und top_logprobs, wann immer effort nicht none ist — Letzteres gilt für beide Modelle und ist eine häufige Quelle für 400er nach jeder Migration auf ein Reasoning-Modell.

Migrieren, ohne dabei einen Produktionspfad darauf zu verwetten

Die realistische Migration ist kein Cutover, sondern ein Shadow Run: einen Teil des Produktionsverkehrs an den neuen Identifier senden, den alten als den Pfad behalten, der antwortet, und anhand eigener Aufgaben vergleichen. Das ist ein Routing-Problem, und es ist die eine Stelle, an der die Plattform, über die man aufruft, die Form der Arbeit verändert. OrcaRouter bedient GPT-6 Sol heute zu OpenAIs eigenem Listenpreis ohne Aufschlag — die $2.00 / $0.20 / $10.00-Karte, die 272K-Repricing-Regel inklusive —, sodass der Baseline-Arm des Vergleichs mit demselben Key live ist wie alles andere, und der 6.1-Arm kann dem Route-Set hinzugefügt werden, sobald er aufrufbar ist, ohne einen zweiten Vertrag oder ein zweites SDK. Bis dahin ist die ehrliche Position, dass GPT-6 Sol das Modell ist, das sich aufrufen lässt, und das sollte man klar sagen, statt etwas anderes anzudeuten: openai/gpt-6.1-sol liefert heute auf unserem öffentlichen catalogue-Endpunkt „model not found" zurück. Automatisches Failover ist das, was den Shadow Run sicher macht, wenn er dann tatsächlich kommt — wenn die neue Route einen Fehler wirft, wird die Anfrage über die alte abgeschlossen, und man erfährt es aus den Logs statt von den eigenen Nutzern.

Wer jetzt umsteigen sollte: Teams, deren Kosten bei langen Agent-Sessions von gecachtem Input dominiert werden, und Teams, deren Workflows bereits die Responses API verwenden und nie none. Für sie ist das nahezu ein kostenloses Upgrade — der Anbieter meldet die Fähigkeitsgewinne, die Cache-Rate ist halbiert, und die Migration besteht aus einem einzigen String. Wer warten sollte: Teams, bei denen none in einem latenzkritischen Pfad liegt, Teams, deren Tool-Calling über Chat Completions läuft, und alle, die eine Zahl von außerhalb OpenAIs benötigen, bevor sie sich festlegen. Für diese letzte Gruppe hat das Warten kein veröffentlichtes Enddatum, und das Sinnvollste, was man mit der Zeit tun kann, ist, das Eval-Set aufzubauen, das der Vergleich benötigen wird — denn wenn die unabhängige Bewertung eintrifft, wird sie für den Traffic von jemand anderem gelten.