Контекстное окно GPT-6.1 Sol: 1 050 000 токенов, отметка 922 000 и обрыв на 272 000

На странице модели GPT-6.1 Sol у поставщика, прочитанной 7 октября 2026 года, указано контекстное окно в 1 050 000 токенов и максимальный объём вывода в 128 000 токенов. На той же странице в машиночитаемой форме, которую получаешь, добавив .md к её URL, приводится третья цифра, которую отображаемая страница никогда не печатает: максимум 922 000 входных токенов. GPT-6 Sol, модель, на смену которой 29.09.2026 выпустили версию 6.1, публикует на своей собственной странице ту же самую пару предельных значений и ту же строку с 922 000 в своей markdown-форме. В нашей собственной карточке модели для openai/gpt-6-sol окно указано как 1 050 000 токенов, а предел вывода — как 128 000; первое из этих значений отображается как «1M» в блоке характеристик, а для той же модели в таблице сравнения ниже на той же странице печатается «1.1M».

Итак, страницы действительно расходятся, и стоит уточнить, в чём именно. Отрендеренная строка спецификаций вендора даёт окно и потолок вывода, но не потолок ввода. Markdown-документация вендора для той же модели даёт все три. Тот, кто рассчитывает запрос по отрендеренной странице, работает с на одно ограничение меньше, чем опубликовал вендор, и недостающее — это число, которое решает, поместится ли запрос.

Три цифры, три источника и одно вычитание, которое никто не записывает

Ниже приведено каждое число вместе с документом, из которого оно взято; все они прочитаны 7 октября 2026 года.

• окно контекста 1,050,000 — страница модели gpt-6.1-sol у поставщика, в отрисованной строке характеристик и в её markdown-формате, а также та же цифра на странице gpt-6-sol. Это также то, что возвращает наш каталог для openai/gpt-6-sol и openai/gpt-6-luna, где поле указано как 1,050,000, а не округлено.

• 128,000 выходных токенов максимум — та же страница, те же две формы, для обоих поколений. В поле нашей карточки указано 128,000; на её дисплее отображается округлённое «128K».

• максимум 922 000 входных токенов — это markdown-версия страницы модели gpt-6-sol поставщика и её страницы gpt-6.1-sol. Её нет в отображаемой полосе ни одной из этих страниц, и её нет в поле нашего каталога для этой модели, которое заканчивается на окне и пределе вывода.

Три числа арифметически согласуются между собой: 922 000 плюс 128 000 — это ровно 1 050 000. Собственное руководство поставщика по рассуждениям описывает механизм, который делает это тождество осмысленным, хотя на странице модели сложение так и не выполняется, — токены рассуждений, говорится в нём, «всё ещё занимают место в контекстном окне модели», и если сгенерированные токены «достигают предела контекстного окна или заданного вами значения max_output_tokens», ответ возвращается помеченным как incomplete. Окно, совместно используемое для того, что подаётся на вход, и того, что выдаётся на выходе, — это окно, в котором верхний предел для входа равен размеру окна минус резерв для вывода.

Эта интерпретация подтверждается, но не доказана, и эти две вещи стоит разделять. Документально подтверждено: окно 1 050 000, лимит вывода 128 000 и максимальный ввод 922 000. Вывод же состоит в том, какой из них срабатывает как ограничение первым. Этот вывод верен для каждого запроса, который резервирует весь разрешённый объём вывода, и неверен для любого запроса, который этого не делает — установите max_output_tokens равным 4 000, и запрос с 1 046 000 входных токенов явно не отклоняется. Пока поставщик не впишет это вычитание на страницу, где живут эти числа, рассматривайте эту пару как форму бюджета, а не как жёсткое правило допуска, и проверяйте по эндпоинту подсчёта, а не по посту в блоге.

Контекст — это не цена: шаг в 272 000 токенов

Более крупное окно — это заявление о вместимости. Это не заявление о стоимости, и в этом семействе эти два понятия расходятся на документированной границе. На странице цен поставщика правило изложено в одном предложении: для запросов с более чем 272K входных токенов тарифы на вход и кэш умножаются на 2, а на выход — на 1,5 для всего запроса. Собственное определение двух столбцов на той же странице: «Короткий контекст: ≤272K входных токенов. Длинный контекст: >272K входных токенов».

