Okno kontekstowe GPT-6.1 Sol: 1 050 000 tokenów, linia 922 000 i klif 272 000

Strona modelu dostawcy dla GPT-6.1 Sol, odczytana 7 października 2026 r., podaje okno kontekstowe wynoszące 1 050 000 tokenów oraz maksymalną długość wyjścia 128 000 tokenów. Ta sama strona, w formie czytelnej maszynowo, którą otrzymuje się, dopisując .md do jej adresu URL, zawiera trzecią liczbę, której wyrenderowana strona nigdy nie wyświetla: maksimum 922 000 tokenów wejściowych. GPT-6 Sol, model, który 6.1 miał zastąpić w dniu 2026-09-29, publikuje identyczną parę liczb granicznych na własnej stronie oraz tę samą wartość 922 000 w swojej formie markdown. Nasza własna karta modelu dla openai/gpt-6-sol podaje okno jako 1 050 000 tokenów, a limit wyjścia jako 128 000, wyświetla pierwszą z tych wartości jako „1M" w pasku specyfikacji i podaje „1.1M" dla tego samego modelu w tabeli porównawczej niżej na tej samej stronie.

Zatem strony rzeczywiście się różnią i warto doprecyzować, na czym polega różnica. Wyrenderowany pasek specyfikacji dostawcy podaje okno oraz limit wyjściowy, a nie podaje limitu wejściowego. Dokumentacja dostawcy w formacie Markdown dla tego samego modelu podaje wszystkie trzy wartości. Każdy, kto dobiera rozmiar żądania na podstawie wyrenderowanej strony, ma o jedno ograniczenie mniej, niż opublikował dostawca, a tym brakującym jest liczba, która decyduje, czy żądanie się zmieści.

Trzy liczby, trzy źródła i jedno odejmowanie, którego nikt nie zapisuje

Oto każdy numer wraz z dokumentem, z którego pochodzi, wszystkie odczytane 7 października 2026 r.

• okno kontekstowe 1,050,000 — strona modelu gpt-6.1-sol u dostawcy, w wyrenderowanym pasku specyfikacji oraz w formie markdown, a także ta sama wartość na stronie dla gpt-6-sol. To również wartość, którą zwraca nasz katalog dla openai/gpt-6-sol i openai/gpt-6-luna, gdzie pole jest wpisane jako 1,050,000, a nie zaokrąglone.

• Maks. 128 000 tokenów wyjściowych — ta sama strona, te same dwa formaty, w obu generacjach. Pole na naszej karcie podaje 128 000; jej wyświetlacz zaokrągla do „128K”.

• 922 000 maksymalnych tokenów wejściowych — wersja markdown strony modelu gpt-6-sol dostawcy oraz jego strony gpt-6.1-sol. Nie ma jej w wyrenderowanym pasku żadnej z tych stron ani w naszym polu katalogowym dla modelu, które kończy się na oknie i limicie wyjściowym.

Trzy liczby są ze sobą arytmetycznie spójne: 922,000 plus 128,000 to dokładnie 1,050,000. Przewodnik dostawcy dotyczący rozumowania opisuje mechanizm, który nadaje sens tej równości, nie wykonując nigdy sumy na stronie modelu — tokeny rozumowania, jak czytamy, „nadal zajmują miejsce w oknie kontekstu modelu”, a jeśli wygenerowane tokeny „osiągną limit okna kontekstu lub ustawioną wartość max_output_tokens”, odpowiedź wraca oznaczona jako niekompletna. Okno współdzielone między tym, co wchodzi, a tym, co wychodzi, to okno, w którym pułap wejściowy równa się oknu pomniejszonemu o rezerwację na wyjście.

