platform.claude.com/docs/en/build-with-claude/prompt-caching) и адаптирована под конфигурацию APIYI с примерами, готовыми для копирования и вставки.
В одном предложении
Пометьте длинный, повторно используемый префикс prompt (системные инструкции / длинный документ / few-shot примеры) с помощьюcache_control. Сервер сохраняет его; при следующем запросе с тем же префиксом он пропускает повторную обработку — примерно в 10× дешевле и быстрее. Он истекает после периода неактивности.
Зачем это нужно — посмотрите на коэффициенты
Относительно базовой цены входных token у модели (1×):
Точки безубыточности:
- TTL 5 минут: достаточно всего 2 повторных использования одного и того же префикса, чтобы выйти в ноль (1.25 + 0.1 = 1.35, дешевле, чем 2.0 за два запроса без кэша).
- TTL 1 час: нужно 3 повторных использования, чтобы выйти в ноль (2 + 0.2 = 2.2, дешевле, чем 3.0).
TTL — это скользящее окно: каждое попадание в кэш сбрасывает таймер истечения, поэтому активные разговоры не истекают у вас под носом. Только реальное бездействие сверх TTL приводит к вытеснению.
Хорошо подходит
- Один и тот же длинный системный prompt вызывается много раз (агенты, чат-боты)
- Многоходовые разговоры (каждый предыдущий ход становится повторно используемым префиксом)
- Пакетная обработка одного документа (50 вопросов по одному контракту)
- RAG, где стабильные извлеченные фрагменты формируют префикс
Плохо подходит
- Каждый prompt отличается с первой же буквы
- Все очень короткое и ни разу не превышает минимальный порог для конкретной модели (ниже)
Три обязательных требования
Все три обязательны.1. Явный маркер cache_control
content не может быть обычной строкой. Это должен быть массив блоков содержимого, а кэшируемый блок должен содержать cache_control:
2. Длина должна превышать минимальное значение для модели
Если содержимое короче минимального значения для модели, оно не будет кэшироваться даже с маркером (ошибки не возникнет — содержимое просто будет молча пропущено). Проверено по официальной документации Anthropic:Измерено в APIYI (2026-07-29). Мы проверили порог записи, постепенно увеличивая размер фиксированного префикса:
claude-opus-5 не вызвало записи в кэш при 301 token, но вызвало её при 614, что ограничивает официальный порог 512; claude-sonnet-5 не вызвало записи при 612, но вызвало её при 1 250, что ограничивает официальный порог 1 024. Оба результата соответствуют приведённой выше таблице.3. Префикс должен побайтно совпадать
Кэширование выполняется на основе префикса: начиная с начала запроса и до маркераcache_control поток байтов должен быть идентичен предыдущему запросу. Любое изменение одного символа — пробел, порядок ключей JSON, временная метка — считается новым префиксом и запускает новую запись вместо попадания в кэш.
Практическое правило: стабильные данные — в начале, изменяемые — в конце.
Минимальный запускаемый пример
Отправьте два запроса, используя один и тот же длинный документ, но разные вопросы. Первый записывает, второй попадает в кэш:read ≈ у первого вызова write — тот же префикс используется повторно.
Как определить, было ли попадание в кэш — три поля usage
В каждом ответе,usage сообщает:
Итого входные tokens = сумма всех трех. Пока
cache_read_input_tokens > 0, вы экономите деньги.
Наиболее распространённые ошибки
Продвинутое: многоходовые диалоги
Разместитеcache_control на последнем блоке контента последнего сообщения пользователя. Каждый новый ход автоматически расширяет кэшированный диапазон чтения до конца предыдущего хода:
- Не более 4
cache_controlточек разрыва на запрос. - Окно поиска префикса у каждой точки разрыва — не более 20 блоков контента назад; все, что старше, не будет учитываться при попадании в кэш. Иными словами, в очень длинных диалогах отметка только последнего хода не покроет всю предыдущую историю.
Об APIYI и кэшировании
APIYI передает поля кэша сквозным образом.
cache_control, который вы отправляете, без изменений передается во upstream Claude (AWS Claude или Claude Official), а возвращаемые cache_creation_input_tokens / cache_read_input_tokens напрямую возвращаются вам — в вашем коде не требуется никакой специальной адаптации.- При первом запросе,
usage.cache_creation_input_tokens > 0(запись выполнена). - Через несколько секунд отправьте тот же префикс еще раз — вы должны увидеть
usage.cache_read_input_tokens > 0(попадание). - На панели тарификации будут отдельно указаны cache writes и cache reads с теми же официальными коэффициентами (1.25× / 2× / 0.1×).
Кратко
1. Отметьте это
cache_control: {"type": "ephemeral"} на блоке контента — plain-string content никогда не кэшируется.2. Достаточной длины
Opus 5 ≥ 512; Sonnet 5 / Sonnet 4.6 ≥ 1,024; Opus 4.7 ≥ 2,048; Opus 4.6 / Haiku 4.5 ≥ 4,096 tokens, иначе пропускается без уведомления.
3. Стабильный префикс
Стабильное — в начале, изменчивое — в конце; одно расхождение в символе убивает попадание в кэш.
4. Проверьте использование
Только
cache_read_input_tokens > 0 доказывает, что вы действительно сэкономили.Связанные ссылки
- Родительская страница: Claude API Basics
- Руководства по настройке клиента: Claude Code integration · Cherry Studio integration
- Получение / управление token:
https://api.apiyi.com/token - Официальная документация Anthropic:
platform.claude.com/docs/en/build-with-claude/prompt-caching