Внимательно прочитайте слово full. Тариф не облагает токены за чертой — он переоценивает всё, включая самый первый токен. И это не изменение 6.1: то же самое правило с тем же самым порогом применяется к GPT-6 Sol, поэтому этот обрыв следует относить на счёт тарифа, а не релиза.

Проведите одно задание с длинным контекстом через обе стороны по опубликованным тарифам GPT-6.1 Sol, при условии, что префикс уже находится в кэше, чтобы плата за запись в кэш не искажала сравнение:

• 240 000 входных токенов (200 000 кэшированных, 40 000 новых), 6 000 выходных — новые входные токены: 40 000 по $2.00 за миллион — это $0.080; кэшированные входные токены: 200 000 по $0.10 — это $0.020; выходные токены: 6 000 по $10.00 — это $0.060. Итого: $0.160.

• 300 000 входных токенов (260 000 кэшированных, 40 000 свежих), 6 000 выходных — теперь запрос превышает порог, поэтому меняются все тарифы: свежие входные 40 000 по $4,00 — это $0,160; кэшированные входные 260 000 по $0,20 — это $0,052; выходные 6 000 по $15,00 — это $0,090. Итого $0,302.

На двадцать пять процентов больше входных токенов — и счёт на 89 процентов больше. Прогоните ту же пару на GPT-6 Sol, и картина сохраняется, только наклон круче: $0.180 ниже линии против $0.354 выше неё, потому что кэшированная ставка старой карты в $0.20 стоит там же, где и кэшированная ставка 6.1 для длинного контекста. Переход — это ступенька, а не наклон, и самый дешёвый способ в этом убедиться — перешагнуть её на волосок. Полностью некэшированный запрос на 271 000 токенов с 1 000 выходных токенов стоит $0.552; при 273 000 он стоит $1.107. На семь десятых процента больше входных токенов — в 2.01 раза больше денег. Уберите 2 000 токенов обратно из этого запроса, и счёт падает с $1.107 до $0.552 — меньше одного процента входных данных за половину стоимости.

Ничто в этом разделе не о том, что окно GPT-6.1 Sol большое. Речь о том, что окно достаточно велико, чтобы достичь границы, которая стоит больше, чем способен купить размер окна.

Что на самом деле заполняет 1 050 000 токенов

Контекстный бюджет состоит из шести компонентов, и они кэшируются не одинаково. Приблизительные доли на примере иллюстративного агентного запроса на 240 000 токенов; пропорции — наши собственные, а правила кэшируемости — от вендора, из его руководства по кэшированию промптов, прочитанного в тот же день.

• Системное содержимое и форматирование запросов, внедряемые провайдером, — выводятся перед вашими сообщениями, тарифицируются как ввод и явно исключаются из минимальной длины, подлежащей кэшированию. Не вам это контролировать, и не вам это урезать.

• Ваши инструкции разработчика и системные инструкции, около 6 000 токенов. Можно кэшировать. Это начало префикса, поэтому изменение здесь делает недействительным всё, что идёт за ним.

• Определения инструментов и схемы, около 14 000 токенов для хостируемой поверхности инструментов плюс ваши функции. Кэшируемо — и это самая хрупкая часть префикса: в руководстве имена инструментов, описания, схемы, порядок и инструкции для конкретных инструментов перечислены как то, что сдвигает границу префикса.

• Извлечённый корпус, около 180 000 токенов. Может кэшироваться и является, бесспорно, самой крупной строкой. Кэшировать его стоит только в том случае, если он побайтово стабилен между вызовами — корпус, пересобираемый при каждом запросе, — это корпус по полной цене.

• Накопленный транскрипт — предыдущие ходы и результаты инструментов — около 30 000 токенов и растёт. Кэшируется до последнего изменения; результат инструмента, полученный на этом ходу, — это свежий ввод по полной ставке.

• Токены рассуждений — генерируются, никогда не кэшируются, тарифицируются как выходные. Они расходуют контекстное окно и невидимы в теле ответа.

