Как я не даю быстро выжечь лимит Codex

Недавно я наблюдал, как две задачи по автоматизации браузера в Codex израсходовали 170,123 и 110,180 токенов.

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

Именно тогда я перестал воспринимать лимит использования Codex как загадочное число, которым управляет только мой тарифный план ChatGPT.

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

Прочитав актуальную документацию OpenAI и сравнив её с отзывами пользователей Codex, я изменил и свою конфигурацию, и подход к распределению работы. Эта статья — та самая настройка, которую я бы посоветовал тому, кто хочет, чтобы Codex продержался всю реальную рабочую неделю.

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

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

Фразу «лимит Codex» часто используют для трёх разных вещей.

Первое — это лимит тарифного плана ChatGPT. Если вы входите в Codex с аккаунтом ChatGPT, Codex расходует лимит, привязанный к этому плану. Codex и другие рабочие продукты ChatGPT могут делить один и тот же пул.[2][3]

Второе — это контекстное окно внутри одной беседы. Длинный чат накапливает промпты, исходные файлы, результаты команд, скриншоты, журналы тестов и предыдущие ответы. Codex умеет сжимать эту историю, но беседа всё равно может стать дорогой и расфокусированной ещё до того, как упрётся в жёсткую границу контекста.[6][7]

Третье — это оплата по API или лимит скорости API. Если вы авторизуетесь по API-ключу, а не через подписку ChatGPT, расход тарифицируется отдельно по ценам API. Переход на API-ключ позволяет продолжить работу после исчерпания лимита подписки, но не уменьшает объём вычислений. Он переносит расход в другой счёт.[3]

Эта статья о том, как сохранить лимит ChatGPT для Codex за счёт легальной настройки и более продуманного проектирования задач.

Самая большая экономия — за счёт выбора модели

На текущей странице цен OpenAI видно, почему маршрутизация моделей так важна. Для тарифов Plus и Standard Business примерное число локальных сообщений за пятичасовой период составляет от примерно 5-45 для GPT-6 Astra, 15-160 для GPT-6.1 Sol и 350-3,000 для GPT-6 Luna. Это оценки, а не гарантированные лимиты сообщений, и сложная работа может израсходовать гораздо больше, чем небольшой запрос.[1]

Этот разрыв меняет моё представление о Codex.

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

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

Моё новое правило простое:

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

Смена модели — это не оценка важности проекта. Это просто подбор инструмента под задачу.

Быстрый режим — дорогое удобство

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

Сейчас OpenAI указывает, что быстрый режим расходует включённый лимит по ставке в 2.5 раза выше стандартной, а купленные кредиты — вдвое дороже стандартной ставки.[1][4] Если я стараюсь растянуть недельный лимит, оставлять быстрый режим включённым на долгую автономную сессию почти не имеет смысла.

В интерактивном CLI /fast — это переключатель. Один запуск включает быстрый режим, ещё один — выключает. Для профиля с оглядкой на расход я предпочитаю явно прописать стандартную скорость в конфигурации, чтобы не держать в голове текущее состояние переключателя.[4][6]

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

Мой экономичный профиль

Текущие версии Codex поддерживают файлы профилей в %USERPROFILE%\.codex на Windows или $CODEX_HOME в других системах. Файл с именем economy.config.toml выбирается с помощью codex --profile economy.[8][10]

Вот профиль, который я рекомендую для небольших правок, преобразований, сводок, простых тестов и несложных действий в браузере:

# %USERPROFILE%\.codex\economy.config.toml

model = "gpt-6-luna"
model_reasoning_effort = "low"
model_verbosity = "low"
service_tier = "default"

[agents]
enabled = false

[features]
fast_mode = false

Запустите его в PowerShell:

codex --profile economy

Затем проверьте активные настройки:

/status

Команда /status показывает текущую модель, использование контекста, информацию о лимитах и другие детали сессии.[6]

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

model_verbosity = "low" — это в первую очередь управление стилем вывода. Я использую его, потому что обычно хочу получить краткий отчёт по завершении работы. Но не стал бы обещать, что одна эта строка даёт предсказуемую экономию лимита: OpenAI не публикует фиксированную формулу пересчёта токенов в проценты подписки.[2][9]

Мой сбалансированный профиль

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

# %USERPROFILE%\.codex\balanced.config.toml

model = "gpt-6.1-sol"
model_reasoning_effort = "low"
model_verbosity = "low"
service_tier = "default"

[agents]
enabled = true
max_concurrent_threads_per_session = 2
default_subagent_model = "gpt-6-luna"
default_subagent_reasoning_effort = "medium"

[features]
fast_mode = false

Запустите его так:

codex --profile balanced

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

Вспомогательные агенты полезны, но они разделяют работу модели и инструментов. OpenAI предупреждает, что многоагентные сценарии расходуют больше токенов, чем сопоставимая работа одного агента.[11] В сообществе также описывают случайное разрастание, повторную проверку файлов и дублирование работы агентами.[15][19]

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

Ускорить одну сложную задачу вместо смены глобального дефолта

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

