Кэш на 12 часов в OpenAI API: когда он снижает стоимость длинных запросов

Для агента, который обращается к API несколько раз за рабочий день, повторная передача длинных инструкций влияет на стоимость. 20 октября 2026 года OpenAI добавила в Responses API выбор 12-часового срока кэширования: общие инструкции, инструменты и контекст могут оставаться пригодными для повторного использования между запросами, разделёнными несколькими часами. OpenAI указывает ставку записи в 2,5 раза выше обычной цены входных токенов; это полная ставка записи, а не надбавка поверх неё. Экономия зависит от повторного использования префикса и цены чтения кэшированных токенов. Анонс в журнале изменений OpenAI датирован 20 октября 2026 года.

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

Что именно кэшируется

Prompt caching повторно использует совпадающий начальный фрагмент входа. Последующие запросы должны сохранять его одинаковым; меняющиеся данные стоит размещать после постоянной части. В руководстве OpenAI по кэшированию промптов указано, что для GPT‑5.6 и более поздних моделей в Responses API можно задать TTL `30m` или `12h`. Двенадцать часов — минимальный срок, в течение которого запись должна оставаться пригодной для кэшированного чтения; это не обещание удалить её ровно через 12 часов. Доступность и параметры зависят от модели.

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

Как оценить окупаемость

Пусть стабильный префикс содержит P токенов, отправляется N раз, цена обычного входного токена равна C, а ставка кэшированного чтения для выбранной модели — R. При одной записи и попадании в кэш во всех последующих запросах расходы на этот префикс составят примерно 2,5PC + (N−1)PR. Без кэша его передача стоила бы NPC. Эта оценка относится только к стабильному префиксу: отдельно учитывайте изменяющуюся часть запроса, непопадания в кэш и дополнительные записи. Ставка чтения зависит от модели; документация, например, указывает для GPT‑6.1 Sol 0,05 от обычной цены входного токена, а для GPT‑5.6 и более поздних моделей — 0,1.

В этой упрощённой модели кэш начинает экономить на повторно используемом префиксе, когда 2,5C + (N−1)R < NC. Реальная точка окупаемости зависит от фактических попаданий, повторных записей и конкретного тарифа. Если запросы редкие, инструкции часто меняются или префикс каждый раз уникален, дополнительные расходы на запись могут перекрыть экономию на чтении.

Проверка на рабочей нагрузке

1. Зафиксируйте базовый сценарий. Возьмите типичные запросы, длину стабильного префикса, интервалы между вызовами и расходы без 12-часового TTL.
2. Разделите постоянное и изменяемое. Оставьте общие инструкции и схемы инструментов в начале, а пользовательские данные и текущую задачу разместите после них.
3. Сравните сопоставимые запросы. Посчитайте записи, объём кэшированных входных токенов и общие расходы для выбранной модели и срока хранения.
4. Оцените полный рабочий цикл. Учитывайте непопадания, повторные записи после истечения срока и случаи, когда изменение префикса мешает его повторному использованию.

Метрики ответа API помогают проверить фактический объём кэшированных входных токенов и записей; состав отчётности зависит от модели. Настраиваемый 12-часовой срок подходит для стабильного большого префикса, который повторно используют с интервалами в несколько часов. Для коротких или редко повторяемых запросов сначала измерьте записи, попадания и суммарную стоимость на собственном трафике.