Кэширование промптов в OpenAI и Claude: как работает, TTL, цены, почему не срабатывает и как проверить

Кэширование промптов (prompt caching) повторно использует вычисления для той части запроса, которая в точности совпадает с началом предыдущего запроса (префиксом), поэтому эта часть ввода обрабатывается дешевле и быстрее. Его предлагают и OpenAI API, и Claude API, но как его включить, сколько живёт кэш, сколько стоит запись в него и как проверить, что он работает, у них сильно различается. Если проектировать под обоих с одинаковыми допущениями, легко получить ситуацию, когда у одного вендора кэш работает, а у другого вы платите за запись в каждом запросе и ни разу не попадаете в кэш.

В этой статье кэширование промптов OpenAI и Anthropic сравнивается по оригинальному тексту страниц OpenAI «Prompt caching», «Prompt cache diagnostics» и «Pricing» и страниц Anthropic «Prompt caching», «Cache diagnostics», «Pricing» и «Rate limits». Разбираем, чем отличаются спецификации, как добиться попаданий в кэш и как убедиться, что они есть. Все цифры сверены с оригинальными страницами 3 октября 2026 года. Общую картину того, как снизить расходы на API (выбор модели, пакетная обработка, контроль вывода и т. д.), смотрите в отдельной статье «Как сократить расходы на ИИ».

1. Что такое кэширование промптов: повторное использование одинакового префикса

Каждый раз, читая ввод, языковая модель вычисляет промежуточные значения для каждого токена (тензоры KV, то есть ключи и значения). Кэширование промптов сохраняет эти значения от начала промпта до определённой точки и пропускает вычисления, когда следующий запрос начинается с точно таких же токенов. В руководстве OpenAI поясняется, что сохраняются именно значения KV, а не сами токены.

Главное: повторно использовать можно только ту часть, которая совпадает с самого начала. В двух запросах ниже повторно используются только инструкции и документы.

Запрос 1: [Инструкции 5,000 токенов][Документы 20,000 токенов][Вопрос A]
Запрос 2: [Инструкции 5,000 токенов][Документы 20,000 токенов][Вопрос B]
          └──────────────── совпадает до сих пор ─────────────┘└ отличается┘
→ 25,000 токенов инструкций + документов можно использовать повторно

Запрос 3: [Сегодняшняя дата][Инструкции 5,000 токенов][Документы 20,000 токенов][Вопрос C]
          └── отличается ──┘
→ Хотя всё остальное совпадает, повторно не используется ни один токен

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

2. Кэширование промптов OpenAI и Anthropic: сравнение

22 сентября 2026 года OpenAI объявила об улучшениях кэширования для GPT-6, и механизм изменился для GPT-5.6 и более новых моделей (хранение 30 минут, явные точки разрыва, платная запись в кэш и другое). Столбец OpenAI в таблице ниже описывает GPT-5.6 и новее. Отличия для GPT-5.5 и более старых моделей — после таблицы.

Источники: OpenAI «Prompt caching», «Prompt cache diagnostics»; Anthropic «Prompt caching», «Cache diagnostics», «Rate limits» (проверено 3 октября 2026 года)

У GPT-5.5 и более старых моделей есть только неявное кэширование: точки разрыва ставятся автоматически через фиксированные интервалы, а доплаты за запись в кэш нет. Время хранения задаётся через prompt_cache_retention: по данным руководства, in_memory держится «примерно 5–10 минут бездействия, до 1 часа», а 24h — «обычно около 30 минут, до 24 часов». При переходе на GPT-5.6 или новее замените эту настройку на prompt_cache_options.ttl.

Цены за токен для каждой модели собраны в нашем сравнении «Claude vs ChatGPT: сравнение цен». О моделях GPT-6 (Astra, Sol, Luna) — в «нашей статье о GPT-6 Sol и Luna», а актуальные модели всех вендоров — в «Даты отсечки знаний ИИ-моделей».

3. Когда кэш срабатывает: префикс, минимальная длина, TTL и область действия

Общий префикс и порядок частей запроса

На обеих платформах кэш срабатывает только тогда, когда префикс до точки разрыва совпадает в точности. Claude читает запрос с начала в порядке tools → system → messages, поэтому изменение одного определения инструмента сбрасывает кэш системного промпта и следующей за ним истории диалога. OpenAI тоже поясняет, что определения инструментов, формат вывода (text.format), уровень рассуждений (reasoning.effort) и подобные настройки входят в префикс.

