Update — лето 2026: у меня это перестало работать
К лету 2026 года этот приём перестал для меня надёжно работать. В моём аккаунте исчез 5-часовой счётчик использования, а видимым остался недельный лимит. На практике это убрало короткое окно сброса, вокруг которого я раньше строил этот workflow.
Но важнее оказалось другое. Если длинная задача Codex упиралась в конец моего недельного лимита, я уже видел не продолжение работы до завершения, а остановку. Из-за этого старое правило «на последних 3–5% запускай самую тяжёлую задачу» почти потеряло смысл: рассчитывать, что уже запущенная работа переживёт окончание недельного лимита, я больше не мог.
Здесь важно не выдать мой опыт за универсальное правило продукта. Я могу подтвердить только то, что видел в своём аккаунте и своём workflow; я не могу доказать, что OpenAI навсегда убрал 5-часовое окно у всех пользователей. Более того, текущая документация OpenAI по Codex по-прежнему упоминает и 5-часовое, и недельное окна, а также говорит, что активный turn в некоторых случаях может продолжиться после достижения лимита с учётом fair-use ограничений. Поэтому изменение летом 2026 года я описываю как реальное поведение, которое увидел у себя, а не как документированное глобальное правило для всех аккаунтов.
Остальная часть статьи сохранена как описание workflow, который действительно работал у меня до этого изменения. Update выше важнее старых формулировок в настоящем времени.
Когда счётчик использования Codex в моём ChatGPT Plus падает примерно до 3–5%, я больше не трачу остаток на мелкие промпты. Я делаю наоборот: запускаю самую большую инженерную задачу из тех, что уже подготовил.
В моём случае это обычно полная миграция на TypeScript, чистка ESLint по всему репозиторию, глубокое ревью багов большой кодовой базы или крупный структурный рефакторинг. Я часто заранее подготавливаю несколько проектов, чтобы последние проценты можно было отдать самой тяжёлой задаче, которая действительно готова к запуску.
Причина — повторявшееся наблюдение. Не один раз я запускал большую работу почти у самого конца видимого лимита, а затем видел, что Codex продолжает работать даже после того, как лимит выглядел исчерпанным. Иногда задача успевала продвинуться до полного завершения. Это повторялось достаточно часто, чтобы изменить мой способ планировать работу, но недостаточно, чтобы превращать наблюдение в гарантированное правило продукта.
Наблюдение, которое изменило мой workflow
Естественная реакция рядом с лимитом — начать экономить: потратить остаток на мелкие запросы, потому что большая задача может оборваться. Я теперь смотрю на последние 3–5% наоборот. Для меня это окно запуска.
Полезный вопрос больше не «сколько ещё мелких промптов я успею отправить?». Он звучит так: «Какую самую ценную заранее подготовленную задачу я могу запустить, пока у меня ещё остаётся включённое в план использование?»
Это работает только потому, что проект уже готов, а сама задача чётко сформулирована. Я не трачу последние проценты на выяснение того, что вообще нужно сделать. Я трачу их на начало исполнения.
Важное уточнение про название и лимиты
Изначально я называл это «Codex Plus», но это разговорное сокращение, а не официальное название продукта. OpenAI описывает Codex как возможность, включённую в ChatGPT Plus. Это стоит исправить, чтобы не создавать впечатление, будто существует отдельный тариф или продукт Codex Plus.
В текущей документации OpenAI по использованию Codex также сказано, что расход зависит от размера и сложности работы, выбранной модели и того, где выполняется задача. Документированы окна использования, включая 5-часовое и недельное. Поэтому под «3–5%» я имею в виду именно оставшийся процент, который показывает интерфейс usage. Это не 3–5% реального времени, не 3–5% токенов и не гарантированный объём инженерной работы.
Подходящие пользователи Plus сейчас могут продолжать использование Codex за счёт кредитов после исчерпания включённого лимита. Это не отменяет мой workflow, а только точнее задаёт его границы. Я рассказываю, как распределяю включённое в подписку использование, а не как обойти квоту.
Что я запускаю на последних 3–5%
На этот момент я обычно оставляю широкие инженерные операции:
- полные миграции на TypeScript
- чистку ESLint по всему репозиторию
- глубокие ревью багов больших кодовых баз
- крупные структурные рефакторинги
Я предпочитаю запустить одну такую работу как большой цельный блок, а не разрезать остаток на цепочку малополезных мелких запросов. В подобных задачах подготовленный репозиторий и ясная цель важнее, чем особенно хитрая формулировка промпта.
Несколько заранее готовых проектов полезны по той же причине. Если в одном репозитории ещё нужны решения или подготовка, я не трачу на это финальное окно, а могу запустить задачу в другом проекте, который уже готов.
Главное ограничение — подготовка
Суть не в том, чтобы «дождаться 3% и вставить огромный промпт». Если задача размыта, ограниченный бюджет легко уйдёт на исследование, уточнения или работу не в ту сторону. Мой подход имеет смысл только тогда, когда проект готов к исполнению, а задача хорошо ограничена.
Для похожего workflow полезно заранее зафиксировать scope: что должно измениться, что не должно измениться, какие есть ограничения, как будет проверяться результат и какой итог ожидается от агента. Это обычные инженерные меры предосторожности, а не доказательство того, что какая-то особая форма промпта открывает дополнительное использование.
Такая подготовка ещё и упрощает продолжение, если лимит действительно оборвёт большую задачу. Частично выполненную миграцию или ревью намного проще возобновить, когда scope и критерии проверки были понятны с самого начала.
Что я могу подтвердить — и чего не могу
Из собственного опыта я могу подтвердить только узкое наблюдение: несколько раз уже запущенная задача продолжала продвигаться после того, как видимый лимит выглядел исчерпанным, а иногда завершалась полностью.
Механизм этого поведения я подтвердить не могу. Я не могу утверждать, что OpenAI даёт каждой выполняющейся задаче скрытый grace period, что последних 3–5% гарантированно хватит на любую большую работу, что поведение стабильно или что это способ обойти лимит. Документация OpenAI ничего из этого не обещает.
Именно это различие делает вывод честным. Я учитываю поведение, которое видел неоднократно, но не полагаюсь на него как на гарантию. Если задача остановится ровно на лимите, это не значит, что что-то сломалось. Стратегия всё равно сработала, если оставшееся включённое использование ушло на более важную работу, чем несколько мелких промптов.
Завершённая задача ещё не означает проверенную
Чем крупнее задача, тем важнее ещё одно различие: завершение не равно корректности. Миграция на TypeScript, которая успешно собирается, не доказывает правильное runtime-поведение. Чистый ESLint не доказывает корректность бизнес-логики. Ревью, нашедшее подозрительный паттерн, ещё не подтвердило реальный баг. Даже рефакторинг с зелёными тестами надёжен только настолько, насколько хороши покрывающие его тесты и проверки.
Этот workflow меняет момент, когда я запускаю работу. Он не снижает стандарт проверки. Большие agentic-изменения всё равно требуют контроля по уровню риска: просмотра diff, typecheck, тестов, сборки, runtime-проверок или другой специфичной для проекта валидации.
Когда этот подход подходит плохо
Не всякая большая задача хороша для конца лимита. Подход слабее, если работа ещё неясна, требует постоянных продуктовых решений, содержит разрушительные или чувствительные для production операции либо оставляет репозиторий в опасном промежуточном состоянии при остановке посередине.
В таких случаях меньшая, хорошо ограниченная задача или новое окно использования обычно будет лучшим инженерным выбором. Цель не в том, чтобы сделать последний промпт максимально эффектным. Цель — потратить редкое включённое использование на работу, которая способна безопасно дать полезный прогресс.
Моё правило сейчас
Когда включённое использование Codex в ChatGPT Plus падает примерно до 3–5%, я перестаю оптимизировать количество оставшихся промптов. Я смотрю на заранее подготовленные проекты и запускаю самую тяжёлую, чётко ограниченную инженерную задачу, которую действительно стоит делать.
Если Codex продолжает работать после того, как видимый счётчик доходит до нуля, я отношусь к этому как к полезному наблюдаемому поведению, а не как к гарантированному праву. Если он останавливается, я не удивляюсь. Я не нашёл способ обойти лимит. Я нашёл более полезный способ решать, что именно запускать до того, как я в него упрусь.