Ta interpretacja jest potwierdzona, ale nie udowodniona, i warto te dwie rzeczy rozdzielić. Udokumentowane są: okno 1 050 000, limit wyjścia 128 000 oraz maksymalne wejście 922 000. Wywnioskowane jest to, który z nich jest ograniczeniem zadziałającym pierwsze. To rozumowanie jest słuszne dla każdego żądania, które rezerwuje pełny przydział wyjścia, a zawodzi dla każdego żądania, które tego nie robi — przy ustawieniu max_output_tokens na 4 000, 1 046 000 tokenów wejściowych nie zostaje w oczywisty sposób odrzucone. Dopóki dostawca nie zapisze tego odejmowania na stronie, na której żyją te liczby, traktuj tę parę jako kształt budżetu, a nie jako twardą regułę dopuszczania, i weryfikuj względem punktu końcowego zliczającego, a nie względem wpisu na blogu.

Kontekst to nie cena: krok 272 000 tokenów

Większe okno to deklaracja pojemności. To nie jest deklaracja kosztu, a w tej rodzinie te dwie rzeczy rozchodzą się na udokumentowanej granicy. Strona cennika dostawcy podaje tę zasadę w jednym zdaniu: prompty z więcej niż 272K tokenów wejściowych są wyceniane według 2x stawek za wejście i cache oraz 1,5x za wyjście dla całego żądania. Własna definicja dwóch kolumn na tej samej stronie brzmi: „Krótki kontekst: ≤272K tokenów wejściowych. Długi kontekst: >272K tokenów wejściowych”.

Przeczytaj uważnie słowo full. Poziom nie opodatkowuje tokenów za linią — przecenia wszystko, w tym pierwszy token. I nie jest to kwestia wersji 6.1: identyczna reguła, z identycznym progiem, obowiązuje w GPT-6 Sol, dlatego tę przepaść trzeba przypisać poziomowi, a nie wydaniu.

Przeprowadź jedno zadanie z długim kontekstem przez obie strony, według opublikowanych stawek GPT-6.1 Sol, przy założeniu, że prefiks jest już w pamięci podręcznej, aby opłata za zapis do pamięci podręcznej nie zaciemniała porównania:

• 240 000 tokenów wejściowych (200 000 z pamięci podręcznej, 40 000 świeżych), 6000 wyjściowych — świeże wejście 40 000 po 2,00 USD za milion to 0,080 USD; wejście z pamięci podręcznej 200 000 po 0,10 USD to 0,020 USD; wyjście 6000 po 10,00 USD to 0,060 USD. Razem 0,160 USD.

• 300 000 tokenów wejściowych (260 000 z pamięci podręcznej, 40 000 świeżych), 6 000 wyjściowych — żądanie jest teraz powyżej progu, więc każda stawka się zmienia: świeże tokeny wejściowe 40 000 po $4,00 to $0,160; 260 000 po $0 to $0,052; tokeny wyjściowe 6 000 po $15,00 to $0,090. Razem $0,160.

Dwadzieścia pięć procent więcej tokenów wejściowych przekłada się na rachunek większy o 89 procent. Uruchom tę samą parę na GPT-6 Sol, a kształt się utrzyma, z bardziej stromym nachyleniem — 0,180 USD poniżej linii w zestawieniu z 0,354 USD powyżej niej, ponieważ stawka za tokeny z pamięci podręcznej starszej karty wynosząca 0,20 USD zajmuje to samo miejsce co stawka za tokeny z pamięci podręcznej dla długiego kontekstu w 6.1. Przekroczenie progu to skok, a nie nachylenie, a najtańszym sposobem, aby to zobaczyć, jest przekroczyć go o włos. Żądanie o 271 000 tokenów w całości bez pamięci podręcznej, z 1 000 tokenami wyjściowymi, kosztuje 0,552 USD; przy 273 000 kosztuje 1,107 USD. O siedem dziesiątych procenta więcej tokenów wejściowych, 2,01 razy więcej pieniędzy. Usuń 2 000 tokenów z tego żądania, a rachunek spadnie z 1,107 USD do 0,552 USD — poniżej jednego procenta danych wejściowych za połowę kosztu.

Nic w tej sekcji nie dotyczy tego, że okno GPT-6.1 Sol jest duże. Chodzi o to, że okno jest wystarczająco duże, by dotrzeć do granicy, której koszt jest wyższy niż to, co pozwala kupić rozmiar okna.

Co tak naprawdę wypełnia 1 050 000 tokenów?