На практике схема одна для обоих: сначала то, что не меняется (определения инструментов, инструкции, документы), в конце — то, что меняется в каждом запросе (даты, данные конкретного пользователя, вопрос). Диалог дополняйте добавлением в конец, не переписывая историю.

Расстановка точек разрыва: автоматически или вручную

Неявный режим OpenAI (GPT-5.6 и новее) ставит точку разрыва в конце самого свежего подходящего сообщения (сообщения пользователя, последнего из серии результатов инструментов и т. п.). В режиме «только явные» точками разрыва становятся лишь места, куда вы добавили prompt_cache_breakpoint, и если не добавить ни одной, кэш не используется и платить за запись тоже не нужно.

Автоматическое кэширование Claude, которое включается одним "cache_control": {"type": "ephemeral"} на верхнем уровне, ставит точку разрыва на последний блок, который можно кэшировать, и сдвигает её вперёд по мере роста диалога. Если добавить cache_control к отдельным блокам, точки разрыва выбираете вы сами.

// Claude: точка разрыва в конце неизменного системного промпта (явная точка разрыва)
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Длинные инструкции и документы...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "Сегодняшний вопрос..." }]
}

// OpenAI (Responses API): точка разрыва после неизменных инструкций, режим «только явные»
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Длинные инструкции и документы...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "Сегодняшний вопрос..." }
  ]
}

Минимальная длина: короткие префиксы не кэшируются

Для GPT-5.6 и новее минимум OpenAI — 1,024 токена видимого ввода (скрытые инструкции, которые OpenAI добавляет за кадром, не учитываются). У Claude минимум зависит от модели.

Источник: Anthropic «Prompt caching», Cache limitations (проверено 3 октября 2026 года). На Bedrock действуют значения из документации AWS.

Если промпт Claude короче минимума, добавление cache_control не вызывает ошибку — промпт просто молча не кэшируется. В этом случае cache_creation_input_tokens и cache_read_input_tokens в usage оба равны 0. Минимум меняется при смене модели, поэтому префикс, который кэшировался на прежней модели, может перестать кэшироваться (в руководстве OpenAI есть такое же предупреждение).

TTL: следите, от какого момента идёт отсчёт

У OpenAI (GPT-5.6 и новее) кэш живёт «не меньше 30 минут после последней записи или использования и может сохраняться дольше». У Claude по умолчанию 5 минут, а выбор 1 часа делает запись вдвое дороже цены ввода. На обеих платформах TTL продлевается без доплаты при каждом использовании кэша.

У Claude есть ловушка: TTL отсчитывается от начала запроса, а не от конца ответа. В примере из документации, если ответ генерируется 4 минуты, следующий запрос должен начаться примерно в течение 1 минуты после завершения этого ответа, чтобы попасть в 5-минутный кэш. Для агентов с длинным выводом 5 минут — меньше, чем кажется.

Область действия кэша и где он хранится

Кэш OpenAI действует в пределах организации и не разделяется между регионами обработки (настройки резидентности данных). В руководстве также сказано, что кэш хранится на отдельных машинах и что при нагрузке выше примерно 15 запросов в минуту запросы могут уходить на другую машину. Начиная с GPT-5.6 OpenAI управляет маршрутизацией автоматически, и prompt_cache_key стал необязательной настройкой для разделения отчётов о кэше по клиентам, а не способом поднять долю попаданий (для GPT-5.5 и старше было важно направлять запросы на одну машину с помощью одного и того же ключа).

Claude API ограничивает кэш рабочим пространством. Внутри одной организации разные рабочие пространства не делят кэш даже при одинаковых промптах. На Bedrock и Google Cloud — в пределах организации. Кроме того, кэш становится доступен только после того, как начался первый ответ, поэтому если разом отправить параллельно много запросов с одинаковым префиксом, остальные тоже станут записями ещё до того, как первый запишет кэш.

4. Цены и окупаемость: сколько чтений нужно, чтобы кэш окупился

Поскольку запись в кэш стоит дороже обычного ввода, запись, которую ни разу не прочитали, обходится дороже, чем работа без кэша. Пусть w — множитель записи, r — множитель чтения, n — число чтений после записи. Число чтений до окупаемости следует из этих формул.

С кэшем         = w + n × r
Без кэша        = 1 + n          (отправить тот же префикс n + 1 раз как есть)
Окупается, если : n > (w − 1) ÷ (1 − r)

