GPT-6.1 Sol Context Window: 1.050.000 Tokens, die 922.000-Linie und die 272.000-Klippe

Die Modellseite des Anbieters für GPT-6.1 Sol, abgerufen am 7. Oktober 2026, nennt ein Kontextfenster von 1.050.000 Token und eine maximale Ausgabe von 128.000 Token. Dieselbe Seite enthält in der maschinenlesbaren Form, die man erhält, wenn man .md an ihre URL anhängt, eine dritte Zahl, die die gerenderte Seite nie ausgibt: maximal 922.000 Eingabe-Token. GPT-6 Sol, das Modell, als dessen Nachfolger 6.1 am 29.09.2026 veröffentlicht wurde, gibt auf seiner eigenen Seite dasselbe Paar von Obergrenzen an und dieselbe Zeile mit 922.000 in seiner eigenen Markdown-Form. Unsere eigene Modellkarte für openai/gpt-6-sol weist das Fenster mit 1.050.000 Token und die Ausgabeobergrenze mit 128.000 aus, zeigt die erste dieser Angaben als "1M" in ihrer Spec-Leiste an und druckt "1.1M" für dasselbe Modell in einer Vergleichstabelle weiter unten auf derselben Seite.

Die Seiten widersprechen sich also, und es lohnt sich, genau zu sein, worin. Die gerenderte Spezifikationsleiste des Anbieters nennt ein Fenster und eine Ausgabeobergrenze, aber keine Eingabeobergrenze. Die Markdown-Dokumentation des Anbieters für dasselbe Modell nennt alle drei. Wer eine Anfrage anhand der gerenderten Seite dimensioniert, arbeitet mit einer Randbedingung weniger, als der Anbieter veröffentlicht hat, und die fehlende ist die Zahl, die entscheidet, ob eine Anfrage passt.

Drei Zahlen, drei Quellen und eine Subtraktion, die niemand aufschreibt

Hier ist jede Nummer mit dem Dokument, aus dem sie stammt, alle gelesen am 7. Oktober 2026.

• 1.050.000 Kontextfenster — die Modellseite des Anbieters für gpt-6.1-sol, im gerenderten Spezifikationsstreifen und in ihrer Markdown-Form, und dieselbe Angabe auf der Seite für gpt-6-sol. Es ist außerdem der Wert, den unser Katalog für openai/gpt-6-sol und openai/gpt-6-luna zurückgibt, wo das Feld als 1,050,000 statt gerundet eingetragen ist.

• maximal 128.000 Ausgabe-Tokens — dieselbe Seite, dieselben zwei Formen, für beide Generationen. Das Feld unserer Karte gibt 128.000 an; ihre Anzeige rundet auf „128K“.

• 922.000 maximale Eingabetoken — die Markdown-Form der Modellseite gpt-6-sol des Anbieters und seiner Seite gpt-6.1-sol. Sie steht weder in der gerenderten Leiste einer der beiden Seiten noch in unserem Katalogfeld für das Modell, das beim Kontextfenster und der Ausgabengrenze endet.

Die drei Zahlen stimmen arithmetisch überein: 922.000 plus 128.000 ergibt genau 1.050.000. Der eigene Reasoning-Leitfaden des Anbieters beschreibt den Mechanismus, der die Gleichung bedeutsam macht, ohne die Summe jemals auf der Modellseite zu bilden – Reasoning-Tokens, heißt es dort, „beanspruchen weiterhin Platz im Kontextfenster des Modells“, und wenn generierte Tokens „das Kontextfensterlimit oder den von Ihnen festgelegten Wert für max_output_tokens erreichen“, wird die Antwort als unvollständig markiert zurückgegeben. Ein Fenster, das zwischen dem, was hineingeht, und dem, was herauskommt, geteilt wird, ist ein Fenster, in dem die Eingabeobergrenze dem Fenster abzüglich der Ausgabereservierung entspricht.

