Кэширование промптов OpenAI на 12 часов: когда выгодна запись по 2.5×
Рассчитайте, когда кэширование на 12 часов выгодно для неизменного префикса, настройте 12h и 30m в одном запросе Responses API и восстановите стоимость входных токенов по usage. Разберите отличие API от кэширования в Codex, Work и Anthropic.
Содержание
Включайте кэширование промптов OpenAI на 12 часов для префикса — неизменного начала запроса, к которому агент возвращается после долгих пауз; меняющийся контекст сессии оставьте на 30m или за пределами области записи в кэш. Если при 30m каждый вызов требовал бы новой записи, одна запись с 12h становится выгоднее на третьем запросе — при втором повторном использовании, пока префикс остаётся прежним. Если же 30m и так даёт попадания в кэш, увеличение срока добавит расходы на запись, не снизив цену чтения.
Сколько стоят запись и чтение при 30m и 12h?
Запись с 12h стоит вдвое дороже стандартной записи с 30m, а цена последующих чтений одинакова для обоих сроков. OpenAI объявила эту возможность для Responses в журнале изменений API от 20 октября 2026 года; по состоянию на 2026-10-24 руководство по кэшированию промптов устанавливает следующие правила для GPT-5.6 и более новых моделей.
| Категория входных токенов | Множитель к обычному тарифу ввода | GPT-6.1 Sol, USD за 1M токенов |
|---|---|---|
| Обычный ввод | 1× | $2.00 |
Запись с 30m, по умолчанию | 1.25× | $2.50 |
Запись с 12h | 2.5× | $5.00 |
| Чтение из кэша при любом из двух сроков | 0.1× для большинства моделей; 0.05× для GPT-6.1 Sol | $0.10 |
Это полная стоимость записи. Токен, учтённый как запись с 12h, оплачивается по ставке 2.5× от обычного ввода; обычная стоимость ввода поверх неё не начисляется.
В столбце с долларами приведены действующие цены OpenAI Standard для gpt-6.1-sol: запрос содержит не более 272K входных токенов, надбавка за обработку в выбранном регионе не применяется. Выходные токены стоят $10.00 за 1M токенов. При более длинном входе, другом уровне обслуживания или региональной обработке ставки могут отличаться — перед расчётом проверьте условия тарификации модели.
Повторно используемый префикс должен содержать не менее 1,024 видимых входных токенов. Большой общий размер запроса не делает короткое неизменное начало пригодным для кэширования.
Когда окупается более дорогая запись?
Считайте, сколько записей удаётся избежать благодаря увеличенному сроку. Обозначим через B обычную стоимость ввода неизменного префикса, через n — общее число запросов, через r — множитель тарифа чтения, а через k — число записей с 30m, включая первую.
Предположим, что каждое чтение или запись охватывает весь этот префикс, а при 12h после одной записи все повторные обращения попадают в кэш:
12h cost = B × [2.5 + (n - 1) × r]30m cost = B × [1.25 × k + (n - k) × r]No-cache cost = B × n
И при r = 0.1, и при r = 0.05 кэш на 12 часов становится дешевле обычного ввода без кэширования при n = 3. По сравнению с кэшем по умолчанию он выгоднее при k >= 3, если для 12h всё ещё достаточно одной записи. То есть нужно избежать двух последующих записей с коротким сроком; само по себе большое число попаданий в кэш этого не обеспечивает.
Если обе политики требуют одну запись, а затем каждый запрос попадает в кэш, вариант 12h остаётся дороже на 1.25 × B. Поэтому для частых сообщений в активном диалоге обычно нет смысла оплачивать более долгий срок, если в работе не возникают паузы, после которых приходится записывать префикс заново.
Пауза дольше 30 минут создаёт возможность сэкономить, но не доказывает, что следующий запрос даст промах кэша. OpenAI может сохранять записи дольше минимального срока, а чтение с 30m продлевает действие кэша как минимум ещё на 30 минут. Прогнозируя расходы работающего приложения, опирайтесь на фактическое число записей.
Рассмотрим расчётный пример: префикс из 10,000 токенов, модель GPT-6.1 Sol и тариф Standard. В этом случае B = $0.02, а r = 0.05. Отправим 12 запросов в моменты от 0 до 11 часов с интервалом в час, не меняя префикс.
| Предполагаемое поведение кэша | Стоимость ввода префикса за 12 запросов |
|---|---|
| Без кэширования: 12 запросов по обычному тарифу ввода | $0.240 |
30m: все 12 запросов требуют записи | $0.300 |
12h: одна запись и 11 чтений | $0.061 |
30m: одна запись и 11 чтений | $0.036 |
Два варианта для 30m показывают, почему одного интервала между запросами недостаточно для вывода об экономии. Запись при каждом обращении — допущение расчёта, а не неизбежный результат запросов раз в час. В суммы не входят меняющаяся часть запроса, выходные токены и платные вызовы инструментов. Это оценки, а не данные реальных счетов.
Почему 12h для всего запроса может увеличить счёт
Параметр prompt_cache_options.ttl: "12h" на уровне запроса распространяется и на автоматически выбранную границу кэширования. В режиме по умолчанию mode: "implicit" новый подходящий для записи контекст может поэтому оплачиваться по ставке 2.5× на каждом ходе диалога, даже если старый префикс уже читается по сниженной цене.
Если агент накапливает результаты вызовов инструментов и сообщения пользователя, расходы на эту растущую часть запроса могут перекрыть экономию на неизменном начале. Высокая доля попаданий в кэш сама по себе не означает, что выбранная политика выгодна.
Выберите схему под характер контекста:
- Общие материалы и контекст, повторно используемый в текущей сессии: задайте
30mпо умолчанию для запроса, а в конце общих материалов явно укажите12h. - Общие материалы и разовые вопросы: используйте
mode: "explicit"и располагайте меняющийся вопрос после последней явной границы кэширования. - Диалог, в котором новый контекст скоро понадобится снова: оставьте
mode: "implicit"с30mна уровне запроса и добавьте границу с12hдля общего префикса.
Граница кэширования охватывает весь префикс перед ней. Если готовой записи ещё нет, граница с 12h на отметке 2,000 токенов и граница с 30m на отметке 5,000 означают запись 2,000 токенов по тарифу 12h и 3,000 — по тарифу 30m. Если назначить 12h поздней границе на отметке 5,000, все 5,000 токенов будут оплачены по более дорогому тарифу. Каждый токен учитывается один раз — по самому долгому из выбранных сроков записи, которые его охватывают.
У смены срока есть ещё два важных последствия. Переход с действующего 30m на 12h оплачивается как новая запись на 12 часов, без зачёта стоимости предыдущей. Если запрос с 30m использует префикс из ещё действующего кэша с 12h, эти токены оплачиваются по тарифу чтения. Такое чтение не запускает отсчёт 12 часов заново и не влечёт новой платы за запись. Из-за этих правил пересечения границ и изменения срока политику лучше выбрать до первой записи большого префикса.
Как настроить 12h и 30m в одном запросе Responses
Задайте 30m по умолчанию и используйте явные границы, чтобы отдельно учитывать общие справочные материалы, контекст сессии и текущий вопрос. Пример ниже обращается напрямую к Responses API OpenAI и выводит текст ответа вместе со статистикой использования для проверки расходов.
Понадобятся Bash, curl, jq и API-ключ OpenAI с доступом к gpt-6.1-sol. Подготовьте в текущем каталоге:
shared-context.md: общие инструкции по разработке и справочные материалы, которые используются в течение дня; не менее 1,024 видимых входных токенов.session-context.md: материалы по текущему развёртыванию или пул-реквесту, которые пригодятся в нескольких запросах этой сессии.
Между двумя вызовами из примера не меняйте эти файлы. Когда команда read будет ждать ввода, вставьте API-ключ и нажмите Enter: символы ключа в терминале не отобразятся. Способ аутентификации соответствует краткому руководству по OpenAI API.
set -o pipefail
read -rs OPENAI_API_KEY && export OPENAI_API_KEY
cache_request() {
jq -n \
--rawfile shared ./shared-context.md \
--rawfile session ./session-context.md \
--arg question "$1" \
'{
model: "gpt-6.1-sol",
service_tier: "default",
reasoning: {effort: "low"},
prompt_cache_options: {mode: "explicit", ttl: "30m"},
input: [
{
role: "developer",
content: [{
type: "input_text",
text: $shared,
prompt_cache_breakpoint: {mode: "explicit", ttl: "12h"}
}]
},
{
role: "user",
content: [
{
type: "input_text",
text: $session,
prompt_cache_breakpoint: {mode: "explicit"}
},
{type: "input_text", text: $question}
]
}
]
}' |
curl --silent --show-error --fail-with-body \
https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
--data-binary @- |
jq '{id, status, service_tier,
text: ([.output[]? | .content[]? |
select(.type == "output_text") | .text] | join("\n")),
usage, error}'
}
cache_request "Which deployment risks need review? Answer briefly." &&
cache_request "Which test should run first? Answer briefly."В первом блоке содержимого параметр "ttl": "12h" переопределяет значение по умолчанию. У блока с контекстом сессии собственного TTL нет, поэтому он наследует "30m". Режим с явными границами оставляет последний вопрос за пределами записи в кэш: за него взимается обычная плата за входные токены.
Если префикс подходит для кэширования и ещё не был записан, первый завершённый ответ должен показать запись на 12 часов в usage.input_tokens_details.cache_write_tokens_details.ttl_12h_tokens. Во втором ответе ожидается cached_tokens > 0 без новой записи на 12 часов, если префикс совпадает и срок действия записи не истёк. Поле text содержит готовый ответ модели. Повторный вызов сразу после первого проверяет совпадение префикса и учёт токенов; экономию после долгих пауз оценивайте на интервалах, характерных для вашего приложения.
При 400 invalid_request_error проверьте точное написание значений TTL, выбранную модель и адрес Responses API. Если оба вызова показывают нулевое число прочитанных из кэша токенов, сначала проверьте длину префикса, затем сравните файлы, модель, настройки и положения границ. Любое изменение перед общей границей, в том числе изменение определений инструментов после их добавления в запрос, может помешать повторному использованию кэша.
Чтобы получить вариант для сравнения без кэширования, оставьте mode: "explicit" и удалите все prompt_cache_breakpoint. В официальной схеме запроса указано, что явный режим без меток не использует кэширование промптов.
Как восстановить стоимость входных токенов по usage
Учитывайте обычный ввод, чтение из кэша и записи с двумя сроками как отдельные, непересекающиеся категории. Общий счётчик cache_write_tokens уже включает ttl_30m_tokens и ttl_12h_tokens: если начислить плату за все три счётчика, записи будут оплачены дважды. Токены, оплаченные как переход на 12h, относятся к записям и не входят в cached_tokens.
В примере учёта OpenAI статистика выглядит так:
{
"usage": {
"input_tokens": 12000,
"input_tokens_details": {
"cached_tokens": 4000,
"cache_write_tokens": 7000,
"cache_write_tokens_details": {
"ttl_30m_tokens": 3000,
"ttl_12h_tokens": 4000
}
}
}
}Пусть I — это input_tokens, R — cached_tokens, а W30 и W12 — число записанных токенов для каждого из двух TTL. Число обычных входных токенов рассчитывается как U = I - R - W30 - W12; в этом примере оно равно 1,000.
Если обычный ввод стоит P USD за 1M токенов, а множитель тарифа чтения равен r, стоимость ввода составит:
Input cost = P × (U + r × R + 1.25 × W30 + 2.5 × W12) / 1,000,000
Для условных ставок из документации P = $1 и r = 0.1 получается:
(1000 + 4000 × 0.1 + 3000 × 1.25 + 4000 × 2.5) / 1000000 = $0.01515
Для того же использования по тарифам GPT-6.1 Sol Standard подставьте P = $2 и r = 0.05: стоимость входных токенов составит $0.02990. Выходные токены и другие применимые платежи нужно прибавить отдельно. Этот расчёт показывает только расходы на ввод, а не полную стоимость решения задачи по программированию.
Записывайте ID ответа, время, модель, фактический service_tier и перечисленные счётчики токенов. Если клиент не показывает разбивку по TTL, проверьте исходный JSON перед расчётом расходов при использовании разных TTL: отсутствие счётчика не означает отсутствие записей. Сравнивайте суммарные расходы в долларах за день с характерной нагрузкой, а не выбирайте политику по одному проценту попаданий в кэш.
Параметр 12h задаёт минимальный срок, в течение которого применима цена чтения из кэша. Он не устанавливает момент удаления данных, не меняет максимальный срок их хранения и не гарантирует меньшую задержку каждого запроса.
Чем это отличается от кэширования в Codex, Work и Anthropic?
Разделяйте тарификацию API и лимиты продуктов, в которые вы входите под своей учётной записью. В посте от 21 октября 2026 года Tibo Sottiaux заявил, что для авторизованных пользователей Codex и Work кэш сохраняется навсегда, а возврат к старым диалогам даёт попадание в кэш. Это заявление относится к сеансам в этих продуктах: оно не задаёт TTL для API и не делает подписку безлимитной.
В официальной документации по ценам Codex отдельно указано, что при расчётах в кредитах нет отдельной платы за запись в кэш, а работа с API-ключом оплачивается по тарифам API. Если вы запускаете Codex с API-ключом, рассчитывайте расходы по правилам API, не перенося на них обещания для пользователей, вошедших через учётную запись.
Для Claude по состоянию на 2026-10-24 документированы кэш на 5 минут по умолчанию с ценой записи 1.25× и вариант на 1 час с ценой записи 2×. Тариф чтения зависит от модели: для Claude Opus 5.5 и Sonnet 5.5 он составляет 0.05×; остальные ставки приведены в таблице цен Anthropic. Успешное чтение продлевает срок без повторной платы за запись, а при смешивании TTL блоки с более долгим сроком должны стоять перед блоками с коротким.
Если приложение уже использует подходящую модель OpenAI и регулярно возвращается к одному контексту после многочасовых пауз, начните со схемы 12h для неизменного префикса. Для непрерывной активной сессии сначала выбирайте короткий срок. Чтобы сравнить поставщиков по цене, нужны их базовые тарифы, расход выходных токенов и наблюдаемое поведение кэша: одни сроки хранения и множители записи не определяют стоимость завершённой задачи.
