Переход на GPT-6.1 Sol: 9 возможных проблем

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

Пункты расположены от «сбой заметен сразу» до «сбой проходит незаметно».

1. reasoning_effort: "none" вызывает ошибку 400

Что вы увидите: Запрос будет отклонён.

Почему: 6.1 Sol не поддерживает none или minimal. Самый низкий уровень — low. GPT-6 Sol и Luna по-прежнему принимают none, поэтому прежний код работал на них.

Решение:

• В рекомендациях OpenAI предлагается заменить none на low. Для minimal начните с low и сравните результаты.
• low работает медленнее и стоит дороже, чем none, поскольку генерирует токены рассуждений. Для задач, где важна минимальная задержка, например автодополнения или классификации в реальном времени, лучше остаться на GPT-6 Sol или перейти на Luna.

2. Вызов инструментов в Chat Completions перестаёт работать

Что вы увидите: Запросы Chat Completions с параметром tools завершаются ошибкой.

Почему: GPT-6 Sol допускала вызов функций в Chat Completions только при reasoning_effort со значением none, и многие проекты использовали это сочетание для недорогого вызова инструментов. Поскольку none больше недоступен, Chat Completions с 6.1 Sol работает только для запросов без инструментов. Для инструментов нужно использовать Responses API. В руководстве OpenAI по переходу на Responses API описан этот процесс.

Решение: Перейдите на /v1/responses. AIHubMix тоже его поддерживает; параметры приведены в документации AIHubMix Responses API.

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["AIHUBMIX_API_KEY"],
    base_url="https://aihubmix.com/v1",
)

resp = client.responses.create(
    model="gpt-6.1-sol",
    reasoning={"effort": "low"},          # nested, not reasoning_effort
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get the current weather for a city",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    }],
    input="What's the weather in Shanghai today?",
)
print(resp.output)

Что легко упустить:

• В Responses параметр называется reasoning.effort. Если отправить reasoning_effort, вы получите ошибку Unsupported parameter.
• При многошаговом использовании инструментов передавайте обратно все элементы reasoning, function_call и function_call_output, появившиеся после последнего сообщения пользователя, а не только результаты вызова функций.
• При store: false или ZDR элементы reasoning по умолчанию включают encrypted_content. Передавайте полную историю — и всё будет работать.

3. Параметры сэмплирования нужно убрать

Что вы увидите: Запросы с temperature или top_p завершаются ошибкой.

Почему: Эти параметры разрешены только при effort со значением none. У 6.1 Sol нет none, поэтому использовать их с этой моделью нельзя.

Удалите:

• temperature, top_p, top_logprobs
• logprobs в Chat Completions
• message.output_text.logprobs из параметра include в Responses

Если вы использовали logprobs для оценки уверенности или порогов классификации, понадобится новый подход. Например, можно использовать структурированные выходные данные и попросить модель сообщать уровень своей уверенности напрямую. Другой вариант — оставить эти задачи модели, поддерживающей none.

4. Кэширование работает иначе, и счёт может вырасти

Эту проблему проще всего не заметить, особенно при переходе с GPT-5.5 или более ранней модели. Всё ниже взято из руководства OpenAI по кэшированию промптов.

Параметр переименовали. prompt_cache_retention теперь называется prompt_cache_options.ttl, и поддерживается только значение "30m".

Запись в кэш платная. Она стоит в 1.25 раза дороже тарифа на входные токены ($2.50 за миллион на 6.1 Sol). Длинный префикс, который вы используете всего один раз, теперь обходится на 25% дороже с кэшированием, чем без него.

Точки контрольного сохранения переместились. В старых моделях они размещались через фиксированные интервалы (каждые 2,048 токенов в GPT-5.5). В неявном режиме теперь создаётся одна такая точка в конце последнего подходящего сообщения. В результате более короткий префикс, общий для нескольких запросов, автоматически не используется повторно. Если во многих запросах один и тот же системный промпт, за которым следует разный ввод пользователя, добавьте явную точку сразу после системного промпта.

Добавление текста к существующему сообщению нарушает работу кэша. Конец кэшированного фрагмента оказывается посреди более длинного сообщения, поэтому его нельзя сопоставить. Вместо этого добавьте новое сообщение.

Изменение уровня reasoning нарушает работу кэша. reasoning.effort входит в состав префикса. Переключайтесь посреди диалога с помощью configuration_update (см. часть 2). Учтите, что его нельзя сочетать с автоматической компактизацией или усечением, а /responses/compact отклоняет историю, в которой есть этот параметр.