Diese Lesart wird gestützt, nicht bewiesen, und es lohnt sich, die beiden zu trennen. Dokumentiert ist ein Fenster von 1.050.000, eine Ausgabeobergrenze von 128.000 und eine maximale Eingabe von 922.000. Abgeleitet wird, welche davon die Einschränkung ist, die zuerst greift. Die Schlussfolgerung gilt für jede Anfrage, die ihr volles Ausgabekontingent reserviert, und schlägt bei jeder Anfrage fehl, die das nicht tut — setzt man max_output_tokens auf 4.000 und 1.046.000 Eingabe-Token, wird das nicht offensichtlich abgelehnt. Bis der Anbieter die Subtraktion in die Seite schreibt, auf der die Zahlen stehen, betrachte die Paarung als die Form des Budgets und nicht als harte Zulassungsregel, und validiere gegen den Token-Zähl-Endpunkt statt gegen einen Blogbeitrag.

Kontext ist kein Preis: der 272.000-Token-Schritt

Ein größeres Fenster ist eine Kapazitätsaussage. Es ist keine Kostenaussage, und in dieser Familie trennen sich die beiden an einer dokumentierten Grenze. Die Preisseite des Anbieters formuliert die Regel in einem Satz: Prompts mit mehr als 272K Eingabe-Tokens werden für die gesamte Anfrage mit dem 2-fachen der Eingabe- und Cache-Raten und dem 1,5-fachen der Ausgabe berechnet. Die eigene Definition der beiden Spalten auf derselben Seite lautet: „Kurzer Kontext: ≤272K Eingabe-Tokens. Langer Kontext: >272K Eingabe-Tokens.“

Lies das Wort voll aufmerksam. Die Stufe besteuert die Token jenseits der Linie nicht — sie berechnet alles neu, einschließlich des ersten Tokens. Und es ist keine 6.1-Änderung: Die identische Regel mit der identischen Schwelle gilt für GPT-6 Sol, weshalb die Klippe der Stufe und nicht dem Release zugeschrieben werden muss.

Rechne einen Long-Context-Job für beide Seiten durch, zu den veröffentlichten Tarifen von GPT-6.1 Sol, wobei das Präfix bereits im Cache liegt, damit die Cache-Schreibgebühr den Vergleich nicht verfälscht:

• 240.000 Eingabe-Tokens (200.000 zwischengespeichert, 40.000 neu), 6.000 Ausgabe — frischer Input 40.000 bei 2,00 $ pro Million ergibt 0,080 $; zwischengespeicherter Input 200.000 bei 0,10 $ ergibt 0,020 $; Ausgabe 6.000 bei 10,00 $ ergibt 0,060 $. Insgesamt 0,160 $.

• 300.000 Eingabe-Tokens (260.000 zwischengespeichert, 40.000 neu), 6.000 Ausgabe — die Anfrage liegt jetzt über der Grenze, also ändert sich jeder Tarif: neue Eingabe 40.000 zu 4,00 $ ergibt 0,160 $; zwischengespeicherte Eingabe 260.000 zu 0,20 $ ergibt 0,052 $; Ausgabe 6.000 zu 15,00 $ ergibt 0,090 $. Gesamt: 0,302 $.

25 Prozent mehr Eingabe-Tokens erkaufen eine um 89 Prozent größere Rechnung. Lässt man dasselbe Paar auf GPT-6 Sol laufen, bleibt die Form mit einer steileren Steigung erhalten — 0,180 $ unterhalb der Linie gegenüber 0,354 $ oberhalb davon, weil der gecachte Tarif der älteren Karte von 0,20 $ an derselben Stelle liegt wie der gecachte Long-Context-Tarif von 6.1. Der Übergang ist ein Sprung, keine Steigung, und der günstigste Weg, das zu sehen, ist, ihn um ein Haar zu überschreiten. Eine vollständig ungecachte Anfrage mit 271.000 Tokens und 1.000 Ausgabe-Tokens kostet 0,552 $; bei 273.000 sind es 1,107 $. Sieben Zehntel eines Prozents mehr Eingabe-Tokens, 2,01-mal so viel Geld. Kürzt man diese Anfrage um 2.000 Tokens, sinkt die Rechnung von 1,107 $ auf 0,552 $ — weniger als ein Prozent der Eingabe für die Hälfte der Kosten.

Nichts in diesem Abschnitt dreht sich darum, dass das Fenster von GPT-6.1 Sol groß ist. Es geht darum, dass das Fenster groß genug ist, um eine Grenze zu erreichen, die mehr kostet, als die Größe des Fensters einbringt.

Was füllt tatsächlich 1.050.000 Tokens?

