Экономия лимитов Codex начинается не с самого короткого запроса. Чаще ресурсы расходуются на повторное изучение проекта, расплывчатые задачи, лишние изменения и исправление недопонимания. Цель — уменьшить число бесполезных итераций, сохранив проверки там, где ошибка действительно дорого обходится.
Лимиты подписки и расходы через API нельзя считать одним и тем же бюджетом. Условия зависят от способа доступа, модели и плана. Актуальные ограничения и время обновления смотрите в своем аккаунте; общие принципы описаны на странице тарифов и использования. Универсального числа запросов на любую задачу нет.
Сначала найдите источник лишней работы
Возьмите несколько завершенных задач и посмотрите, где повторялся один и тот же цикл. Агент каждый раз искал команду тестов? Читал всю монорепу вместо одного пакета? Переделывал интерфейс после уточнения требований? Каждая причина требует своего исправления. Смена модели не решит проблему отсутствующих критериев приемки.
Не оценивайте эффективность только по длине ответа. Короткий отчет может скрывать большой объем работы, а подробная постановка задачи иногда экономит несколько переделок. Сравнивайте одинаковые задачи: время до принятого результата, число повторных попыток, качество diff и выполненные проверки.
Дайте компактную карту проекта
Подготовьте сведения, которые действительно повторяются: назначение основных каталогов, команды запуска, тестов и сборки, ограничения доступа, расположение документации. Храните устойчивые правила в AGENTS.md, а архитектурные решения в отдельном документе.
Не превращайте файл правил в архив всех переписок. Устаревшие команды и противоречащие друг другу запреты увеличивают неопределенность. Периодически сверяйте инструкции с реальным проектом. Ссылка на актуальный тестовый сценарий полезнее десяти абзацев о том, как его когда-то запускали.
Ограничьте область поиска
Проблема в форме заявки на странице контактов.
Начни с компонента формы и его обработчика.
Связанные тесты находятся в tests/contact.
Не анализируй остальные приложения монорепозитория,
если зависимость на них не обнаружена.
Если причина выходит за эту область, объясни связь.
Нужен минимальный фикс и проверка отказа отправки.Такое ограничение не запрещает исследовать настоящую причину. Оно задает стартовую область и просит обосновать расширение. Слишком жесткий запрет читать зависимости может, наоборот, привести к поверхностному исправлению. Экономия должна уменьшать шум, а не лишать агента необходимых фактов.
Разделяйте решение и реализацию
Если неизвестно, какой подход выбрать, сначала поручите короткое исследование с конкретным вопросом. Например: подойдет ли существующий механизм очереди для повторной отправки в CRM? После ответа зафиксируйте решение и только затем запускайте реализацию.
При этом не нужно требовать отдельного плана для каждой мелочи. Замена подписи в одном компоненте не требует архитектурного обсуждения. Отдельный этап полезен тогда, когда ошибка выбора способна привести к большой переделке: миграция, новый протокол, интеграция, изменение хранения данных.
Выбирайте сложность модели по риску
Однотипная правка текста, анализ гонки запросов и проектирование миграции — разные задачи. Более легкий доступный вариант можно проверить на ограниченной операции с простой приемкой. Сложные взаимосвязанные изменения требуют более тщательного рассуждения и проверки независимо от выбранного инструмента.
Не обещайте себе конкретный процент экономии заранее. Если легкая модель делает несколько неудачных попыток, итог может быть хуже. Полезнее небольшой набор типовых задач с одинаковыми критериями. Оцените не только стоимость запуска, но и время на проверку результата человеком.
Не запускайте все проверки по привычке
Для локальной функции сначала достаточно ее тестов и проверок затронутого пакета. Для общего API, авторизации или миграции нужен более широкий охват. Перед выпуском полный согласованный набор может оставаться обязательным. Это управление риском, а не предложение отказаться от тестирования.
Если проверка долгая, сохраняйте результат и версию кода, к которой он относится. После изменения проверенного участка старый отчет уже не доказывает корректность новой версии. В статье о приемке Codex разобрано, как отличить выполненную проверку от намерения ее выполнить.
Передавайте состояние, а не всю историю
Перед переходом к отдельной задаче сохраните краткую сводку: цель, текущая ветка, измененные файлы, принятые решения, команды проверок и открытые вопросы. Не начинайте новый диалог после каждого сообщения, но и не смешивайте бесконечно несвязанные проекты. Важнее качество передаваемого состояния, чем сам факт смены чата.
Логи прикладывайте по проблемному фрагменту, сохраняя сообщение об ошибке и необходимый контекст. Перед отправкой убирайте секреты и персональные данные. Огромная выгрузка без объяснения, где проявился дефект, заставляет заново искать полезный сигнал.
Что не стоит делать ради экономии
Не отключайте подтверждения опасных действий, не пропускайте резервные копии и не заменяйте тесты словами «проверь мысленно». Экономия нескольких итераций не оправдывает повреждение базы. Также не существует надежной фразы, которая заставляет модель всегда выполнять ту же работу с заранее заданным меньшим расходом.
Следующий практический шаг — разделить простые и сложные задачи между инструментами. А крупные доработки лучше заранее разбить на проверяемые этапы. Для бизнеса это дает не только более управляемые расходы, но и понятную приемку результата.