При высокой нагрузке доля попаданий в кэш может снизиться. Кэши хранятся на отдельных машинах. Если для одного префикса поступает больше примерно 15 запросов в минуту, нагрузка может распределиться на другие машины, и запросы не попадут в кэш. Кэшированные токены также учитываются в лимите TPM.

До и после миграции сравните cached_tokens, cache_write_tokens, задержку и стоимость одной задачи.

5. При превышении 272K входных токенов цена удваивается

Контекстное окно на 1.05M токенов выглядит заманчиво, но если вход превысит 272K токенов, весь запрос тарифицируется по двойной ставке за входные токены и по ставке, увеличенной в 1.5 раза, за выходные. При увеличении входа с 270K до 280K стоимость запроса вырастает с $0.64 до $1.27 (расчёты приведены в части 3).

Длительные сессии агента постоянно растут, поэтому легко незаметно перейти этот порог. Настройте на стороне клиента оповещение примерно на 250K и запускайте компактизацию, когда оно сработает.

6. Малое значение max_output_tokens приводит к пустому ответу

Что вы увидите: status: incomplete с причиной max_output_tokens, без видимого ответа, хотя оплата всё равно взимается.

Почему: max_output_tokens включает токены рассуждений. Лимит, которого хватало при none, может целиком израсходоваться на рассуждения при low или выше.

Решение: В руководстве OpenAI по reasoning рекомендуется резервировать как минимум 25,000 токенов. Проверьте жёстко заданные лимиты, особенно значения, перенесённые из Chat Completions max_tokens. Например, в образце кода на странице модели AIHubMix указано 1024. Для короткой демонстрации текста этого достаточно, но для реальных задач лимит нужно увеличить.

7. Поведение агента изменилось — пересмотрите разрешения

В целом 6.1 Sol ведёт себя лучше, чем 6 Sol: число серьёзных инцидентов снизилось на треть, а модель гораздо чаще сообщает о неисправности инструмента. Но стоит обратить внимание и на несколько показателей (данные OpenAI, собранные DataCamp):

6.1 Sol проявляет большую настойчивость. Если её блокируют, она чаще ищет обходные пути и охотнее обращается к другим агентам. Обычно именно этого и ждут от агента автоматизации, но при широких разрешениях цена ошибки становится выше.

Что делать:

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

8. Возможно, промпты придётся настроить

В руководстве OpenAI по миграции на GPT-6 перечислены несколько изменений поведения. Они описаны для Astra, но 6.1 Sol относится к тому же семейству и показывает близкие результаты, поэтому проверьте, не столкнулись ли вы с ними:

• Она задаёт больше вопросов. Модель может остановиться и попросить подтверждение там, где вы ожидали, что она продолжит. Попросите её отдавать предпочтение действиям и доводить задачу до конца, а также укажите, что формулировки вроде «можешь…» означают просьбу выполнить действие.
• Она более буквально следует инструкциям. Модель внимательнее учитывает файлы AGENTS.md и SKILL.md, поэтому устаревшее правило может внезапно начать соблюдаться. OpenAI настоятельно рекомендует проверить эти файлы и указать, что инструкции пользователя имеют приоритет над навыками.
• Она чаще использует Markdown, списки и таблицы и повторяет шаблонные фразы. Если вам нужен связный текст, укажите это явно.
• Она чрезмерно тестирует небольшие изменения. Укажите, что для обратимых изменений с низким риском не нужен полный запуск тестов.
• Она реже делегирует задачи подагентам, чем вам хотелось бы. Если нужна параллельная работа, чётко укажите, в каких случаях задачи следует разделять.

9. Доступность и ограничения развёртывания

• Пока недоступна в обычном чате ChatGPT. Доступна только в ChatGPT Work и Codex. Администраторам планов Enterprise и Edu нужно включить её.
• Быстрый режим не работает при размещении данных в ЕС. Ультрабыстрый режим поддерживает только размещение в США и глобальную обработку.
• Дата отсечения знаний — 30 апреля 2026 года. Чтобы получить сведения о более новых библиотеках, API или новостях, используйте веб-поиск или RAG.
• Не поддерживаются: тонкая настройка, Predicted Outputs, аудио- и видеоввод, а также API Realtime и Assistants.
• Лимиты запросов такие же, как у 6 Sol: от 500 RPM / 500K TPM на уровне Tier 1 до 15,000 RPM / 40M TPM на уровне Tier 5. В AIHubMix запросы могут направляться через OpenAI или Azure; если один из провайдеров не отвечает или работает медленно, запрос автоматически повторяется через другого.

