Флаг Codex CLI —model (-m): как выбрать модель ИИ

Флаг Codex CLI --model применяется для выбора модели, которая будет обрабатывать запрос в конкретном запуске Codex. С его помощью можно явно указать нужную модель вместо той, что используется по умолчанию: например, выбрать более быструю модель для простого рефакторинга или более сильную — для разбора большой кодовой базы и сложной архитектурной задачи.

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

Обычно флаг указывают вместе с командой codex и текстом запроса. Короткая форма — -m. Важно понимать, что доступность конкретного имени модели зависит от установленной версии Codex CLI, настроек аккаунта, выбранного провайдера и текущей конфигурации. Поэтому правильная работа начинается не с механического копирования названия модели, а с проверки того, какие варианты доступны именно в вашем окружении.

Как использовать

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

Флаг обычно передают в виде --model <имя-модели>, а его сокращённый вариант — -m <имя-модели>. Значение после флага должно однозначно определять модель.

Базовая форма запуска выглядит так:

codex --model <имя-модели> "текст задачи"

Короткая запись выполняет ту же функцию:

codex -m <имя-модели> "текст задачи"

Если запрос состоит из нескольких слов, его удобно заключать в кавычки. Это особенно важно в оболочках, где пробелы разделяют аргументы командной строки. В Unix-подобных системах обычно подходят двойные кавычки, а в PowerShell и Windows CMD правила экранирования могут отличаться для специальных символов.

Запись	Назначение	Когда использовать
--model	Полное имя флага	В документации, скриптах и командах, где важна читаемость
-m	Короткий псевдоним флага	В интерактивной работе и коротких командах
<имя-модели>	Идентификатор выбранной модели	Заменяется на конкретное доступное имя
"текст задачи"	Инструкция для Codex	Передаётся после параметров команды

Порядок аргументов обычно не должен становиться проблемой: параметры вроде --model принято располагать до основного текста запроса, чтобы команда легче читалась. Если вы используете дополнительные флаги, придерживайтесь последовательной структуры: сначала параметры запуска, затем путь или режим работы, затем инструкция.

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

Что проверить	Зачем это нужно	Практический результат
Версию Codex CLI	Синтаксис и список моделей могут обновляться	Понимание возможностей установленного клиента
Список доступных моделей	Не каждое имя разрешено аккаунту или провайдеру	Выбор рабочего значения для --model
Авторизацию	Модель может быть недоступна без действующей сессии	Исключение ошибок доступа
Лимиты и тариф	Разные модели могут иметь разные ограничения	Предсказуемые расходы и скорость

Когда применять

Выбор модели имеет смысл не только тогда, когда команда «не работает». На практике --model помогает управлять качеством, скоростью, стоимостью и воспроизводимостью работы Codex. Это своего рода переключатель режима: вместо универсального варианта вы явно задаёте, какой тип вычислительного поведения нужен для задачи.

Хорошая модель — не обязательно самая мощная. Лучший выбор определяется задачей, ограничениями проекта и ценой ошибки.

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

Для сложных задач приоритеты меняются. Анализ взаимосвязей между модулями, поиск причины нестабильного теста, проектирование миграции базы данных или проверка большого pull request требуют более глубокого рассуждения. Здесь оправдано явно выбрать модель, которая лучше справляется с длинным контекстом и многошаговым анализом.

Тип задачи	Что обычно важнее	Предпочтительная стратегия
Переименование и форматирование	Скорость	Использовать быструю доступную модель
Добавление небольшого теста	Баланс скорости и качества	Выбрать универсальную модель
Отладка сложного бага	Глубина анализа	Рассмотреть более сильную модель
Проектирование архитектуры	Качество рассуждения и контекст	Выбрать модель с подходящими возможностями
Массовая автоматизация	Стоимость, стабильность, повторяемость	Зафиксировать модель в скрипте

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

В командной работе фиксированная модель также облегчает обсуждение результатов. Если один разработчик получает исправление от одной модели, а другой — от другой, сравнивать качество становится сложнее. В README, Makefile, CI-конфигурации или внутренней инструкции можно указать рекомендуемый вариант и объяснить, почему он выбран.

Ситуация	Стоит ли указывать --model	Причина
Разовый эксперимент	Желательно	Удобно сравнить разные модели
Повторяемый скрипт	Да	Нужно уменьшить зависимость от настроек по умолчанию
Командный стандарт	Да	Все участники работают в сопоставимых условиях
Быстрая ручная подсказка	Не обязательно	Модель по умолчанию может быть вполне достаточна
Работа с чувствительным кодом	Проверить особенно внимательно	Важно учитывать доступность, политики и ограничения провайдера