codex --profile balanced `
  --model gpt-6.1-sol `
  --config 'model_reasoning_effort="high"' `
  --config 'model_verbosity="medium"' `
  --config 'agents.max_concurrent_threads_per_session=2' `
  --config 'service_tier="default"' `
  --config 'features.fast_mode=false'

Для неинтерактивной задачи:

codex exec --profile balanced `
  --model gpt-6.1-sol `
  --config 'model_reasoning_effort="high"' `
  --config 'agents.max_concurrent_threads_per_session=2' `
  --config 'service_tier="default"' `
  --config 'features.fast_mode=false' `
  "Fix the failing payment reconciliation test. Change only the relevant service and tests. Run the focused test suite and report the root cause."

Codex даёт флагам командной строки и --config более высокий приоритет, чем настройкам профиля и пользователя.[8][10]

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

Audit the whole repository, fix anything wrong, improve the architecture,
and run all tests.

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

Одна задача — один тред

Самый распространённый совет от сообщества, который я нашёл, оказался и самым нетехническим: перестаньте использовать одну беседу с Codex как постоянный рабочий кабинет.

Длинный тред кажется эффективным, потому что агент всё помнит. Проблема в том, что он может раз за разом тащить в последующие вызовы старые разговоры, содержимое файлов, результаты работы инструментов и инструкции. Один пользователь, проанализировавший сотни запусков Codex, сообщил, что активный входной контекст вырос примерно с 16,700 до 158,300 токенов всего за одиннадцать минут после повторных проверок и больших объёмов вывода.[14] Это телеметрия одного пользователя, а не официальная формула расчёта, но закономерность легко узнать.

Теперь я отношусь к треду как к рабочей задаче:

1. Исследовать одну проблему.
2. Написать или реализовать результат.
3. Выполнить нужную проверку.
4. Сохранить важное состояние в репозитории или в коротком файле для передачи.
5. Закрыть тред, когда задача выполнена.

Если следующая задача не связана с текущей, я начинаю новую сессию. Если она продолжает ту же цель, но чат уже раздут, я использую /compact. Если хочу попробовать другой подход, не теряя текущий путь, я делаю форк сессии.[6][7]

Универсального правила для компактизации нет. Некоторые опытные пользователи говорят, что автоматическая компактизация хорошо работает на длинных проектах. Другие — что она удалила детали, которые им всё ещё были нужны, и привела к повторной работе.[18] Я компактизую на границах этапов, а не посреди хрупкого браузерного сценария или отладки.

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

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

Логи могут незаметно стать самой большой частью сессии разработки.

Когда команда выводит 20,000 строк, Codex может получить этот вывод, порассуждать о нём, а затем перенести его версию в следующие ходы. То же самое происходит с минифицированным JSON, списками файлов по всему репозиторию, скриншотами, деревьями доступности браузера и полными наборами тестов.

Я стараюсь фильтровать вывод до того, как Codex его увидит:

# Instead of dumping every test result, run the focused test.
npm test -- payment-reconciliation

# Search for the error instead of opening the entire log.
Select-String -Path .\logs\app.log -Pattern "reconciliation failed" -Context 3,8

# Ask Git for the files that changed instead of rereading the repository.
git diff --name-only

Конкретная команда зависит от проекта. Принцип — нет: машины хорошо фильтруют. Модель должна получать ту часть, где нужно суждение.

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

Держите AGENTS.md полезным, а не энциклопедическим

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

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

OpenAI рекомендует сокращать лишний контекст в AGENTS.md, ограничивать исходные файлы и диапазоны дат, делать промпты точнее и отключать серверы MCP, которые не нужны для задачи.[1] Разработчики, обсуждающие инженерию контекста, говорят то же самое: огромные универсальные файлы инструкций могут похоронить те немногие правила, которые действительно важны.[17][20]

Мой AGENTS.md обычно содержит:

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

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

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

Задайте Codex условие остановки

Автономный промпт для написания кода должен говорить агенту, когда остановиться.

Сейчас я включаю в него пять пунктов:

Goal: Fix the duplicate invoice bug.
Scope: Billing service and its tests only.
Constraints: Do not change the database schema or public API.
Verification: Run the focused billing tests and show the result.
Stop: Finish after the test passes and summarize changed files.

Это не магия промптов. Так я сокращаю исследование, о котором не просил.

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

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

Следите за расходом, пока он не стал неприятной неожиданностью

Раньше я смотрел на расход, только когда Codex меня останавливал. Теперь проверяю в начале крупной задачи и ещё раз после затратного этапа.

Внутри CLI:

/status

В текущих релизах Codex также могут быть доступны представления расхода по учётной записи — например, дневной или недельный расход — в зависимости от клиента и этапа развёртывания. Панель использования ChatGPT остаётся источником истины на уровне учётной записи.[2][6]

Ещё я проверяю установленную версию:

codex --version
codex update

Когда я писал эту статью 5 октября 2026 года, мой отдельный Windows-клиент показывал версию 0.156.1, а в списке изменений OpenAI последним релизом значилась 0.160.0. В документации OpenAI также сказано, что для GPT-6 Astra нужен Codex CLI 0.153.0 или новее.[3][12][13]

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

