Токены тоже деньги: практичная экономия в Codex без потери качества

В работе с Codex токены уходят незаметно. Задача движется, но каждый следующий шаг постепенно становится дороже предыдущего. Главный источник расхода обычно находится в контексте. В него входят инструкции, история диалога, содержимое файлов, описания инструментов, результаты команд, логи и рассуждения модели. Simon Willison называет работу с этим набором данных context engineering: модель должна получить ровно тот объём информации, который помогает выполнить следующий шаг. Anthropic формулирует принцип ещё строже: лучший контекст содержит минимальный набор высокосигнальных токенов, достаточный для достижения цели.

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

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

Например:

Цель: добавить повторную отправку письма с кодом авторизации.

Область: backend/auth и связанные тесты.
Сохрани текущий формат API и существующие правила ограничения запросов.

Готово, когда:
1. Пользователь может запросить новый код.
2. Предыдущий код становится недействительным.
3. Ограничение частоты покрыто тестами.

Проверка:
запусти тесты auth-модуля и линтер.
В финальном ответе укажи изменённые файлы, результаты проверок и оставшиеся риски.

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

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

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

В Responses API параметр previous_response_id удобно сохраняет состояние разговора, при этом тарификация продолжает учитывать предыдущие входные токены цепочки. Представим десять запросов, каждый из которых добавляет тысячу токенов. Уникального контекста накопится 10 тысяч токенов, а суммарная обработка растущей истории составит уже 55 тысяч.

Для длинной задачи Codex CLI поддерживает /compact. Команда сжимает текущую историю и сохраняет ключевое состояние. Codex также умеет запускать серверную компактизацию автоматически после достижения установленного порога. Текущий расход, заполнение контекста и выбранную модель можно посмотреть через /status, общую активность аккаунта через /usage.

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

Для смены треда удобно попросить Codex подготовить checkpoint:

Подготовь краткий handoff для нового треда.

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

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

Такой handoff можно сохранить в docs/codex-handoff.md или вставить первым сообщением нового диалога. Для обычного длинного разговора с ChatGPT действует тот же принцип: новое обсуждение начинается с компактного состояния проекта, а полная переписка остаётся архивом.

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

Хороший AGENTS.md содержит структуру репозитория, команды сборки и тестирования, соглашения по коду, ограничения и определение готовой работы. История компании, длинное описание продукта и коллекция всех редких исключений занимают контекст на каждом запуске. Такие материалы лучше подключать по необходимости.

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

Следующий источник расхода связан с чтением файлов. Запрос «проанализируй весь проект» открывает Codex слишком широкое поле. Запрос «найди реализацию расчёта скидки, её вызовы и связанные тесты» задаёт конкретный маршрут.

Полезная формулировка выглядит так:

Работай в src/checkout и связанных тестах.

Сначала найди существующие реализации через rg.
Прочитай найденные участки и их прямые зависимости.
Исключи vendor, build, coverage, сгенерированные файлы и большие фикстуры.
Перед изменением перечисли выбранные файлы и кратко объясни их роль.

Официальный системный промт Codex рекомендует заранее определить нужные ресурсы, читать связанные файлы пакетами и использовать точечный поиск. Это сокращает число последовательных проходов, повторное чтение и поток промежуточных сообщений.

Большие логи лучше оставлять в файловой системе. Агенту обычно нужны первая содержательная ошибка, стек вызовов, несколько строк окружения и итог выполнения. Передача полного вывода тестов на 30 тысяч строк добавляет его в историю и заставляет модель снова обрабатывать при каждом следующем шаге.

Практичный запрос:

Запиши полный вывод тестов в /tmp/auth-tests.log.
В контекст верни:
- первую первичную ошибку;
- связанный stack trace;
- список упавших тестов;
- последние 50 строк;
- путь к полному логу.

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

В Codex CLI лимит можно зафиксировать вместе с базовой глубиной рассуждений и объёмом финального ответа:

model_reasoning_effort = "medium"
model_verbosity = "low"
tool_output_token_limit = 10000

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

Уровень рассуждений стоит выбирать по типу работы. low подходит для переименований, обновления конфигурации, форматирования и простых тестов. medium покрывает обычную разработку, исправление багов и локальные рефакторинги. high и xhigh полезны при архитектурных изменениях, гонках данных, сложных миграциях, нестабильных тестах и поиске причин редких ошибок.

OpenAI рекомендует начинать с текущего уровня рассуждений, затем проверять на реальных задачах уровень на одну ступень ниже. Более высокий режим оправдан измеримым приростом качества. В Codex CLI временное переключение доступно через /reasoning, поэтому тяжёлый режим можно включать только на сложном этапе.

Объём финального ответа тоже влияет на расход. После внесения изменений Codex часто повторяет фрагменты кода, которые уже лежат в репозитории. Для работы через CLI достаточно попросить указать результат, пути файлов, выполненные тесты и риски.

Например:

Внеси изменения полностью.