Budżet kontekstu składa się z sześciu rzeczy i nie wszystkie nadają się równie dobrze do buforowania. Przybliżone udziały w ilustracyjnym żądaniu agentowym o rozmiarze 240 000 tokenów; proporcje są nasze, zasady buforowania pochodzą od dostawcy, z jego przewodnika po buforowaniu promptów, przeczytanego tego samego dnia.

• Formatowanie żądań i formatowanie wstrzykiwane przez dostawcę — renderowane przed Twoimi wiadomościami, rozliczane jako dane wejściowe i wyraźnie wyłączone z minimalnej długości kwalifikującej się do pamięci podręcznej. Nie masz nad tym kontroli ani nie możesz tego skracać.

• Twoje instrukcje deweloperskie i systemowe, około 6000 tokenów. Możliwe do buforowania. To jest początek prefiksu, więc zmiana tutaj unieważnia wszystko, co znajduje się za nim.

• Definicje i schematy narzędzi, około 14 000 tokenów dla hostowanej powierzchni narzędzi oraz Twoich funkcji. Można to buforować, a jest to najbardziej krucha część prefiksu: przewodnik wymienia nazwy narzędzi, opisy, schematy, kolejność i instrukcje dotyczące konkretnych narzędzi jako elementy, które przesuwają granicę prefiksu.

Kursor...Korpus..., około 180 000 tokenów. Cache'uj, i to zdecydowanie największa linia. Warto go cache'ować tylko wtedy, gdy jest stabilny bajtowo między wywołaniami — ponowne składanie przy każdym żądaniu to oszczędność kosztów, a nie oszczędność pamięci podręcznej. Ten element warto cache'ować tylko wtedy, gdy złożony korpus jest identyczny bajtowo między żądaniami.

• Zgromadzony transkrypt — wcześniejsze tury i wyniki narzędzi — około 30 000 tokenów i rośnie. Można go buforować aż do najnowszej zmiany; wynik narzędzia, który pojawił się w tej turze, to świeże dane wejściowe rozliczane po pełnej stawce.

• Tokeny rozumowania — generowane, nigdy nie są buforowane, rozliczane jako dane wyjściowe. Zużywają okno i są niewidoczne w treści odpowiedzi.

Z tej listy wynikają wprost dwie uwagi operacyjne. Po pierwsze, wpisy pamięci podręcznej są przechowywane na poszczególnych maszynach: przewodnik mówi, że żądanie może ponownie użyć prefiksu „tylko wtedy, gdy trafi na maszynę przechowującą pasujący wpis, który nie wygasł”, a routing przepełnienia rozpoczyna się powyżej około 15 żądań na minutę. Prefiks, który jest stabilny w twoim kodzie, nadal może nie trafić w środowisku produkcyjnym. Po drugie, prefiks kwalifikujący się do buforowania wynosi 1024 widocznych tokenów wejściowych, a ukryte tokeny systemowe nie wliczają się do niego — więc mały monit systemowy nie jest prefiksem kwalifikującym się do buforowania, niezależnie od tego, jak duże jest otaczające go żądanie.

Limit wyjściowy jest oddzielną sekundą

128 000 maksymalnych tokenów wyjściowych nie oznacza 128 000 tokenów odpowiedzi. Przewodnik dotyczący rozumowania wyraźnie mówi, że max_output_tokens ogranicza całkowitą liczbę tokenów generowanych przez model, „w tym tokeny rozumowania, widoczne tokeny wyjściowe i niewidoczne tokeny formatowania”, oraz że tokeny rozumowania są rozliczane jako wyjście, jednocześnie zajmując miejsce w oknie.

To sprawia, że obcinanie jest decyzją projektową, a nie przypadkiem brzegowym, ze względu na sposób, w jaki zawodzi. Gdy generowanie osiągnie limit, odpowiedź zwracana jest ze statusem incomplete i powodem max_output_tokens — a przewodnik ostrzega, że może to „wystąpić, zanim zostaną wygenerowane jakiekolwiek widoczne tokeny wyjściowe, co oznacza, że możesz ponieść koszty tokenów wejściowych i rozumowania, nie otrzymując widocznej odpowiedzi”. Budżet, który wydaje całe okno na dane wejściowe i pozostawia rezerwę na wyjście przypadkowi, to budżet, który może rozliczyć pełne żądanie długiego kontekstu i zwrócić nic, co wywołujący mógłby przetworzyć. Własna wstępna rekomendacja dostawcy to zarezerwowanie co najmniej 25 000 tokenów na rozumowanie i dane wyjściowe, dopóki wciąż mierzysz, czego faktycznie wymaga prompt.

