Новый prompt-caching API Claude Opus 5 резко снижает расходы на токены в приложениях чат-стиля, позволяя модели пропускать повторное чтение неизменного текста. Первый запрос оплачивается с небольшой наценкой; каждый последующий запрос стоит примерно в десять раз меньше базовой ставки, превращая регулярные расходы в разовые платежи.

Почему разработчики платят дважды за одни и те же слова

Большинство диалоговых интерфейсов пересобирают полный промпт при каждом ходе: системный промпт объемом 8 000 токенов, прикрепленные PDF-файлы и полная история диалога каждый раз отправляются модели вместе с новым вопросом пользователя. Модель заново обрабатывает каждый токен, хотя большая часть этого текста не меняется. При текущих ценах такая избыточность может составлять основную часть стоимости работы активно использующегося бота.

Как кэширование меняет расчеты

API создает запись в кэше для каждого «блока» токенов вплоть до определенной границы. Когда следующий запрос содержит тот же блок в начале, сервис считывает его из кэша вместо повторной токенизации. Распределение стоимости отражает сэкономленную работу:

  • Запись в кэш – TTL 5 минут: 1.25 × базовая цена
  • Запись в кэш – TTL 1 час: 2 × базовая цена
  • Чтение из кэша (hit): 0.1 × базовая цена

На практике первый вызов нового блока стоит немного дороже обычного запроса. Каждый последующий вызов, попадающий в кэш, обходится на 90% дешевле, поэтому чистые расходы резко снижаются по мере углубления диалога.

«Золотое правило» структурирования промптов

Эффективность кэширования зависит от того, где вы размещаете статический и динамический контент. Размещайте всё неизменное в начале, а постоянно меняющиеся части — в конце. Надежный порядок выглядит так:

  1. Tools — определения любых внешних функций, которые модель может вызывать.
  2. System instructions — высокоуровневые инструкции, которым должна следовать модель.
  3. Documents — длинный контекст, такой как PDF-файлы, базы знаний или выдержки из политик.
  4. User questions — текущий запрос, который меняется при каждом ходе.

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

Скрытые ограничения, которые необходимо учитывать

  • Минимальный размер блока — Opus 5 кэширует только блоки, содержащие не менее 512 токенов. Всё, что меньше, полностью пропускается мимо кэша.
  • Ошибка с временной меткой — вставка меняющейся временной метки внутри кэшируемого блока гарантирует промах (miss), так как текст блока никогда не будет совпадать в точности.
  • Просмотр последних 20 блоков — сервис сканирует только последние 20 блоков на предмет совпадений. Длительные сессии, которые быстро продвигаются вперед, могут выйти за пределы окна кэша.
  • Параллельные запросы — отправка нескольких идентичных запросов в один и тот же момент приведет к тому, что все они промахнутся, так как кэш заполняется только после завершения первого запроса. Сначала «прогрейте» кэш одним вызовом, а затем отправляйте остальные.

Как увидеть экономию в ответе API

Каждый ответ содержит три счетчика токенов:

  • cache_read_input_tokens — токены, полученные из кэша (попадание в кэш).
  • cache_creation_input_tokens — токены, записанные в кэш в этом запросе.
  • input_tokens — новые токены, которые не были закэшированы.

Сложите эти три числа, чтобы получить общее количество токенов, которые модель обработала за этот ход. Если оба поля кэша равны нулю, значит, запрос не попал в кэш; проверьте размер блока и расположение границ.

Итог: Вынося неизменяемый контекст в начало и позволяя API prompt-caching Claude Opus 5 выполнять основную работу, вы превращаете регулярные расходы на токены в разовые платежи. Результатом является резкое снижение стоимости для любого чат-бота, который многократно обращается к одному и тому же системному промпту или набору документов — при условии, что вы соблюдаете минимальный порог токенов, избегаете изменяемых маркеров внутри кэшируемых блоков и удерживаете подходящий для кэширования контент в пределах горизонта в 20 блоков.