Записи в кэш съели 85% счёта Codex на Bedrock

В баг-трекере Codex опубликован отчёт о том, что на агентной нагрузке через нативный провайдер amazon-bedrock записи в кэш промпта дали около 85% оценочного расхода на модель openai.gpt-5.6-sol: 1 182,09 доллара из 1 386,46 за четыре дня. Отчёт размещён в трекере Codex на Github.

Коротко

• Нативные запросы Codex CLI к Bedrock Mantle Responses API не могут включить явный режим кэширования для GPT-5.6 Sol, поэтому стабильный префикс инструкций и определений инструментов оплачивается заново.
• По данным Cost Explorer и тарифной карты Bedrock автор насчитал за 5–8 августа 3 656 запросов и 171,94 млн токенов записи в кэш, из них 1 182,09 доллара пришлось на записи при общей оценке 1 386,46 доллара.
• Настроить это через config.toml нельзя: встроенный конфиг провайдера Bedrock описывает транспорт и аутентификацию, но не преобразование тела запроса, так что обходного пути на стороне пользователя нет.

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

Записи в кэш составили около 85% оценочного расхода на Sol

Отчёт составлен для Codex CLI 0.147.0 с нативным провайдером amazon-bedrock, эндпоинтом Bedrock Mantle Responses API в регионе us-east-1 и моделью openai.gpt-5.6-sol. За полные сутки с 5 по 8 августа 2026 года выборка Cost Explorer дала 3 656 запросов и 171,94 млн токенов записи в кэш.

Локальная сессия Codex зафиксировала 76 запросов к Sol с 6,709 млн токенов записи в кэш, нулевым числом прочитанных из кэша токенов и средними примерно 88 тыс. токенов записи на запрос. Клиентских ошибок в соответствующих метриках CloudWatch не было. Автор подчёркивает, что все суммы получены из данных о потреблении и тарифной карты, а не из финального счёта AWS.

В типах запросов нет полей prompt_cache_options и prompt_cache_breakpoint

Codex уже передаёт prompt_cache_key, привязанный к сессии, однако типы запросов Responses ни для HTTP, ни для WebSocket не содержат ни prompt_cache_options, ни prompt_cache_breakpoint. Без этих полей клиент не может обозначить границу стабильного префикса, на которую опирается явный режим кэширования в Bedrock.

В документации AWS явный режим кэширования для GPT-5.6 на Bedrock описан именно под агентные сценарии: длинные неизменные инструкции и определения инструментов, за которыми идут меняющиеся вызовы инструментов и пользовательский контент. Встроенная конфигурация провайдера отвечает за транспорт и аутентификацию, преобразование тела запроса в ней не предусмотрено, поэтому включить режим через config.toml невозможно.

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

Автор просит типизированное поле prompt_cache_breakpoint и телеметрию по кэшу

Отчёт формулирует четыре требования к Codex: сериализовать prompt_cache_options для Responses-провайдеров с поддержкой GPT-5.6 и добавить типизированное поле prompt_cache_breakpoint в поддерживаемые блоки входного контента. Третье требование касается проверки возможностей провайдера и модели, а также безопасной стратегии размещения точки разрыва в конце измеренного стабильного префикса инструкций и инструментов.

Четвёртый пункт касается диагностики: чтения и записи кэша должны попадать в потурновую телеметрию потребления, чтобы пользователь мог распознавать дорогие перезаписи полного префикса. Сейчас соотношение записей и чтений в интерфейсе Codex не показывается, и картина потребления восстанавливается по данным Cost Explorer и метрикам CloudWatch уже после того, как токены оплачены. Именно так собраны обе оценки в отчёте.

Что происходит в 0.148.0

В следующей версии клиента, 0.148.0, та же модель завершается ошибкой на параметре prompt_cache_retention, поэтому простое обновление проблему не снимает. Сроки поддержки явного кэширования для нативного провайдера amazon-bedrock не названы, как и приоритет задачи в трекере Codex. Оценка расходов охватывает только четыре завершившихся дня, 5–8 августа, данные за более поздние периоды в отчёте не приводятся.