Множители относительно цены ввода, принятой за 1. Расчёт по OpenAI «Prompt caching» и «Pricing» и Anthropic «Pricing» (проверено 3 октября 2026 года). Сравнивается только префикс; вывод и вопрос в каждом запросе не учитываются.

В руководстве OpenAI приведён тот же расчёт для модели с множителем 0.1x: одна запись и одно чтение стоят 1.35x против 2x за двукратную обработку без кэша. На странице цен Anthropic тоже сказано, что 5-минутный кэш окупается после одного чтения, а часовой — после двух. Как бы дёшево ни стоило чтение, часовой кэш не окупается за одно чтение, потому что запись по 2x слишком тяжела.

Модели с одинаковой ценой ввода: интервал между запросами меняет результат

По официальным ценам на 3 октября 2026 года GPT-6.1 Sol и Claude Sonnet 5.5 берут одинаково — $2 за миллион входных токенов, и цена 5-минутной записи у них тоже одна — $2.50. Различаются цена чтения (Sol $0.10, Sonnet 5.5 $0.20) и TTL. Мы посчитали стоимость префикса при 10-кратной отправке префикса на 100,000 токенов с разными интервалами.

Цены по OpenAI «Pricing» (Standard, до 272K) и Anthropic «Pricing» (обе проверены 3 октября 2026 года). 100,000 токенов = 0.1 (в единицах по 1 миллиону токенов). При попаданиях первый запрос — запись, остальные 9 — чтения; при промахах все 10 — записи. У OpenAI промах возможен и из-за маршрутизации между машинами и подобных факторов, поэтому строки с попаданиями — значения при благоприятных условиях.

Например, GPT-6.1 Sol каждые 3 минуты: «0.1 × $2.50 (одна запись) + 0.1 × $0.10 × 9 чтений = $0.25 + $0.09 = $0.34». Из таблицы видно три вещи.

• При интервале до 5 минут разница между ними невелика ($0.34 против $0.43). Всё решает только цена чтения.
• При интервале от 5 до 30 минут выигрывает 30-минутный TTL OpenAI. С 5-минутным TTL Claude каждый запрос становится записью и стоит $2.50 — дороже, чем без кэша. Переход на 1 час снижает стоимость до $0.58.
• Если интервал больше TTL, кэш приносит убыток. При запросах раз в 2 часа дешевле всего работать без кэша — $2.00. В Claude не добавляйте cache_control; в OpenAI GPT-5.6 и новее используйте режим «только явные» без точек разрыва — так вы избежите платы за запись.

Особенно важно, что у OpenAI GPT-5.6 и новее кэширование включено по умолчанию, поэтому в неявном режиме вы можете платить за запись даже того ввода, который больше никогда не отправите. Если ваша нагрузка состоит из множества длинных разовых вводов, проверьте cache_write_tokens в usage и решите, не перейти ли на режим «только явные».

Как кэширование сочетается с другими тарифами

• Batch: в прайс-листе OpenAI есть цены кэшированного ввода и записи в кэш и для Batch и Flex (GPT-6.1 Sol в Batch: ввод $1, чтение из кэша $0.05, запись в кэш $1.25). Anthropic пишет, что множители кэша складываются со скидкой 50% для batch, но поскольку пакетные запросы обрабатываются параллельно и в произвольном порядке, попадания в кэш описаны как «best effort» (без гарантии).
• Длинный ввод: у OpenAI, когда ввод превышает 272K токенов, цены ввода, чтения из кэша и записи в кэш удваиваются (множители не меняются). У Anthropic модели Claude 4.6 и новее берут одну и ту же цену до 1 миллиона токенов.
• Прогрев: у обоих запись при прогреве оплачивается по обычной цене записи. max_tokens: 0 у Claude не влечёт платы за вывод.

5. Почему кэширование промптов не срабатывает: частые причины

Если свести вместе замечания обоих вендоров о типичных ошибках и списки причин, которые возвращает их диагностика, причины промахов делятся примерно на три группы.

Частые проблемы у OpenAI