Настройки, которые я не стал бы копировать из случайных постов

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

У Codex есть ключи конфигурации для метаданных модели и поведения компактизации, но я оставляю их незаданными. Ручное значение model_context_window не увеличивает реальное контекстное окно модели. Неверное значение заставит Codex учитывать контекст или запускать компактизацию не вовремя. Агрессивное model_auto_compact_token_limit либо сохраняет слишком много истории, либо компактизирует так часто, что агент снова и снова переоткрывает детали.[9]

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

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

Что делать, когда лимит уже исчерпан

Нет такой строки конфигурации, которая законно сбрасывала бы лимит ChatGPT.

OpenAI говорит, что поддержка не сбрасывает лимиты Codex вручную.[2] Остаются варианты: дождаться сброса соответствующего окна, купить кредиты, если учётная запись имеет право на покупку, перейти на тариф с большей ёмкостью или использовать отдельно оплачиваемый доступ к API.[1][3]

Я бы не назвал переход на API способом сэкономить. Это способ не прерывать работу. Работа продолжается, но расходы переходят с абонентского лимита на оплату API по факту использования.

Апгрейд тарифа добавит мощности, но не спасёт от рабочего процесса, который запускает слишком много агентов, тащит за собой гигантские логи, по умолчанию работает в режиме Fast или отдаёт каждую мелкую задачу самой дорогой модели.

Рабочий процесс, которым я пользуюсь сейчас

Мой подход скучный — наверное, поэтому он и работает.

Перед началом:

1. Для рутины выбираю economy, для обычной разработки — balanced.
2. Запускаю /status и проверяю модель, уровень рассуждений, скоростной режим и остаток лимита.
3. Ставлю перед Codex одну цель, разумный объём, проверку и условие остановки.

Во время работы над задачей:

1. Фильтрую логи и результаты поиска, прежде чем отдавать их модели.
2. Разрешаю не больше двух потоков субагентов, если только задача явно не выигрывает от большего.
3. Повышаю уровень рассуждений только для того этапа, который действительно сложен.
4. После завершённого этапа делаю компактизацию, если цель не изменилась.

После задачи:

1. Сохраняю долгоживущие решения в коде, тестах, документации или в коротком файле-хендоффе.
2. Для следующей несвязанной задачи открываю новый поток.
3. Проверяю /status ещё раз после особенно долгой работы в браузере, исследований или работы с несколькими агентами.

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

Мой вывод

Не думаю, что лучший способ обойти лимиты Codex — трястись над каждым токеном.

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

Для повторяющихся задач берите Luna. Держите режим Fast выключенным, если только ожидание не имеет значения. Пусть Sol занимается обычной разработкой. Поднимайте уровень рассуждений на сложном этапе, а потом снова опускайте. Ограничивайте число агентов. Держите в одном потоке одну задачу. Фильтруйте большой вывод инструментов. Пишите короткие инструкции. Проверяйте /status до того, как долгий запуск застанет вас врасплох.

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

Ссылки

[1] https://developers.openai.com/codex/pricing — цены и лимиты использования OpenAI Codex
[2] https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan — использование Codex с тарифом ChatGPT
[3] https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex — ChatGPT Work и Codex
[4] https://developers.openai.com/codex/agent-configuration/speed — режим Fast в Codex
[5] https://developers.openai.com/codex/models — модели Codex
[6] https://developers.openai.com/codex/developer-commands?surface=cli — Codex CLI и слэш-команды
[7] https://developers.openai.com/blog/mastering-codex-remote-for-engineering — освоение удалённого режима Codex для инженеров
[8] https://developers.openai.com/codex/config-file/config-basic — основы настройки Codex
[9] https://developers.openai.com/codex/config-file/config-reference — справочник по настройке Codex
[10] https://developers.openai.com/codex/config-file/config-advanced — продвинутая настройка Codex
[11] https://developers.openai.com/codex/agent-configuration/subagents — субагенты Codex
[12] https://developers.openai.com/codex/changelog — список изменений Codex
[13] https://developers.openai.com/codex/reference/troubleshooting — устранение неполадок Codex
[14] https://github.com/openai/codex/issues/44305 — issue Codex 44305: телеметрия роста контекста
[15] https://github.com/openai/codex/issues/33196 — issue Codex 33196: отчёт об использовании нескольких агентов
[17] https://news.ycombinator.com/item?id=47970795 — Ask HN: стратегии использования ИИ-агента для разработки
[18] https://news.ycombinator.com/item?id=49807573 — Hacker News: обсуждение компактизации в Codex
[19] https://www.reddit.com/r/OpenaiCodex/comments/1wlcns2/usage_limits_are_insane — Reddit: отчёты о лимитах использования Codex
[20] https://www.faros.ai/blog/context-engineering-for-developers — Faros: инженерия контекста для разработчиков

Впервые опубликовано на https://blog.jenuel.dev/blog/how-i-stopped-burning-through-my-codex-usage-limit