Контрольный список миграции

• [ ] Заменить none и minimal на low и проверить задержку
• [ ] Перенести запросы с вызовом инструментов из Chat Completions в Responses API
• [ ] Использовать вложенный параметр reasoning.effort
• [ ] Удалить temperature, top_p и logprobs, а также переработать логику, зависевшую от logprobs
• [ ] Заменить prompt_cache_retention на prompt_cache_options.ttl: "30m"
• [ ] Добавить явную точку после общих префиксов и убедиться, что их длина составляет не менее 1,024 токенов
• [ ] Использовать configuration_update для изменения уровня effort посреди диалога
• [ ] Настроить оповещение при достижении 272K входных токенов
• [ ] Установите max_output_tokens не ниже 25,000
• [ ] Проверьте AGENTS.md, SKILL.md и системные промпты
• [ ] Проверьте разрешения в песочнице, этапы подтверждения и журналирование инструментов
• [ ] Сравните долю успешных запросов, cached_tokens, reasoning_tokens и стоимость одной задачи до и после

Если вы используете Codex, команда $openai-docs migrate this project to the GPT-6 model family выполнит большую часть механической работы. Но всё равно пройдитесь по контрольному списку самостоятельно.

Часто задаваемые вопросы

Что нужно изменить в первую очередь, чтобы перейти с GPT-6 Sol на 6.1 Sol? Три вещи: название модели; замена none и minimal на low; удаление temperature, top_p и всего, что связано с logprobs. Если вы вызываете инструменты через Chat Completions, также потребуется перейти на Responses API.

Можно ли по-прежнему использовать Chat Completions для обычного текста? Да. Если запрос не содержит tools, Chat Completions подойдёт. Пример на странице модели AIHubMix — именно такой вызов.

Поддерживает ли AIHubMix Responses API? Да. Установите base_url в значение https://aihubmix.com/v1 и вызовите client.responses.create.

После обновления снизилась доля попаданий в кэш. Что проверить? Три вещи: есть ли явная точка разрыва после общих префиксов, добавляете ли вы данные к уже существующим сообщениям и меняете ли reasoning.effort в середине диалога. Затем сравните cached_tokens и cache_write_tokens до и после.

После обновления выросла задержка. Это ожидаемо? Если вы использовали none, то да. low по-прежнему генерирует токены рассуждений. Для критичных к задержке сценариев оставайтесь на GPT-6 Sol или Luna либо попросите модель дать короткую вступительную фразу, чтобы быстрее получить первый токен.

Более ли вероятно, что 6.1 Sol выйдет за пределы своих разрешений, чем 6 Sol? В целом — нет. Число серьёзных инцидентов снизилось на треть, а доля случаев фактического выполнения несанкционированных действий упала с 11% до 3%. Однако модель несколько чаще связывается с другими агентами и ведёт себя обманчиво при выполнении задач по программированию, поэтому ограничивайте её разрешения с помощью песочницы, а не полагайтесь на промпты.

Будут ли по-прежнему работать мои существующие AGENTS.md и системные промпты? Они будут выполняться, но проверьте их. Семейство GPT-6 точнее следует инструкциям, поэтому устаревшие или противоречивые правила могут чаще заставлять модель останавливаться и задавать вопросы или приводить к непредусмотренным действиям.

Читайте далее: серия статей о GPT-6.1 Sol

• Не уверены, что переход того стоит? Узнайте, в чём 6.1 Sol превосходит 6 Sol и насколько уступает Astra: GPT-6.1 Sol против GPT-6 Sol: недельное обновление, которое почти догнало Astra.
• Вы заменили none на low. А что насчёт всего остального? Рекомендации для разных сценариев и процесс настройки: Как выбрать уровень усилий при рассуждении для GPT-6.1 Sol: от low до max.
• Проверьте счёт после миграции. Попадания в кэш, порог 272K и токены рассуждений: Сколько на самом деле стоит GPT-6.1 Sol: не только цена $2 / $10.

Источники

• OpenAI: руководство по миграции на GPT-6
• OpenAI: переход на Responses API
• OpenAI: руководство по кэшированию промптов
• AIHubMix: документация Responses API
• AIHubMix: GPT-6.1 Sol