Codex токены — единицы входного и выходного контекста задачи, которые нужно учитывать отдельно от кредитов и лимитов подписки. В рабочем журнале фиксируют выбранную модель, объём входа, кэшированную часть и выход, а доступный остаток подписки сверяют через /status в CLI и Dashboard. Если Codex запущен с API-ключом, его расход относится к отдельному API-учёту, поэтому остаток подписки виден только в её собственном учёте.
Что именно считать
У Codex есть разные единицы учёта: токены описывают обработанный контекст, кредиты относятся к подходящим планам оплаты, а включённые лимиты задают доступный объём использования. При входе по API-ключу действует отдельная тарификация API.
Токен — часть содержимого, которую модель получает или выдаёт при работе. Согласно официальной документации OpenAI, в расход контекста входят запрос, файлы, история диалога, результаты инструментов и ответ. Поэтому короткая команда в CLI может сопровождаться большим входом: вместе с ней поступают фрагменты репозитория и прежние сообщения. Для руководителя проекта полезнее видеть состав входа, чем длину фразы пользователя.
| Показатель | Что описывает | Где проверять |
|---|---|---|
| Входные токены | Запрос и дополнительный контекст | Журнал задачи и доступные данные запуска |
| Кэшированный вход | Повторно использованная часть входа | Данные учёта, когда инструмент их показывает |
| Выходные токены | Ответ модели и результаты генерации | Данные конкретного запуска |
| Остаток лимита | Доступность использования по плану | /status в Codex CLI и Dashboard |
Кэшированный вход остаётся входом по смыслу, хотя условия его тарификации могут отличаться. Его нельзя автоматически вычитать из общего объёма задачи. Если интерфейс показывает лишь общий расход, записывайте именно эту величину и помечайте детализацию как отсутствующую. Кредиты тоже нельзя выдавать за токены: это единица оплаты для подходящих кредитных планов. Включённый лимит подписки связан с доступностью продукта по плану; единой формулы перевода любого числа токенов в остаток лимита нет. Для команды важна точная подпись каждого столбца журнала, иначе график смешает технический расход и финансовый учёт.
Где расход растёт
На расход влияет сложность поручения и объём переданного контекста. Codex получает текущий запрос, открытые файлы, историю и результаты вызванных инструментов. Если задача охватывает весь репозиторий, модель обрабатывает больше материала, чем при работе с конкретным модулем. Широкий запрос может вызвать чтение дополнительных файлов и увеличить вход без видимой пользы для результата. Отдельно записывайте, какие материалы действительно требовались для ответа, а какие попали в контекст по инерции.
- Формулируйте рабочую цель и критерий готовности так, чтобы исполнитель открыл относящиеся к задаче файлы.
- Передавайте путь к нужному модулю и ограничения на чтение, если задача касается локальной правки.
- Сохраняйте неизменный справочный фрагмент в устойчивой форме, когда процесс допускает повторное использование контекста.
- После серии запусков сравнивайте вход и выход по одинаковым задачам; объяснение различий важнее итогового числа.
Кэширование означает повторное использование подходящей части входа по правилам конкретного режима. Доля кэша меняется вместе с формой запроса и условиями запуска; обещать постоянную экономию по одной записи нельзя. Для осмысленного сравнения фиксируйте модель и режим доступа. При переходе между подпиской и API-ключом одинаковый текст перестаёт быть одинаковой строкой учёта: данные относятся к разным механизмам оплаты. Подробнее о подключении ключа и границах этого режима — в разборе Codex API для компании.
Если полный список файлов или длинная история доступны скрипту, отдайте подсчёт парсеру. Скрипт соберёт объёмы и метки запусков, а языковая модель объяснит аномалии и предложит гипотезы. Человек сверит вывод с исходными данными и решит, какие файлы нужны следующему запуску. Такой порядок сохраняет проверяемость журнала и снижает риск убедительного, но ошибочного вывода.
Журнал рабочей задачи
Для пилота предложите команде воспроизводимую задачу из разработки: например, поправить обработку ошибки в выбранном модуле и принять изменение по тесту. Это проектная схема, без рассказа о проведённом эксперименте. Название задачи, версия исходных файлов и критерий приёмки должны совпадать между сравниваемыми запусками. Иначе отличие расхода легко объясняется разным объёмом работы, а вывод о настройке контекста окажется ложным.
- Создайте запись с идентификатором задачи, исполнителем, режимом доступа и выбранной моделью. Секреты, значения ключей и клиентские данные в журнал исключите.
- Зафиксируйте состав входа: собственный запрос, переданные файлы, историю и результаты инструментов. Отметьте наличие кэшированного входа, когда источник учёта показывает эту величину.
- Добавьте входные, кэшированные и выходные токены как отдельные поля. При отсутствии поля используйте пометку «нет данных», чтобы пустота выглядела как ограничение измерения.
- Сверьте результат с тестом и просмотром изменений человеком. Рядом запишите причину повторного запуска, если возникла правка постановки или ошибка в исходном контексте.
Таблицу запусков удобно держать в Google Таблицах либо в локальном файле CSV. Автоматический парсер читает полную выгрузку, нормализует названия полей и собирает сводку; модель получает уже проверенную выборку и помогает сформулировать причины разброса. Человек проверяет строки сводки на исходных записях. При наличии доступа к репозиторию серверный контур проверяет права на файлы и подтверждения опасных действий. Текст запроса к модели задаёт рабочую инструкцию.
Если команда пока путает режимы доступа, начните журнал с этого различия. Оно определяет смысл последующих полей и помогает увидеть, какие данные ещё требуется получать от инструмента.
Хотите разобрать журнал токенов вашей команды?
Лимиты и оплата
У подписки и API-ключа разные маршруты учёта. В режиме подписки текущие ограничения смотрят в Dashboard, а остаток во время работы в Codex CLI — командой /status. Кредиты на подходящих планах могут использоваться после исчерпания включённого объёма, однако их наличие и условия зависят от плана. Официальная страница OpenAI о планах и кредитах объясняет эти различия. Значение из /status полезно для решения о продолжении работы; журнал токенов показывает, из чего складывается нагрузка.
При запуске с API-ключом действует тарификация OpenAI API. В таком режиме считайте вход, кэшированный вход и выход по данным API-учёта и сверяйте их с отдельным платёжным отчётом проекта. Нельзя приписывать эти расходы включённому лимиту подписки либо оценивать платёж по одному числу токенов. На итог также влияет выбранная модель и режим обработки. Актуальные условия проверяйте в официальных кабинетах.
Если журнал показывает расход, а /status даёт неожиданную картину, сначала проверьте способ входа в Codex, выбранный рабочий контур и дату данных. Затем разделите строки подписки и API-ключа. Для вопросов о квоте сообщений и распределении доступа в команде используйте отдельный разбор лимитов Codex; здесь главным остаётся состав токенов и связь каждого запуска со своим режимом учёта.
Технический расход описывает нагрузку, а цену задания показывает платёжный отчёт. Отчёт по токенам помогает понять источник нагрузки, а платёжная информация отвечает за фактическое списание. Соединяйте эти данные по идентификатору проекта и периоду, сохраняя исходные отчёты для проверки. Если для строки отсутствует надёжное соответствие, оставьте её в категории «требует сверки», без придуманной оценки. Такой подход подходит командам со смешанными режимами доступа.
Как принять схему
Предложенный пилот оценивает качество учёта, без обещания заранее заданного снижения расхода. После сбора записей проверьте, можно ли по каждой строке восстановить задачу, модель, тип доступа, источник данных о токенах и результат приёмки. Затем выберите записи с большим входом и посмотрите, какие материалы передавались модели. Если часть файлов оказалась лишней, измените правила подбора контекста и повторите сопоставимую задачу. Решение о расширении схемы принимайте по полноте журнала и качеству результата.
- Сверьте суммы по полям с исходной выгрузкой скриптом, а подозрительные строки откройте вручную.
- Проверьте, что строки API-ключа имеют собственный источник расходов и отсутствуют в сводке по подписке.
- Сравните выполненную работу с критериями приёмки: готовность правки подтверждают тест и просмотр изменений человеком.
- Запишите владельца журнала и правило обновления полей при смене интерфейса или способа входа.
Если команда использует Codex для обучения разработчиков, покажите им смысл входа, выхода и кэша на учебной записи без секретов. Для руководителя сделайте отдельный вид с задачей, результатом и проверенным источником оплаты. Подробности квот оставьте статье о лимитах, а настройку доступа по API — техническому разбору ключа. Так каждый материал отвечает на свой вопрос, а журнал соединяет их в управляемый процесс.
Стоимость настройки такого процесса зависит от состава инструментов, качества доступной выгрузки, требований к доступу и числа рабочих контуров. План работ и смету можно обсудить на консультации по учёту ИИ. Принесите обезличенный образец журнала и перечень спорных строк: по ним проще определить, где требуется парсер, где нужна настройка отчёта, а где достаточно ясного правила для команды.