• Нет точки разрыва сразу после общего префикса: неявный режим ставит точку разрыва в конце последнего сообщения, поэтому при схеме «неизменные инструкции + каждый раз новое сообщение пользователя» изменяемая часть тоже записывается, и следующий запрос промахивается. Поставьте явную точку разрыва сразу после неизменной части.
• Переход на режим «только явные» посреди работы: в этом режиме ищутся только расставленные вами точки разрыва, поэтому записи кэша, сделанные в неявном режиме, не срабатывают.
• Дописывание в то же сообщение: если сообщение заканчивалось на «содержимое A», а стало «содержимое A + содержимое B», прежняя точка разрыва оказывается посреди сообщения, и кэш промахивается. Добавляйте новое содержимое отдельным сообщением.
• Смена уровня рассуждений посреди работы: у моделей GPT-6 уровень можно менять без сброса кэша — оставьте reasoning.effort в запросе как есть и добавьте configuration_update после ввода.
• Запуск компактизации (сжатия контекста): префикс меняется, поэтому доля попаданий падает. Впрочем, руководство отмечает, что общая стоимость всё равно может снизиться, потому что ввод сокращается, и советует сравнивать итоговую стоимость.

Частые проблемы у Claude

• Точка разрыва на блоке, который каждый раз меняется: записи происходят только в позициях точек разрыва, а чтение ищет только более ранние позиции записи, двигаясь назад. Если точка разрыва стоит на блоке, который каждый раз меняется, вы каждый раз платите за запись и ни разу не попадаете в кэш. Автоматическое кэширование тоже ставит точку разрыва на последний блок, поэтому попадает в ту же ловушку. Поставьте явную точку разрыва на последний неизменный блок.
• 20 и более блоков, добавленных за один ход: поиск прежних записей охватывает до 20 позиций назад от точки разрыва. Если диалог разом сильно вырос, прежняя запись оказывается за пределами этого окна. Держите дополнительную точку разрыва ближе к началу промпта.
• Переписывание системного промпта посреди работы: на поддерживаемых моделях инструкции можно добавлять без сброса кэша — оставьте верхнеуровневый system без изменений и добавьте в messages сообщение с "role": "system".
• Переключение между быстрым режимом (speed: "fast") и стандартным: это сбрасывает кэш системного промпта и диалога.

6. Как проверить попадания в кэш: usage и диагностика

Начните с usage: input_tokens означает разное

На обеих платформах usage в ответе показывает, сколько прочитано из кэша и сколько записано в него. Важно помнить, что input_tokens на двух платформах означает противоположные вещи.

Источники: OpenAI «Prompt caching», Monitor cache performance; Anthropic «Prompt caching», Tracking cache performance (проверено 3 октября 2026 года)

Если делить на input_tokens Claude, считая его полным вводом, и доля попаданий, и стоимость окажутся сильно искажены. Выводя цифры обоих вендоров на один дашборд, сначала приведите итоги по формулам выше, а потом сравнивайте. Руководство OpenAI рекомендует считать «долю попаданий по токенам» как сумму токенов, прочитанных из кэша, делённую на сумму входных токенов, с агрегацией по пользователям, по дням и т. д.

Стоимость у OpenAI — «(ввод − чтение − запись) × цена + чтение × цена × 0.1 + запись × цена × 1.25», у Claude — «input_tokens × цена + чтение × цена × 0.1 + запись × цена × 1.25 (2 для часовой части)» (множитель чтения замените на 0.05 или другое значение в зависимости от модели). У OpenAI на странице использования есть «Prompt Caching Dashboard», а документация Anthropic по Rate limits отсылает к странице Usage, где видна доля попаданий в кэш.

Что проверять по порядку, если чтений 0

1. Записей тоже 0? У Claude, если оба значения 0, промпт короче минимальной длины или нет cache_control. У OpenAI в режиме «только явные» записи тоже не будет, если вы не поставили ни одной точки разрыва.
2. Запись появляется в каждом запросе? Точка разрыва стоит на позиции, которая каждый раз меняется, или что-то в префиксе каждый раз меняется. Найти, что именно изменилось, поможет диагностика, описанная ниже.
3. Сколько прошло с предыдущего запроса? Проверьте, не превышены ли 5 минут Claude (включая время генерации ответа) или 30 минут OpenAI.

Диагностика OpenAI: prompt_cache_diagnostics

В Responses API OpenAI для поддерживаемых моделей начиная с GPT-5.6, если передать ID предыдущего ответа в prompt_cache_options.comparison_response_id, результат сравнения того запроса с текущим появится в prompt_cache_diagnostics. В документации сказано, что это бесплатно и отдельно в лимитах не учитывается.

