Лимиты Codex: как измерить расход и спланировать рабочие задачи
Как проверить лимиты Codex, измерить расход на одной задаче и составить рабочий план: журнал, учебный расчёт и способы убрать лишние действия.
Нужно разобрать пять интервью, подготовить бриф и ещё проверить презентацию, а Codex показывает остаток лимита. Перевести его в точное количество будущих задач нельзя: короткий запрос может запустить длинную работу с файлами и инструментами. Зато можно измерить типовую задачу и получить ориентир для планирования.
Разберём это на учебной проверке продуктового брифа. Здесь нет обещаний «подписки хватит на сто документов»: будет журнал замера, пример расчёта и способ уменьшить лишнюю работу без потери качества.
1. Уточни, какое ограничение ты видишь
Начни с аккаунта, рабочего пространства и способа входа. Включённый объём подписки, дополнительные кредиты и оплата по API — разные способы учёта. Число сообщений само по себе не определяет расход.
На 1 октября 2026 года официальная страница Pricing описывает пятичасовые оценки для Plus и Standard Business и отсутствие пятичасового лимита у Pro; также могут действовать недельные ограничения. Это изменяемые условия. Текущие окна и время восстановления проверяй в своём usage dashboard, ссылка на который есть на странице Pricing.
В активной сессии Codex CLI остаток можно посмотреть командой /status. Запиши название окна, его остаток и время сброса. Не называй недельный остаток «дневным», даже если планируешь работу только на сегодня.
| Что зафиксировать | Зачем |
|---|---|
| План и рабочее пространство | Не сравнивать разные условия доступа |
| Название окна | Разделить короткое и длительное ограничение |
| Остаток и время восстановления | Понять, что именно доступно сейчас |
| Модель и режим работы | Повторять замер в сопоставимых условиях |
| Другие активные задачи | Не приписывать весь расход одному документу |
Официальная документация указывает, что модель, контекст, рассуждения, инструменты и кеширование влияют на расход. Поэтому длина твоего сообщения — слабый ориентир. Подробные условия и доступные способы продолжения работы сверяй по ссылке выше.
2. Выбери одну типовую задачу
Для замера нужна задача с чётким концом. «Улучши весь продукт» будет разрастаться по мере работы. «Найди пять пробелов в одном брифе и сохрани таблицу» даёт сравнимый результат.
Создай учебный файл pilot-brief.txt с текстом:
Пилот: еженедельный отчёт для руководителя поддержки.
Вход: таблица обращений за неделю.
Выход: список частых тем и ссылки на исходные обращения.
Пользователи: руководители двух команд.
Длительность: две недели.
Не определены: критерий успеха, ответственный за проверку,
правила доступа к исходным обращениям.
В пилот не входят автоматические ответы клиентам.Затем дай Codex ограниченное задание:
Прочитай только pilot-brief.txt.
Создай pilot-review.md с таблицей: пробел, основание из брифа,
вопрос команде, что должно появиться в готовом решении.
Максимум пять строк. Не выдумывай ответы и результаты пилота.
Не ищи информацию в интернете и не меняй исходный файл.
Заверши работу после сохранения таблицы и короткой проверки её полноты.Проверь файл результата сам. Он должен различать отсутствующее решение и уже известный факт. «Автоответы клиентам» нельзя вернуть в объём пилота только потому, что это кажется помощнику полезным.
3. Сними показатели до и после
Перед запуском дождись завершения других своих задач, если это возможно. Запиши остаток каждого доступного окна. После завершения обнови показатели и сохрани итоговый файл. Если счётчик обновляется с задержкой, не делай вывод по первой цифре.
Учебный журнал — это иллюстрация метода, не реальные замеры Codex:
| Проба | Остаток одного и того же окна до | После | Разница |
|---|---|---|---|
| A | 70% | 66% | 4 процентных пункта |
| B | 66% | 61% | 5 процентных пунктов |
| C | 61% | 55% | 6 процентных пунктов |
Для собственных проб используй разные, но сопоставимые брифы. Повтор одного и того же файла в той же сессии может дать непоказательную экономию за счёт уже имеющегося контекста. Не расходуй лимит специально на десятки тестов: можно собирать журнал по мере выполнения полезных рабочих задач.
Если во время пробы окно восстановилось или параллельно работала другая сессия, пометь замер как несопоставимый. Разница счётчиков в таком случае не равна расходу выбранной задачи.
4. Рассчитай осторожный ориентир
Допустим, в учебном примере осталось 55%, а ты решил оставить 15 процентных пунктов на непредвиденную работу. Используем худшую из трёх проб — 6 пунктов на задачу:
Доступно для планирования: 55 − 15 = 40 пунктов.
Ориентир: целая часть от 40 / 6 = 6 похожих задач.Это локальная оценка по твоему журналу, а не гарантия сервиса. Она теряет смысл при смене модели, объёма документов, режима, условий плана или состава инструментов. Если действуют несколько окон, оцени каждое и ориентируйся на то, которое ограничивает работу раньше.
Не переводи этот результат в стоимость токенов через цену подписки. Процент включённого лимита не является универсальной денежной единицей. Для отдельного API-бюджета нужны его собственные данные использования и тарифы.
5. Уменьши лишние действия
Экономить полезнее на ненужной работе, чем на проверке результата. Вот изменения постановки, которые стоит сравнить на своих задачах:
| Вместо расплывчатого запроса | Укажи конкретно |
|---|---|
| «Изучи весь проект» | Какие два документа нужны для решения |
| «Сделай идеально» | Какие критерии определяют готовность |
| «Предложи много вариантов» | Сколько вариантов тебе действительно нужно |
| «Перепиши всё» | Какой раздел изменить и что сохранить |
| «Проверь ещё раз» | Какую обнаруженную ошибку проверить |
Например, после проверки брифа попроси исправить только таблицу вопросов. Повторная генерация всего документа создаёт новую работу и новые места для ошибок. Для регулярной процедуры сохрани правила в skill Codex, но не обещай себе фиксированную экономию: её нужно измерять.
6. Подготовь продолжение при достижении лимита
Если работа остановилась, сохрани текущий результат и список оставшихся действий. Ошибку лимита отделяй от ошибки доступа к файлу или внешнему сервису: для этого есть диагностика Codex.
Полезная заметка для продолжения выглядит так:
Готово: pilot-review.md, пять вопросов к пилоту.
Проверено: исходный brief не изменён, автоответы исключены.
Осталось: получить ответ команды о критерии успеха.
Следующее действие: после ответа обновить одну строку таблицы.Сначала проверь время восстановления и варианты, предложенные аккаунтом. Решение о покупке дополнительных ресурсов принимай отдельно от срочности текущей задачи. Иногда правильный следующий шаг — дождаться информации от команды, а не запускать ещё один круг генерации.
Моя рекомендация: планируй лимит по числу проверенных рабочих результатов. Сотня коротких сообщений — плохая цель, если ни один документ после них нельзя использовать.
Проверка материала: условия сверены с официальной документацией, учебная арифметика проверена. Фактический расход аккаунта не измерялся; приведённые проценты вымышлены для объяснения расчёта. Практику постановки и проверки задач разбираем на курсе по ИИ-агентам.
Собери своего ИИ-агента и проверь результат
«AI Agents: от vibe coding к AI-команде»: desktop agents, MCP, skills, evals и harness. Отдельные воркшопы — от подключения инструментов до контроля качества.
7 практических воркшопов · записи · вопросы автору в чате
Посмотреть программу курса ↗