Из этого списка непосредственно вытекают два эксплуатационных замечания. Во-первых, записи кэша хранятся на отдельных машинах: в руководстве сказано, что запрос может повторно использовать префикс, «только если он попадает на машину, на которой есть соответствующая запись, срок действия которой не истёк», и что маршрутизация переполнения начинается примерно при превышении 15 запросов в минуту. Префикс, стабильный в вашем коде, всё равно может давать промах в продакшене. Во-вторых, минимальный кэшируемый префикс — 1 024 видимых входных токена, а скрытые системные токены в него не засчитываются, поэтому небольшой системный промпт не является кэшируемым префиксом, независимо от того, насколько велик окружающий его запрос.

Потолок вывода — это отдельный бюджет, а не вторая порция.

Ограничение в 128 000 выходных токенов не означает 128 000 токенов ответа. В руководстве по рассуждениям прямо сказано, что max_output_tokens ограничивает общий объём, генерируемый моделью, «включая токены рассуждений, видимые выходные токены и невидимые токены форматирования», а также что токены рассуждений тарифицируются как выходные, занимая при этом место в окне.

Это делает усечение проектным решением, а не крайним случаем — из-за того, как именно оно проявляется при сбое. Когда генерация достигает лимита, ответ возвращается со статусом incomplete и причиной max_output_tokens, и руководство предупреждает, что это «может произойти до того, как будут созданы какие-либо видимые токены вывода, а значит, вы можете понести расходы за входные токены и токены рассуждений, так и не получив видимого ответа». Бюджет, который тратит всё окно на вход и оставляет резерв на вывод на волю случая, — это бюджет, который может выставить счёт за полный запрос с длинным контекстом и вернуть ничего такого, что вызывающая сторона смогла бы разобрать. стартовая рекомендация самого вендора — резервировать не менее 25 000 токенов на рассуждения и вывод, пока вы ещё только измеряете, что на самом деле нужно промпту.

GPT-6.1 Sol заостряет это, и это одна из немногих действительно специфичных для 6.1 строк в релизе. Его лестница усилий рассуждения включает low, medium, high, xhigh и max, а настройки none и minimal не поддерживаются. GPT-6 Sol поддерживает все шесть. Поэтому на 6.1 нет настройки, которая отключала бы расходы на рассуждения; по умолчанию используется medium, а часть бюджета, отведённая на вывод, никогда не бывает бесплатной.

Сокращение вдвое кэшированного ввода читайте там, где окно шире всего.

Единственный тариф в карточке GPT-6.1 Sol, который изменился не в пользу GPT-6 Sol, — это кэшированный ввод: с $0,20 до $0,10 за миллион токенов; страница модели указывает его как 5% от тарифа на некэшированный ввод, а руководство производителя по кэшированию явно называет его случаем 0,05x в противовес 0,1x, по которому тарифицируется большинство моделей GPT-5.6 и более поздних. Ввод, запись в кэш и вывод в обеих карточках одинаковы, и множители для длинного контекста тоже идентичны.

Именно для той рабочей нагрузки, которой посвящена эта страница, сдвинуть нужно было именно этот показатель, и причина — состав длинного запроса, а не его размер. В задании на 300 000 токенов выше 260 000 входных токенов — это кэшированный префикс, то есть 87 процентов всего, что отправляет запрос. Таким образом, строка кэша — крупнейший отдельный показатель входных данных в счёте, а это общее свойство работы с длинным контекстом: чем длиннее используемое окно, тем большая его часть — уже отправленный вами префикс. Сокращение этого показателя вдвое экономит $0.052 на этом запросе.

И обрыв забирает обратно больше, чем даёт снижение вдвое, на том же запросе. Если бы та же 300 000-токенная задача на GPT-6.1 Sol оценивалась по тарифам для короткого контекста, действующим ниже порога, она стоила бы $0,166 вместо $0 — стоимость пересечения $0,136, или примерно в 2,6 раза больше того, сколько стоит единственный изменённый счётчик тарификации в этом релизе. Выше порога тариф на кэшированное чтение составляет $0,20, и это не новое число для этого семейства: оно вдвое превышает заявленную цену на карточке 6.1 и в точности равно тому, что GPT-6 Sol взимал за кэшированное чтение ниже порога до этого релиза. Длинноконтекстная рабочая нагрузка с кэшированием получает изменение заявленной цены, а затем отдаёт его обратно на границе, и причина — граница, а не модель.