Ein Kontextbudget besteht aus sechs Dingen, und sie sind nicht alle gleichermaßen cachebar. Ungefähre Anteile einer beispielhaften agentischen Anfrage mit 240.000 Token; die Proportionen sind unsere eigenen, die Cachebarkeitsregeln stammen vom Anbieter, aus seinem am selben Tag gelesenen Prompt-Caching-Leitfaden.

• Vom Anbieter eingefügter Systeminhalt und Anfrageformatierung — vor Ihren Nachrichten gerendert, als Eingabe abgerechnet und explizit von der minimalen cachefähigen Länge ausgeschlossen. Nicht Ihre Sache, es zu kontrollieren und nicht Ihre Sache, es zu kürzen.

• Ihre Entwickler- und Systemanweisungen, etwa 6.000 Tokens. Cachefähig. Dies ist der Anfang des Präfixes, daher macht eine Änderung hier alles dahinter ungültig.

• Tool-Definitionen und -Schemata, etwa 14.000 Tokens für die gehostete Tool-Oberfläche plus Ihre Funktionen. Cachefähig und der fragilste Teil des Präfixes: Der Leitfaden führt Toolnamen, Beschreibungen, Schemas, Reihenfolge und tool-spezifische Anweisungen als Dinge auf, die die Präfixgrenze verschieben.

• Der abgerufene Korpus, rund 180.000 Tokens. Cachefähig und mit Abstand die größte Zeile. Es lohnt sich nur dann, ihn zu cachen, wenn er zwischen Aufrufen byte-stabil ist — ein pro Anfrage neu zusammengesetzter Korpus ist ein Korpus zum Vollpreis.

• Das akkumulierte Transkript – frühere Turns und Tool-Ergebnisse – rund 30.000 Tokens und steigend. Bis zur neuesten Änderung cachebar; das in diesem Turn eingetroffene Tool-Ergebnis ist frischer Input zum vollen Satz.

• Reasoning-Tokens – generiert, nie zwischengespeichert, als Ausgabe abgerechnet. Sie belegen das Kontextfenster und sind im Antwortkörper unsichtbar.

Aus dieser Liste ergeben sich unmittelbar zwei operative Hinweise. Erstens werden Cache-Einträge auf einzelnen Maschinen gehalten: Der Leitfaden besagt, dass eine Anfrage ein Präfix „nur dann wiederverwenden kann, wenn sie eine Maschine erreicht, die einen passenden, nicht abgelaufenen Eintrag enthält“, und dass das Overflow-Routing oberhalb von ungefähr 15 Anfragen pro Minute beginnt. Ein Präfix, das in Ihrem Code stabil ist, kann in der Produktion dennoch zu einem Cache-Miss führen. Zweitens beträgt das minimale cachefähige Präfix 1.024 sichtbare Eingabe-Tokens, und versteckte System-Tokens werden nicht darauf angerechnet – ein kleines System-Prompt ist also kein cachefähiges Präfix, egal wie groß die Anfrage darum herum ist.

Die Ausgabeobergrenze ist ein separates Budget, kein Nachschlag.

128.000 maximale Ausgabetokens bedeuten nicht 128.000 Tokens Antwort. Der Reasoning-Leitfaden stellt ausdrücklich klar, dass max_output_tokens die Gesamtzahl begrenzt, die das Modell generiert, „einschließlich Reasoning-Tokens, sichtbarer Ausgabetokens und nicht sichtbarer Formatierungstokens“, und dass Reasoning-Tokens als Ausgabe abgerechnet werden, während sie Platz im Fenster belegen.

Das macht die Trunkierung zu einer Designentscheidung statt zu einem Sonderfall, und zwar wegen der Art und Weise, wie sie fehlschlägt. Wenn die Generierung das Limit erreicht, wird die Antwort mit dem Status incomplete und dem Grund max_output_tokens zurückgegeben — und der Leitfaden warnt, dies „könnte auftreten, bevor sichtbare Ausgabe-Token erzeugt werden, was bedeutet, dass Ihnen Kosten für Eingabe- und Reasoning-Token entstehen können, ohne dass Sie eine sichtbare Antwort erhalten.“ Ein Budget, das das gesamte Fenster für die Eingabe aufbraucht und die Reservierung für die Ausgabe dem Zufall überlässt, ist ein Budget, das eine vollständige Long-Context-Anfrage abrechnen und nichts zurückgeben kann, was ein Aufrufer parsen kann. Die eigene Ausgangsempfehlung des Anbieters lautet, mindestens 25.000 Token für Reasoning und Ausgaben zu reservieren, während Sie noch messen, was ein Prompt tatsächlich benötigt.