GPT-6.1 Sol to wyostrza i jest to jeden z niewielu fragmentów tego wydania dotyczących tak naprawdę wyłącznie wersji 6.1. Jego drabinka wysiłku rozumowania obejmuje low, medium, high, xhigh i max, a ustawienia none i minimal nie są obsługiwane. GPT-6 Sol akceptuje wszystkie sześć. Nie istnieje zatem na 6.1 żadne ustawienie, które wyłączałoby nakłady na rozumowanie; wartością domyślną jest medium, a część budżetu dotycząca wyjścia nigdy nie jest darmowa.

Połowienie wejścia z pamięci podręcznej, odczytywane tam, gdzie okno jest najszersze

Jedyną stawką na karcie GPT-6.1 Sol, która zmieniła się względem GPT-6 Sol, jest wejście z pamięci podręcznej: z 0,20 USD do 0,10 USD za milion tokenów, co strona modelu przedstawia jako 5% stawki za wejście bez pamięci podręcznej, a przewodnik dostawcy dotyczący pamięci podręcznej nazywa wprost przypadkiem 0,05x w porównaniu ze stawką 0,1x, po której rozliczana jest większość modeli GPT-5.6 i późniejszych. Wejście, zapisy do pamięci podręcznej i wyjście są identyczne na obu kartach, a mnożniki dla długiego kontekstu również są identyczne.

Dokładnie w przypadku obciążenia, którego dotyczy ta strona, to właściwy licznik, który należało zmienić, a powodem jest struktura długiego żądania, a nie jego rozmiar. W powyższym zadaniu na 300 000 tokenów 260 000 tokenów wejściowych to prefiks z pamięci podręcznej — 87 procent wszystkiego, co wysyła żądanie. Linia dotycząca pamięci podręcznej jest zatem największym pojedynczym licznikiem danych wejściowych na rachunku, co jest ogólną właściwością pracy z długim kontekstem: im dłuższe okno wykorzystujesz, tym większa jego część to prefiks, który już wysłano. Zmniejszenie tego licznika o połowę jest warte 0,052 USD w tym żądaniu.

A klif odbiera więcej, niż daje obniżka o połowę, przy tym samym żądaniu. Gdyby rozliczyć je według stawek dla krótkiego kontekstu, poniżej linii to samo zadanie o 300 000 tokenów na GPT-6.1 Sol kosztowałoby 0,166 USD zamiast 0,302 USD — koszt przekroczenia granicy wynosi 0,136 USD, czyli około 2,6 razy więcej, niż wart jest ten jeden zmieniony licznik w tym wydaniu. Powyżej linii stawka za odczyt z pamięci podręcznej wynosi 0,20 USD, co nie jest nową liczbą w tej rodzinie: to dwukrotność stawki nagłówkowej na karcie 6.1 i dokładnie to, ile GPT-6 Sol pobierał za odczyt z pamięci podręcznej poniżej linii przed tym wydaniem. Obciążenie korzystające z pamięci podręcznej w długim kontekście zbiera zmianę stawki nagłówkowej, a następnie oddaje ją na granicy, i to granica — nie model — jest przyczyną.

Jak dobrać rozmiar budżetu kontekstu

Jako procedura, w kolejności, w jakiej obowiązują ograniczenia:

• Policz żądanie, nie szacuj go. WYŚLIJ dokładny ładunek — narzędzia, obrazy, pliki i wszystko inne — metodą POST do endpointu zliczania tokenów wejściowych w Responses API. Przewodnik mówi wprost, dlaczego: zliczenie obejmuje tokeny formatowania dla ról i granic wiadomości, które nigdy nie pojawiają się w tekście możliwym do tokenizowania lokalnie, a lokalne szacunki, takie jak dzielenie liczby znaków przez cztery, są niedokładne w przypadku obrazów, plików i schematów.

