«Выбор модели и уровень рассуждений — это компромисс между интеллектом и ценой»: OpenAI выпустила руководство по семейству GPT-6

Что предлагает руководство

Руководство отвечает на практический вопрос: как выбрать модель GPT-6, дать ей внятные инструкции, удержать долгую работу в нужном русле и подготовить всё к продакшену.

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

Соотносить модель с рабочей нагрузкой, балансируя возможности, стоимость и задержку через выбор модели, уровня рассуждений и скорости.

Согласовать промпты, навыки и инструкции репозитория в том, что модель должна выдать, что она может делать самостоятельно и что считается завершённым.

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

Как выбрать модель и уровень рассуждений

Руководство предлагает думать о выборе модели и уровне рассуждений как о компромиссе между интеллектом и ценой.

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

При оценке лучшей модели для задачи в OpenAI советуют сравнивать цены по каждой модели.

Уровень рассуждений в API выбирается по объёму усилий, которые модель тратит на задачу: Low — рутинные задачи вроде извлечения фактов или небольших правок. Medium — работа, требующая суждения, например планирование функции или сравнение вариантов. High — сложная отладка, более глубокий анализ или внимательное ревью. Extra high и Max — пробовать там, где это поддерживается, если High не хватает, и оставлять только если улучшение оправдывает добавленные время и стоимость.

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

Скорость: Fast mode и Ultrafast

В API предлагается Fast mode, когда важна скорость ответа — например, в чат-приложениях или инструментах для кодинга: он даёт более быстрые и более стабильные времена отклика при более высокой цене за токен, чем стандартная обработка.

В Codex и в API для ускорения генерации токенов предлагается Ultrafast, когда более быстрые ответы стоят премии — например, при быстрых итерациях в кодинге; он ускоряет генерацию токенов независимо от уровня рассуждений и доступен для GPT-6 Astra.

Промпты, навыки и границы решений

Раздел о промптах открывается советом дать модели ясное задание: нужный результат, для кого он, релевантный контекст и ограничения, а также что считается завершённым.

Далее перечислены четыре направления, суммированные из материала OpenAI о переосмыслении навыков и промптов для GPT-6 Astra. Первое — делать навыки лучше: держать описания короткими и явными насчёт того, когда навык должен срабатывать, загружать вспомогательные детали только по необходимости и заменять жёсткие рецепты рекомендациями, подходящими используемым командой моделям.

Второе — обновить AGENTS.md: объяснить, когда релевантны конкретные документы и тесты, и явно разрешить безопасные рутинные рабочие процессы вроде запуска локальных тестов на одноразовых данных без доступа к продакшену.

Третье — задать границы решений: указать, какие действия могут идти самостоятельно, а какие требуют одобрения, заменив сплошные правила «всегда спрашивай» ясными границами.

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

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

Длинные задачи: steering, асинхронные инструменты и делегирование

С семейством GPT-6 можно брать задачи, которые тянутся часы или дни, и руководство перечисляет средства управления такими агентами.

В API первое средство — менять инструкции прямо во время прогона: mid-turn steering позволяет отправить исправление через Responses WebSocket API, пока модель работает, причём обновления ставятся в очередь и не отменяют уже выполняющиеся инструменты и не откатывают завершённые действия.

Второе — продолжать работу, пока выполняется инструмент: асинхронный вызов инструментов даёт модели заниматься независимой работой, пока приложение выполняет более медленную задачу вроде тестов, а результат возвращается, когда он готов; зависимую работу следует начинать только после этого результата.

Третье — делегировать независимые подзадачи: GPT-6.1 Sol поддерживает мультиагентные сценарии в Responses API, умея отдавать независимую работу субагентам, например исследование разных частей кодовой базы, и собирать их выводы в финальный ответ; мультиагентность пока в бете.

В Codex руководство советует использовать уточнения и steering, поскольку долгие задачи вскрывают решения, которых в исходном промпте не предвидели: GPT-6 Astra умеет спрашивать уточнения прямо во время работы, а при смене требований активную задачу можно перенаправить новой информацией, объяснив, что должно измениться, а что остаться прежним.

Работа за компьютером

Возможность computer use позволяет GPT-6 Astra, GPT-6.1 Sol и GPT-6 Luna напрямую взаимодействовать с сайтами и настольными приложениями, даже если у приложения нет API: например, можно попросить модель исследовать баг, исправить код и открыть продукт в браузере, чтобы убедиться, что исправление работает.

Выбирать предлагается самый простой надёжный способ для каждого шага: использовать API или подключённый инструмент, когда он делает работу напрямую, и переходить к computer use, когда модели нужно прочитать экран, нажать кнопку или заполнить форму.

Если computer use встраивается в собственное приложение, модели дают инструмент, умеющий запускать код для управления браузером или рабочим столом: с браузерами работает Playwright, с настольными приложениями — PyAutoGUI.

Подготовка к продакшену

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

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

Для длинных диалогов компакция уменьшает размер контекста, сохраняя состояние, нужное для продолжения.

Также предлагается заранее решить, как вы будете мониторить поведение и проверять контроли данных для своего приложения, а перед выкатом прогнать представительные задачи и измерить успех задачи, задержку и стоимость на одну успешную задачу по чек-листу развёртывания API.