GPT-6.1 Sol schärft dies, und es ist eine der wenigen wirklich 6.1-spezifischen Zeilen im Release. Seine Reasoning-Aufwandsleiter umfasst low, medium, high, xhigh und max, und die Einstellungen none und minimal werden nicht unterstützt. GPT-6 Sol akzeptiert alle sechs. Es gibt daher keine Einstellung auf 6.1, die den Reasoning-Aufwand ausschaltet, der Standard ist medium, und die Ausgabeseite des Budgets ist niemals kostenlos.

Die Halbierung der gecachten Eingabe, gelesen dort, wo das Fenster am breitesten ist

Der einzige Tarif auf der GPT-6.1-Sol-Karte, der sich gegenüber GPT-6 Sol verändert hat, ist der für gecachte Eingabe: 0,20 $ auf 0,10 $ pro Million Token, was die Modellseite als 5 % des Tarifs für ungecachte Eingabe ausdrückt und was der Caching-Leitfaden des Anbieters ausdrücklich als den 0,05x-Fall gegenüber dem 0,1x nennt, mit dem die meisten Modelle ab GPT-5.6 abgerechnet werden. Eingabe, Cache-Schreibvorgänge und Ausgabe sind auf beiden Karten identisch, und die Long-Context-Multiplikatoren sind ebenfalls identisch.

Für genau die Arbeitslast, um die es auf dieser Seite geht, ist das die richtige Messgröße, die verändert werden musste, und der Grund dafür ist die Zusammensetzung einer langen Anfrage und nicht ihre Größe. Bei dem oben genannten Auftrag mit 300.000 Token sind 260.000 der Eingabe-Tokens ein zwischengespeichertes Präfix — 87 Prozent von allem, was die Anfrage sendet. Die Cache-Position ist daher die größte einzelne Eingabe-Messgröße in der Abrechnung, was die allgemeine Eigenschaft von Long-Context-Arbeit ist: Je länger das Fenster, das Sie verwenden, desto mehr davon ist ein Präfix, das Sie bereits gesendet haben. Die Halbierung dieser Messgröße ist bei dieser Anfrage 0,052 $ wert.

Und die Klippe nimmt bei derselben Anfrage mehr zurück, als die Halbierung hergibt. Mit den Kurzkontext-Tarifen bepreist, mit denen er unterhalb der Linie gezahlt hätte, würde derselbe 300.000-Token-Job auf GPT-6.1 Sol 0,166 $ statt 0,302 $ kosten – ein Übertrittspreis von 0,136 $, also etwa 2,6-mal so viel, wie die eine geänderte Abrechnungsmetrik des Releases wert ist. Oberhalb der Linie steht der Cache-Tarif bei 0,20 $, was in dieser Familie keine neue Zahl ist: Er ist doppelt so hoch wie der Headline-Preis auf der 6.1-Karte und genau das, was GPT-6 Sol vor diesem Release für einen gecachten Lesevorgang unterhalb der Linie berechnete. Eine gecachte Long-Context-Workload nimmt die Headline-Änderung mit und gibt sie an der Grenze wieder zurück, und die Grenze – nicht das Modell – ist die Ursache.

Wie man ein Kontextbudget bemisst

Als Verfahren, in der Reihenfolge, in der die Beschränkungen binden:

• Zählen Sie die Anfrage, schätzen Sie sie nicht. POSTen Sie die exakte Payload – Tools, Bilder, Dateien und alles – an den Endpunkt zur Zählung der Eingabe-Tokens der Responses API. Der Leitfaden ist unverblümt, was den Grund betrifft: Die Zählung enthält Formatierungs-Tokens für Nachrichtenrollen und -grenzen, die nie in Text auftauchen, den Sie lokal tokenisieren können, und lokale Schätzungen wie Zeichen geteilt durch vier sind für Bilder, Dateien und Schemas ungenau.