Как рассчитать размер контекстного бюджета

Как процедура, в порядке связывания ограничений:

• Подсчитывайте запрос, а не оценивайте его. Отправьте точную полезную нагрузку — инструменты, изображения, файлы и всё остальное — в конечную точку подсчёта входных токенов в Responses API. Руководство прямо говорит, почему: подсчёт включает форматирующие токены для ролей сообщений и границ, которые никогда не встречаются в тексте, который можно токенизировать локально, а локальные оценки вроде «символы, делённые на четыре» неточны для изображений, файлов и схем.

• Сначала зарезервируйте сторону вывода. Выбирая max_output_tokens, помните, что он охватывает рассуждения, видимый вывод и форматирование вместе, и начинайте с буфера поставщика в 25 000 токенов, а не с нуля. Ваш бюджет ввода — это окно минус этот резерв, а цифра девятьсот двадцать два — это версия того же вычитания от поставщика.

• Прежде чем отправлять заявку, оцените её по обе стороны от 272 000. Шаг настолько велик, что заявка, рассчитанная на то, чтобы попасть чуть ниже порога, и заявка, рассчитанная на то, чтобы попасть чуть выше него, — это разные продукты.

• Упорядочите префикс по стабильности. Инструкции, затем схемы инструментов, затем корпус, затем транскрипт. Всё, что меняется между вызовами, должно располагаться в конце, где это обходится потерей совпадения префикса, а не всего кэша.

• Наберите 1 024 видимых входных токена, прежде чем рассчитывать на кэш.Ниже этого минимума ничего не кэшируется, а скрытые токены провайдера в него не засчитываются.

• Проверьте, что переиспользование правдоподобно. Префикс должен быть переиспользован в течение 30-минутного времени жизни кэша и должен попасть на машину, хранящую эту запись; и то, и другое описано в руководстве, и ни то, ни другое не является свойством вашего кода.

• Повторно измеряйте после любого изменения модели или настроек. Переход на GPT-6.1 Sol убирает позицию с отключённым reasoning, из-за чего меняется количество токенов рассуждений, а значит, и выходная часть бюджета, — а изменение reasoning effort, инструментов, схемы структурированного вывода или управления контекстом тоже может сдвинуть границу префикса и полностью лишить вас кэшированной ставки.

• Решите, что произойдёт, когда задание не станет меньше. Компактизация — это документированный выход: запрос Responses может задать context_management с порогом компактизации, и сервер заменяет предыдущее содержимое разговора непрозрачным элементом компактизации, который переносит ключевое состояние дальше с меньшим числом токенов. Это решение о бюджете, а не бесплатное усечение, поскольку в руководстве отмечается, что компактизация «может предотвратить повторное использование, начиная с первого изменённого токена» — проход компактизации аннулирует предшествующий ему префикс.

Арифметика на этой странице начинается с поколения, на смену которому приходит GPT-6.1 Sol, и именно эта ступень доступна для вызовов сегодня: наша карточка для openai/gpt-6-sol указывает контекстное окно в 1 050 000 токенов при максимальном выводе 128 000 токенов по прайсовым тарифам OpenAI с наценкой 0% — цена поставщика — это цена на странице, и изменение от поставщика появляется там в тот же день, а не при продлении. Наша карточка не содержит собственного поля максимального ввода, поэтому значение 922 000 токенов для этой модели должно браться из собственной документации поставщика, что и использовалось на этой странице на всём её протяжении. Чем карточка полезна — так это для оценки размеров: окно и потолок вывода, которые она всё же публикует, — это два числа, которые процедура бюджетирования выше вычитает одно из другого, а ступень ниже — та, к которой вы действительно можете применить эту процедуру, пока 6.1 ещё новая. Она находится по адресу https://www.orcarouter.ai/models/openai/gpt-6-sol.