Назад в блог
2 апреля 2026 г.Sergei Solod3 мин чтения

Почему я оставляю последние 3–5% Codex Plus для самых больших инженерных задач

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

Codex PlusAI-инструменты для кодаWorkflow разработчикаРазработка ПОМиграция на TypeScriptЧистка ESLintРефакторингПродуктивность

Одна из самых интересных закономерностей, которые я заметил в работе с Codex Plus, связана не столько с формулировкой промптов, сколько с таймингом.

Когда у меня остаются последние 3–5% от 5-часового или недельного лимита, я больше не трачу этот остаток на маленькие запросы. Я делаю ровно наоборот. Я использую этот кусок лимита, чтобы запускать самые большие инженерные задачи на нескольких заранее подготовленных проектах.

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

Что изменило мой workflow

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

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

Как я теперь использую этот остаток

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

  • полная миграция на TypeScript
  • чистка ESLint по всему репозиторию
  • глубокое ревью багов в больших кодовых базах
  • крупные структурные рефакторинги

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

Почему это кажется мне важным

Инструменты вроде Codex Plus — это не только про голую мощность. Очень многое зависит и от того, как именно ты распределяешь усилие по времени. Небольшой сдвиг в тайминге может заметно изменить практическую отдачу от одного и того же лимита.

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

Иногда, если честно, возникает ощущение, что Codex продолжает работать на меня даже после того, как видимый лимит уже исчез. Я не знаю, является ли это каким-то специально заложенным пограничным сценарием или просто особенностью того, как некоторые задачи завершаются на практике. Но это оказалось достаточно полезным, чтобы я начал строить свой workflow вокруг этого наблюдения.

Практический вывод для разработчиков

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

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