• Reservieren Sie zuerst die Ausgabeseite.Wählen Sie max_output_tokens, wobei Sie bedenken sollten, dass es Reasoning, sichtbare Ausgabe und Formatierung zusammen abdeckt, und beginnen Sie mit dem 25.000-Token-Puffer des Anbieters statt bei null. Ihr Eingabebudget ist das Kontextfenster abzüglich dieser Reservierung, und die Zahl neunhundertzweiundzwanzig ist die Version des Anbieters derselben Subtraktion.

• Bepreisen Sie die Anfrage auf beiden Seiten von 272.000, bevor Sie sie absenden. Die Stufe ist so groß, dass eine Anfrage, die darauf ausgelegt ist, knapp unter der Grenze zu landen, und eine Anfrage, die darauf ausgelegt ist, knapp darüber zu landen, unterschiedliche Produkte sind.

• Ordne das Präfix nach Stabilität an. Zuerst die Anweisungen, dann die Tool-Schemata, dann das Korpus, dann das Transkript. Alles, was sich zwischen Aufrufen ändert, gehört ans Ende, wo es einen Präfix-Treffer kostet statt den gesamten Cache.

• Überschreiten Sie 1.024 sichtbare Eingabe-Token, bevor Sie einen Cache erwarten können. Unterhalb dieses Minimums wird nichts gecacht, und versteckte Provider-Token zählen nicht dafür.

• Prüfen Sie, ob die Wiederverwendung plausibel ist. Ein Präfix muss innerhalb der 30-minütigen Lebensdauer des Caches wiederverwendet werden und auf der Maschine landen, die den Eintrag hält; beides ist im Leitfaden beschrieben, und keines von beidem ist eine Eigenschaft Ihres Codes.

• Nach jeder Modell- oder Einstellungsänderung neu messen. Der Wechsel zu GPT-6.1 Sol entfernt die Position „Reasoning aus“, wodurch sich die Anzahl der Reasoning-Tokens und damit die Ausgabeseite des Budgets ändert – und eine Änderung am Reasoning-Aufwand, an Tools, am Schema für strukturierte Ausgaben oder an der Kontextverwaltung kann ebenfalls eine Präfixgrenze verschieben und dazu führen, dass Sie den Cache-Tarif vollständig verlieren.

•Entscheide, was passiert, wenn die Aufgabe nicht schrumpfen will. Komprimierung ist der dokumentierte Ausweg: Eine Responses-Anfrage kann context_management mit einem Kompakt-Schwellenwert festlegen, und der Server ersetzt die frühere Konversation durch ein opakes Komprimierungselement, das wichtigen Zustand mit weniger Tokens weiterführt. Es ist eine Budgetentscheidung statt einer kostenlosen Kürzung, denn der Leitfaden merkt an, dass Komprimierung „die Wiederverwendung ab dem ersten geänderten Token verhindern kann“ – ein Komprimierungsdurchlauf macht den davor liegenden Präfix ungültig.

Die Berechnung auf dieser Seite beginnt bei der Generation, die GPT-6.1 Sol ersetzt, und diese Stufe ist diejenige, die heute aufrufbar ist: Unsere Karte für openai/gpt-6-sol meldet ein Kontextfenster von 1.050.000 Tokens mit 128.000 Tokens maximaler Ausgabe zu OpenAI-Listenpreisen mit 0 % Aufschlag — der Preis des Anbieters ist der Preis auf der Seite, und eine Preisänderung des Anbieters wird dort noch am selben Tag übernommen statt erst bei einer Verlängerung. Unsere Karte enthält kein eigenes Feld für die maximale Eingabe, daher muss die Zahl von 922.000 Tokens für dieses Modell aus der Dokumentation des Anbieters selbst stammen, die diese Seite durchgängig verwendet hat. Wofür die Karte nützlich ist, ist die Dimensionierung: Das Fenster und die Obergrenze für die Ausgabe, die sie tatsächlich veröffentlicht, sind die beiden Zahlen, die das obige Budgetverfahren voneinander abzieht, und die Stufe darunter ist diejenige, gegen die Sie dieses Verfahren tatsächlich anwenden können, solange 6.1 noch neu ist. Sie ist unter https://www.orcarouter.ai/models/openai/gpt-6-sol zu finden.