Примеры использования

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

Выбор модели для объяснения функции

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

codex --model fast-model "Объясни функцию calculate_total в текущем проекте. Не изменяй файлы, перечисли входные данные, побочные эффекты и возможные ошибки."

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

Исправление простого теста

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

codex -m general-model "Исправь падающий тест в tests/cart.test.js. Найди причину, измени только необходимые файлы и в конце объясни внесённые изменения."

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

Анализ сложной ошибки

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

codex --model reasoning-model "Проанализируй ошибку race condition в сервисе очередей. Изучи логи, найди возможные сценарии гонки, предложи исправление и добавь тест на воспроизведение."

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

Рефакторинг с сохранением поведения

Для рефакторинга важно не просто попросить «сделать код лучше», а зафиксировать ограничения. Например, можно потребовать сохранить публичный API и существующее поведение.

codex -m code-model "Проведи рефакторинг модуля src/parser.ts: убери дублирование, сохрани публичные типы и поведение, не меняй формат внешнего JSON. После изменений запусти связанные тесты."

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

Подготовка миграции базы данных

Миграции относятся к задачам с повышенной ценой ошибки. Здесь модель следует использовать как помощника для анализа и подготовки, но не как автоматический механизм без проверки.

codex --model reasoning-model "Изучи модели users и orders. Подготовь план миграции для добавления индекса по customer_id, оцени влияние на существующие запросы и не выполняй миграцию автоматически."

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

Проверка pull request

Явный выбор модели помогает сделать ревью повторяемым. В запросе полезно перечислить критерии: корректность, безопасность, регрессии, тестовое покрытие и читаемость.

codex -m review-model "Проведи ревью текущих изменений относительно основной ветки. Ищи логические ошибки, уязвимости, регрессии и недостающие тесты. Сначала перечисли проблемы по приоритету, затем предложи исправления."

Формат «сначала проблемы, потом решения» помогает не смешивать наблюдения с предположениями и облегчает ручную проверку.

Генерация документации

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

codex --model general-model "Обнови README для пакета notifications на основе текущего кода. Описывай только реально поддерживаемые параметры и команды, не меняй исходные файлы."

Такой сценарий позволяет быстро закрыть пробелы в документации, но каждое утверждение всё равно стоит сверить с кодом и фактическим запуском.

Сравнение двух моделей на одной задаче

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

codex --model fast-model "Предложи план оптимизации функции search_users без изменения API."

codex --model reasoning-model "Предложи план оптимизации функции search_users без изменения API."

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

Использование в скрипте

В автоматизированном сценарии значение модели можно вынести в переменную. Это упрощает замену модели и делает команду заметно читаемее.

MODEL_NAME=general-model
codex --model "$MODEL_NAME" "Проверь изменённые файлы и составь список потенциальных регрессий."

Перед использованием в CI проверьте, как конкретная оболочка обрабатывает переменные, кавычки, секреты и коды завершения команд.

Запуск с явным ограничением задачи

Иногда важнее не только выбрать модель, но и не дать ей выйти за пределы запроса. Такой подход особенно полезен при работе с большим репозиторием.

codex -m fast-model "Работай только с src/utils/date.ts. Найди ошибку в обработке часового пояса, предложи минимальное исправление и не трогай другие файлы."

Ограничение области не является заменой ревью, но заметно снижает объём неожиданных изменений.

Сценарий	Пример выбора	Что проверять после ответа
Объяснение кода	Быстрая модель	Соответствие объяснения фактической реализации
Рефакторинг	Универсальная или сильная модель	Тесты и сохранение API
Ревью	Модель с хорошим анализом	Реальность найденных проблем
CI-проверка	Зафиксированная стабильная модель	Повторяемость и код завершения

Чем отличается от других команд и параметров

Флаг --model часто путают с другими параметрами командной строки. Причина проста: все они влияют на запуск Codex, но делают это на разных уровнях. Один выбирает модель, другой меняет способ авторизации, третий задаёт режим взаимодействия, а четвёртый определяет сам текст задачи.

Инструмент	Что меняет	Чего не делает
--model / -m	Выбирает модель	Не меняет права доступа и файлы сам по себе
Промпт	Определяет задачу и ограничения	Не выбирает модель автоматически, если это не предусмотрено конфигурацией
Профиль или конфигурация	Может задавать набор постоянных параметров	Не всегда заменяет явный параметр в конкретном запуске
Режим подтверждений	Определяет, когда Codex должен спрашивать разрешение	Не меняет интеллектуальные возможности модели

--model и текстовый запрос