• Najpierw zarezerwuj część wyjściową. Wybierz max_output_tokens, pamiętając, że obejmuje ono łącznie rozumowanie, widoczne wyjście i formatowanie, i zacznij od bufora 25 000 tokenów dostawcy, a nie od zera. Twój budżet wejściowy to okno pomniejszone o tę rezerwację, a liczba dziewięćset dwadzieścia dwa to wersja tego samego odejmowania u dostawcy.

• Wyceń zlecenie po obu stronach 272 000, zanim je wyślesz. Ten krok jest na tyle duży, że zlecenie zaprojektowane tak, by trafić tuż poniżej tej granicy, oraz zlecenie zaprojektowane tak, by trafić tuż powyżej niej, to dwa różne produkty.

• Uporządkuj prefiks według stabilności.Instrukcje, potem schematy narzędzi, potem korpus, potem transkrypt. Wszystko, co zmienia się między wywołaniami, należy umieścić na końcu, gdzie powoduje to utratę dopasowania prefiksu, a nie całej pamięci podręcznej.

• Przekrocz 1 024 widocznych tokenów wejściowych, zanim zaczniesz liczyć na pamięć podręczną. Poniżej tego minimum nic nie trafia do pamięci podręcznej, a ukryte tokeny dostawcy nie wliczają się do tego progu.

• Sprawdź, czy ponowne użycie jest prawdopodobne. Prefiks musi zostać ponownie użyty w ciągu 30-minutowego czasu życia pamięci podręcznej i musi trafić na maszynę przechowującą ten wpis; oba te warunki opisano w przewodniku i żaden z nich nie jest właściwością twojego kodu.

• Zmierz ponownie po każdej zmianie modelu lub ustawień. Przejście na GPT-6.1 Sol usuwa pozycję wyłączenia rozumowania, co zmienia liczbę tokenów rozumowania, a więc i wyjściową stronę budżetu — a zmiana poziomu wysiłku rozumowania, narzędzi, schematu ustrukturyzowanego wyjścia lub zarządzania kontekstem może również przesunąć granicę prefiksu i sprawić, że całkowicie stracisz stawkę za pamięć podręczną.

• Zdecyduj, co się stanie, gdy zadanie nie da się skurczyć. Kompakcja to udokumentowana droga wyjścia: żądanie Responses może ustawić context_management z progiem kompakcji, a serwer zastępuje wcześniejszą treść rozmowy nieprzejrzystym elementem kompakcji, który przenosi kluczowy stan dalej w mniejszej liczbie tokenów. To decyzja budżetowa, a nie darmowe przycięcie, ponieważ przewodnik zauważa, że kompakcja „może uniemożliwić ponowne wykorzystanie od pierwszego zmienionego tokenu wzwyż” — przebieg kompakcji unieważnia poprzedzający go prefiks.

Arytmetyka na tej stronie zaczyna się od generacji, którą zastępuje GPT-6.1 Sol, a ten szczebel to ten, który można wywołać już dziś: nasza karta dla openai/gpt-6-sol podaje okno kontekstu o rozmiarze 1 050 000 tokenów z maksymalnym wyjściem 128 000 tokenów według stawek katalogowych OpenAI z 0% marży — cena dostawcy to cena na stronie, a zmiana po stronie dostawcy pojawia się tam tego samego dnia, a nie przy odnowieniu. Nasza karta nie ma własnego pola maksymalnego wejścia, więc liczba 922 000 tokenów dla tego modelu musi pochodzić z dokumentacji samego dostawcy, której ta strona używała w całym tekście. Karta jest przydatna do szacowania rozmiaru: okno i pułap wyjścia, które publikuje, to dwie liczby, które powyższa procedura budżetowa odejmuje od siebie, a szczebel poniżej to ten, na którym można faktycznie przeprowadzić tę procedurę, dopóki 6.1 jest jeszcze nowy. Znajduje się pod adresem https://www.orcarouter.ai/models/openai/gpt-6-sol.