Финальный ответ:
- результат;
- изменённые файлы;
- выполненные проверки;
- существенные риски.

Ссылайся на пути и функции.
Полные файлы и большие фрагменты кода в ответе опусти.

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

В API для управления объёмом доступны text.verbosity и max_output_tokens. Первый параметр регулирует подробность ответа. Второй задаёт верхнюю границу для видимого текста вместе с reasoning-токенами. Слишком жёсткий лимит может завершить ответ ещё до появления полезного текста, поэтому его лучше выбирать по статистике реальных запросов, например по 95-му процентилю успешных выполнений.

Для повторяющихся API-запросов большой эффект даёт prompt caching. Кеш работает по точному совпадению начала запроса. Постоянные инструкции, схемы инструментов и стабильные примеры размещаются в начале. Текущая задача, пользовательские данные, diff, логи и даты отправляются в конце.

Структура получается такой:

[постоянные developer-инструкции]
[стабильные правила проекта]
[схемы инструментов]
[канонические примеры]
[prompt cache breakpoint]

[текущая задача]
[актуальный diff]
[результаты текущего запуска]

Для семейства GPT-5.6 OpenAI поддерживает явные точки кеширования. Они позволяют кешировать стабильный префикс, даже когда окончание запроса меняется. Запись такого кеша тарифицируется дороже обычного входа, поэтому выгода появляется при повторном использовании. В статистике следует сравнивать cached_tokens и cache_write_tokens, а не просто факт включённого кеша.

Компактизация решает другую задачу. Кеш удешевляет повторную обработку одинакового контекста. Компактизация уменьшает сам контекст. Для длинных диалогов через API OpenAI предоставляет /responses/compact, который возвращает сокращённое состояние для продолжения разговора.

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

В GPT-5.6 параметр reasoning.context помогает выбирать глубину преемственности. all_turns подходит для одной продолжающейся задачи со стабильными целями и допущениями. current_turn подходит после смены задачи, когда прежние рассуждения утратили ценность. OpenAI также рекомендует продолжать связанные запросы через previous_response_id, сохраняя reasoning items, которые помогают модели избежать повторного анализа.

Отдельного внимания требуют MCP-серверы и инструменты. Каждое описание функции, её параметры и результаты занимают место в контексте. Большой набор похожих инструментов увеличивает стоимость и усложняет выбор действия. Anthropic рекомендует оставлять минимальный рабочий набор инструментов с чётко разделёнными назначениями. Chip Huyen предлагает проводить ablation-тесты: временно убирать инструмент и измерять изменение качества. Инструмент, отсутствие которого никак не влияет на результат, создаёт лишнюю сложность.

Для задачи с backend обычно достаточно shell, поиска, редактирования, Git и тестовой команды. Интеграции с Figma, CRM, почтой и десятками внешних сервисов можно подключать отдельными профилями. В Responses API для больших наборов функций доступен tool search, который подгружает редкие инструменты только при необходимости.

Параллельные агенты сокращают календарное время, но каждый из них получает собственный контекст и создаёт собственную историю. Режимы multi-agent и Ultra подходят для независимых направлений: один агент изучает backend, второй проверяет frontend, третий готовит тесты. Запуск нескольких агентов на одну маленькую функцию быстро превращает один анализ в три похожих анализа. Chip Huyen отдельно обращает внимание на стоимость промежуточных рассуждений, наблюдений и рефлексии в многошаговых агентах.

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

Для проверки настроек достаточно собрать 20-30 типовых задач из своего репозитория и сравнить несколько режимов:

medium против low reasoning;
полный набор инструментов против профильного;
сырая история против compact;
полные логи против выбранных фрагментов;
длинный AGENTS.md против короткого файла со ссылками.

Для каждого запуска стоит сохранять входные токены, кешированные токены, запись кеша, выходные токены, число вызовов инструментов, успешность тестов и замечания ревью. OpenAI предоставляет отдельный endpoint подсчёта входных токенов до запуска, а Responses API возвращает статистику фактического использования. LangChain и Chip Huyen также рекомендуют связывать оптимизацию контекста с наблюдаемостью и проверкой качества, поскольку одна и та же техника даёт разный эффект на разных задачах.

В результате рабочая схема выглядит достаточно просто. Одна задача получает отдельный тред. Постоянные правила живут в коротком AGENTS.md. Codex получает цель, границы и критерии готовности. Файлы читаются через поиск и по конкретным путям. Логи остаются на диске. Обычные задачи выполняются на medium, рутинные на low, тяжёлые временно переводятся на high. После завершения этапа запускается compact или создаётся checkpoint. API кеширует стабильный префикс и отдельно хранит структурированное состояние проекта.

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

Вопросы по материалу

О чем этот материал?

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

Кто автор материала?

Материал подготовил Игорь Колосов. Автор материалов о продуктивности, IT, управлении, нейросетях и инструментах для работы и жизни.

Когда материал опубликован или обновлен?

Дата публикации: 30.07.2026. Последнее обновление: 30.07.2026.