Текстовый запрос отвечает на вопрос «что нужно сделать», а --model — «какой моделью это делать». Эти элементы дополняют друг друга и не являются взаимозаменяемыми.

codex --model fast-model "Переименуй локальную переменную total в subtotal в одном файле."

Если убрать текст задачи, модель может не понять цель запуска. Если убрать --model, Codex обычно использует модель по умолчанию или настройки конфигурации.

--model и короткий псевдоним -m

Это не две разные функции, а две формы одного параметра. Длинная форма лучше читается в документации, короткая удобнее для ручного ввода.

codex --model general-model "Объясни структуру проекта."

codex -m general-model "Объясни структуру проекта."

Обе команды задают одинаковый выбор модели, если оболочка и версия CLI принимают такой синтаксис.

--model и конфигурация

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

codex "Проверь форматирование проекта"

codex --model review-model "Проведи глубокое ревью изменённых файлов"

В первом случае действует текущая конфигурация, во втором модель задаётся непосредственно командой. При конфликте настроек точный приоритет зависит от версии и способа конфигурирования, поэтому его следует проверять в документации конкретного релиза.

--model и режим подтверждений

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

codex --model reasoning-model "Проанализируй миграцию и сначала покажи план. Не выполняй команды, изменяющие базу данных."

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

Типичные ошибки

Ошибки при работе с --model обычно связаны не со сложностью флага, а с неверными ожиданиями: пользователь предполагает, что любое имя допустимо, что мощная модель всегда лучше или что выбор модели автоматически делает результат безопасным.

Неподдерживаемое имя модели

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

codex --model old-model "Проверь текущие изменения"

Если CLI сообщает, что модель неизвестна или недоступна, проверьте список поддерживаемых значений, обновите документацию и убедитесь, что выполнена авторизация.

Симптом	Возможная причина	Что сделать
Unknown model	Опечатка или устаревшее имя	Проверить доступные идентификаторы
Access denied	Нет разрешения для модели	Проверить аккаунт, тариф и провайдера
Параметр не распознан	Старая версия CLI или неверный синтаксис	Проверить версию и справку
Запуск зависает	Сетевая проблема, лимит или ожидание подтверждения	Проверить соединение и состояние процесса

Перепутаны имя модели и отображаемое название

В интерфейсе сервиса модель может показываться красивым маркетинговым названием, тогда как CLI ожидает технический идентификатор. Эти строки не всегда совпадают.

codex --model "Самая умная модель" "Проанализируй архитектуру"

В командной строке нужно использовать именно значение, которое понимает Codex CLI, а не произвольную подпись из веб-интерфейса.

Неправильно использован короткий флаг

Короткая форма требует значения после себя. Если написать -m без имени модели, следующий аргумент может быть ошибочно воспринят как значение параметра.

codex -m "Исправь тесты"

В таком случае строка «Исправь тесты» может быть интерпретирована не как запрос, а как название модели. Правильная структура должна содержать оба элемента:

codex -m general-model "Исправь тесты"

Ожидание, что сильная модель исправит неточный запрос

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

codex --model reasoning-model "Сделай проект лучше"

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

codex --model reasoning-model "Изучи src/cache.ts, найди причину лишних запросов к Redis, предложи минимальное исправление, добавь тест и не меняй публичный API."

Выбор модели без учёта стоимости и лимитов

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

codex --model premium-reasoning-model "Переименуй переменную index в i в одном коротком файле"

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

Ошибка	Риск	Профилактика
Устаревшее имя	Команда не запускается	Проверять актуальный список моделей
Слишком общий промпт	Непредсказуемые изменения	Указывать область и критерии результата
Постоянный выбор самой дорогой модели	Лимиты расходуются без необходимости	Соотносить модель со сложностью задачи
Отсутствие проверки результата	Ошибки попадают в код	Запускать тесты и проводить ревью

Краткая памятка

Флаг --model нужен для явного выбора модели в конкретном запуске Codex CLI. Его короткий аналог — -m. Параметр отвечает именно за выбор модели, а не за текст инструкции, права доступа, режим подтверждений или безопасность операций.

Задача	Команда-шаблон	Комментарий
Полная форма	codex --model MODEL "PROMPT"	Наиболее читаемый вариант
Короткая форма	codex -m MODEL "PROMPT"	Эквивалент полной формы
Проверка кода	codex -m MODEL "Проверь изменённые файлы"	Уточните критерии ревью
Ограниченный рефакторинг	codex --model MODEL "Измени только FILE"	Явно задайте область изменений

Перед запуском полезно пройти короткий чек-лист:

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

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