// Добавить объект сравнения во второй запрос
{
  "model": "gpt-6.1-sol",
  "input": [ ...тот же префикс, что в первом запросе..., { "role": "user", "content": "Следующий вопрос" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_(ID первого ответа)" }
}

// Пример ответа при промахе (пример из документации: переименован инструмент)
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

У type четыре значения: cache_hit, cache_miss, comparison_response_not_found (записи для сравнения нет или она истекла) и unavailable (вывод сделать нельзя). При промахе reason принимает одно из девяти значений.

Источник: OpenAI «Prompt cache diagnostics», Fix a cache miss (проверено 3 октября 2026 года)

Диагностика Claude: diagnostics

В Claude API поле diagnostics нужно включать в каждый запрос, потому что API сохраняет отпечаток для сравнения (хеши и оценки числа токенов) только для запросов, где оно есть. В первом ходе передайте "previous_message_id": null, а дальше — id предыдущего ответа.

// Со второго хода
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_(id предыдущего ответа)" },
  "system": "...",
  "messages": [ ... ]
}

Если diagnostics в ответе равно null, различий не найдено (или сравнение не проводилось); {"cache_miss_reason": null} означает, что сравнение ещё не закончено; а если указана причина, она отмечает первое место, где запросы разошлись. Причин шесть: model_changed, system_changed, tools_changed, messages_changed, previous_message_not_found и unavailable. К причинам *_changed прилагается cache_missed_input_tokens — оценка того, сколько было потеряно.

Документация Claude советует читать диагностику вместе с cache_read_input_tokens.

Источник: Anthropic «Cache diagnostics», Reading diagnostics alongside usage (проверено 3 октября 2026 года)

У двух функций диагностики много общего: обе возвращают только первое найденное различие, поэтому после исправления нужно сравнить снова. Отличия в том, что диагностика Claude работает только в Claude API (не в Amazon Bedrock, Google Cloud, Claude Platform on AWS и Microsoft Foundry) и сравнивает только с запросами из того же рабочего пространства. В документации OpenAI не описан шаг, которым нужно заранее пометить предыдущий запрос для сравнения. У Claude, если в предыдущем запросе тоже не было diagnostics, вернётся previous_message_not_found.

7. Цифры доли попаданий: примеры вендоров и сторонние данные

Цифры доли попаданий в кэш, которые гуляют по сети, означают очень разное в зависимости от того, кто их опубликовал и в каких условиях. Разделим их.

Цифры от вендоров

• Примеры в руководстве OpenAI: разовая нагрузка по оценке (LLM в роли оценщика) с явной точкой разрыва после фиксированной рубрики достигла «доли попаданий по токенам около 70%», а агент, многократно вызывающий инструменты, — «более 90%». Руководство предупреждает, что это примеры возможных результатов и что потолок зависит от нагрузки.
• Комментарии клиентов в анонсе OpenAI (22 сентября 2026 года): команда Manus пишет, что после пересмотра расстановки точек разрыва её доля попаданий на моделях OpenAI меньше чем за неделю выросла «примерно с 85% до стабильно более 90%». В комментарии о GitHub Copilot говорится, что за последние несколько месяцев доля ввода, который нужно обрабатывать заново, снизилась более чем на 50% по сравнению с прежним базовым уровнем. И то и другое — цитаты клиентов, которые OpenAI опубликовала на своей странице, а не независимые измерения.
• Anthropic: в документации нет реальных цифр доли попаданий. На странице Rate limits есть пример расчёта: «при доле попаданий 80% лимит ввода в 2 миллиона токенов в минуту фактически позволяет обрабатывать 10 миллионов токенов в минуту», — но это арифметика на допущении, а не измерение.

Сторонние данные: не прямой вердикт о том, кто лучше

Requesty — сервис, который маршрутизирует запросы к нескольким ИИ-API, — агрегировал запросы, прошедшие через собственный шлюз, и опубликовал долю попаданий за апрель 2026 года: 77% для Anthropic напрямую (77.50% в таблице) и 36% для OpenAI (36.40%) («Prompt-cache hit rate per provider, April 2026», обновлено 9 мая). На первый взгляд Claude попадает в кэш более чем вдвое чаще, но есть четыре причины, по которым эти цифры нельзя использовать для сравнения в этой статье.

1. Данные получены до изменений у OpenAI: OpenAI ввела 30-минутное хранение и явные точки разрыва 22 сентября, а апрельские данные относятся к периоду до этого.
2. Нагрузки разные: это результаты приложений разных пользователей, которые отправляли через шлюз разные промпты с разными интервалами, а не один и тот же промпт, отправленный обоим вендорам. У Claude учитываются только запросы, где пользователи сами добавили cache_control.
3. Знаменатель: на странице указано «cached_tokens ÷ input_tokens», но, как объяснено в разделе 6, input_tokens у Claude не включает кэшированные токены. Как их пересчитывали, на странице не сказано.
4. Страница противоречит сама себе: в одном месте Claude через Google Cloud (Vertex) указан с 24%, в другом — с 14%.

По нашему поиску на 3 октября 2026 года сторонних измерений, где два кэша сравнивались бы в одинаковых условиях, не нашлось. В итоге единственный способ узнать, работает ли кэш в вашем приложении, — измерить его по собственным данным использования. Посчитайте долю попаданий и стоимость по формулам из раздела 6, а при промахах выясните причину с помощью диагностики.

Итоги

Кэширование промптов OpenAI и Claude построено на одной идее: повторно использовать одинаковый префикс и брать за чтение около 0.1x цены ввода. Разница в том, что у OpenAI (GPT-5.6 и новее) кэш включён по умолчанию, хранится не меньше 30 минут и запись стоит 1.25x, а Claude кэширует, только если добавить cache_control, хранит кэш 5 минут (опционально 1 час) и берёт за запись 1.25x (2x за 1 час).

По цене: раз запись стоит дороже, кэш, который ни разу не прочитали, — это убыток. 5- и 30-минутный кэш окупаются после одного чтения, часовой кэш Claude — после двух. При интервалах от 5 до 30 минут преимущество у 30-минутного TTL OpenAI, а в Claude выбор 1 часа предотвращает перелом. Если запросы разнесены дальше, чем TTL, дешевле обойтись без кэша.

Проверяйте работу кэша по объёмам чтения и записи в usage. input_tokens у Claude охватывает только то, что идёт после точки разрыва, поэтому сначала посчитайте итог, а потом долю попаданий. При промахе prompt_cache_diagnostics у OpenAI и diagnostics у Claude покажут, чем запрос отличается от предыдущего. Другие способы сократить расходы — в статье «Как сократить расходы на ИИ».

FAQ

В. Какой TTL у кэширования промптов OpenAI?

О. Для GPT-5.6 и новее — не меньше 30 минут после последней записи или использования. Настройка prompt_cache_options.ttl принимает только "30m", а руководство говорит, что кэш может сохраняться дольше. Для GPT-5.5 и старше выбор делается через prompt_cache_retention: in_memory держится примерно 5–10 минут бездействия (до 1 часа), 24h — до 24 часов.

В. Можно ли продлить TTL кэширования промптов в Claude?

О. Да, "cache_control": {"type": "ephemeral", "ttl": "1h"} даёт 1 час. Запись стоит 2x цены ввода, так что это окупается, только если кэш прочитают хотя бы дважды. Если вы продолжаете обращаться с интервалом меньше 5 минут, 5-минутный кэш бесплатно продлевается при каждом чтении. Оба отсчитываются от начала запроса, поэтому время генерации длинного ответа входит в TTL.

В. Меняет ли кэширование ответы?

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

В. Можно ли очистить кэш вручную?

О. Ни одна из платформ этого не позволяет. OpenAI пишет, что записи истекают в соответствии с TTL и настройками, а Anthropic — что они удаляются автоматически не менее чем через 5 минут без использования (через 1 час, если выбран 1 час). Если нужно заменить содержимое промпта, измените префикс — следующий запрос запишет новую запись.

Источники

• Документация OpenAI API: Prompt caching
• Документация OpenAI API: Prompt cache diagnostics
• Документация OpenAI API: Pricing
• OpenAI: Better prompt caching for GPT-6 (22 сентября 2026 года)
• Документация Claude Platform: Prompt caching
• Документация Claude Platform: Cache diagnostics
• Документация Claude Platform: Pricing
• Документация Claude Platform: Rate limits
• Requesty: Prompt-cache hit rate per provider, April 2026

Все источники проверены в оригинале 3 октября 2026 года. Цены, TTL и минимальная длина могут меняться с выходом новых моделей, поэтому перед использованием сверяйтесь со страницей цен каждого вендора. Расчёты стоимости в этой статье — арифметика по официальным ценам, а не результаты наших собственных вызовов API.