Расчет окупаемости кэширования промптов в Claude

Стоимость кэширования промптов до того, как оно начнет приносить выгоду

Кэширование промптов позволяет Claude повторно использовать начальную часть промпта вместо того, чтобы считывать её при каждом вызове. Итоговая стоимость зависит от двух коэффициентов, применяемых к базовой цене входных данных модели. По состоянию на октябрь 2026 года запись в кэш стоит 1.25x от базовой цены входных данных при времени жизни 5 минут или 2x при времени жизни 1 час для любой модели. Чтение из кэша для большинства моделей стоит 0.1x, однако этот коэффициент больше не является единым для всех. Для Claude Fable 5.1 и Claude Mythos 5.1, запущенных с этим тарифом 1 сентября 2026 года, он составляет 0.025x. Для Claude Opus 5.5 и Claude Sonnet 5.5 он равен 0.05x, причем для Sonnet 5.5 ставка была снижена с 0.1x до этого уровня 7 октября 2026 года. Приведенные ниже расчеты используют стандартный коэффициент чтения 0.1x. Более дешевое чтение немного смещает точку безубыточности в вашу пользу, и в следующем разделе показано, насколько именно.

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

Точка безубыточности в одном алгебраическом выражении

Обозначим B как базовую стоимость ввода префикса без кэширования. Без кэша N запросов стоят N умножить на B. При использовании 5-минутного кэша первый запрос записывает префикс по цене 1.25B, а остальные N минус 1 запросов считывают его по 0.1B. Приравняем эти значения: 0.9N = 1.15, откуда N = 1.28. Второй запрос уже обходится дешевле, чем работа без кэширования.

Повторим расчет для 1-часового кэша с двойной стоимостью записи: 0.9N = 1.9, откуда N = 2.11. Для долгосрочного кэша требуется два чтения, чтобы выйти в ноль, поэтому он не является выбором по умолчанию.

При более дешевых операциях чтения линия смещается, но незначительно. При стоимости чтения 0.05x для 5-минутного кэша получаем 0.95N = 1.2, то есть N = 1.26, а при 0.025x — 0.975N = 1.225, что также дает N = 1.26. Для 1-часового кэша значения падают до N = 2.05 и N = 2.03. Практический вывод одинаков для любой модели: 5-минутный кэш окупается со второго запроса, 1-часовой — с третьего.

На графике ниже приведен расчет для префикса объемом 20,000 токенов на модели Claude Opus 5. Базовая стоимость ввода составляет $5 за миллион токенов по состоянию на октябрь 2026 года, цена не менялась с августа. Opus 5 теперь является устаревшей моделью, хотя все еще доступна. Ее преемник, Claude Opus 5.5, стоит $4 за миллион при стоимости чтения 0.05x, поэтому запись того же префикса там стоит $0.10, а чтение — $0.004. Умножьте каждое значение на 0.6 для модели со стоимостью $3 за миллион при стандартном чтении 0.1x. Форма кривой при этом не меняется.

[
  {
    "requests": 1,
    "uncached_usd": "0.10",
    "cached_5m_usd": "0.125",
    "cached_1h_usd": "0.20"
  },
  {
    "requests": 2,
    "uncached_usd": "0.20",
    "cached_5m_usd": "0.135",
    "cached_1h_usd": "0.21"
  },
  {
    "requests": 3,
    "uncached_usd": "0.30",
    "cached_5m_usd": "0.145",
    "cached_1h_usd": "0.22"
  },
  {
    "requests": 5,
    "uncached_usd": "0.50",
    "cached_5m_usd": "0.165",
    "cached_1h_usd": "0.24"
  },
  {
    "requests": 10,
    "uncached_usd": "1.00",
    "cached_5m_usd": "0.215",
    "cached_1h_usd": "0.29"
  },
  {
    "requests": 20,
    "uncached_usd": "2.00",
    "cached_5m_usd": "0.315",
    "cached_1h_usd": "0.39"
  }
]

Одиночный запрос стоит $0.10 без кэширования и $0.125 с кэшированием, поэтому кэширование разового промпта — это чистый убыток. К моменту второго запроса стоимость 5-минутного кэша составляет $0.135 против $0.20. 1-часовой кэш в этой точке все еще проигрывает: $0.21 против тех же $0.20, и он становится выгоднее варианта без кэширования только на третьем запросе: $0.22 против $0.30. К 20 запросам разница составляет $2.00 против $0.315.

Попадание в кэш (cache hit) также обновляет запись, поэтому в опубликованной таблице цен этот столбец называется «попадания и обновления» (cache hits and refreshes). Таким образом, активная конечная точка поддерживает 5-минутную запись в актуальном состоянии бесконечно долго по ценам чтения, а 1-часовой срок жизни оправдывает свою двойную стоимость записи только при наличии реальных пауз в трафике.

Во что обходится низкий коэффициент попаданий

Реальный трафик приводит к промахам. Запрос, который не попадает в кэш, но всё равно содержит точку останова, тарифицируется как запись, поэтому корректный способ моделирования затрат — это функция от коэффициента попаданий. На графике ниже это показано для 1000 запросов, каждый из которых содержит одинаковый префикс из 20000 токенов.

[
  {
    "hit_rate_percent": 0,
    "cost_5m_usd": "125.00",
    "cost_1h_usd": "200.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 25,
    "cost_5m_usd": "96.25",
    "cost_1h_usd": "152.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 50,
    "cost_5m_usd": "67.50",
    "cost_1h_usd": "105.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 75,
    "cost_5m_usd": "38.75",
    "cost_1h_usd": "57.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 90,
    "cost_5m_usd": "21.50",
    "cost_1h_usd": "29.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 95,
    "cost_5m_usd": "15.75",
    "cost_1h_usd": "19.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 99,
    "cost_5m_usd": "11.15",
    "cost_1h_usd": "11.90",
    "uncached_usd": "100.00"
  }
]

При коэффициенте попаданий 0 процентов вы платите $125.00 вместо $100.00, а часовой кэш увеличивает счет вдвое до $200.00. Решив уравнение 1.25 минус 1.15h = 1, получаем, что 5-минутный кэш начинает экономить средства при коэффициенте попаданий около 22 процентов, поэтому при 25 процентах уже отображается $96.25. Аналогичный расчет для двойной записи дает около 53 процентов для часового кэша, поэтому при 50-процентном коэффициенте попаданий стоимость все еще составляет $105.00, что выше линии без кэширования. При 90 процентах значения достигают $21.50 и $29.00. При 99 процентах короткий кэш достигает $11.15, что близко к нижнему пределу, составляющему одну десятую от цены без кэширования.

В модели с чтением 0.05x пороги снижаются примерно до 21 процента для 5-минутного кэша и до 51 процента для часового кэша. При чтении 0.025x они падают примерно до 20 и 51 процента. Нижний предел снижается вместе со стоимостью чтения до одной двадцатой или одной сороковой от стоимости без кэширования.

Коэффициент попаданий — это показатель, который необходимо отслеживать, поскольку это единственный параметр, который вы контролируете после фиксации размера префикса.

Какие префиксы стоит использовать для точек останова

Запрос может содержать до четырех точек останова кэша, поэтому возникает вопрос, какие блоки их заслуживают. Кандидатами являются блоки, которые идентичны побайтово при разных вызовах и достаточно велики, чтобы это имело значение. В таблице ниже приведена стоимость четырех распространенных конфигураций при 1000 запросов с коэффициентом попадания 90 процентов в 5-минутном кэше.

[
  {
    "label": "System prompt",
    "prefix_size_tokens": "2,000",
    "uncached_usd": "10.00",
    "cached_usd": "2.15",
    "saved_usd": "7.85"
  },
  {
    "label": "System plus tools",
    "prefix_size_tokens": "8,000",
    "uncached_usd": "40.00",
    "cached_usd": "8.60",
    "saved_usd": "31.40"
  },
  {
    "label": "Policy document",
    "prefix_size_tokens": "25,000",
    "uncached_usd": "125.00",
    "cached_usd": "26.88",
    "saved_usd": "98.12"
  },
  {
    "label": "Codebase context",
    "prefix_size_tokens": "120,000",
    "uncached_usd": "600.00",
    "cached_usd": "129.00",
    "saved_usd": "471.00"
  }
]

Системный промпт с токенами 2,000 позволяет сэкономить $7.85 на 1000 запросов по сравнению с $10.00 без кэширования. Это реальные деньги при больших объемах, но не это делает кэширование интересным. Добавьте определения инструментов, и вы получите 8,000 токенов и $31.40 экономии. Политика объемом 25,000 токенов, к которой обращается каждый запрос, экономит $98.12. Последняя строка — это то, что меняет архитектуру: 120,000 токенов контекста кодовой базы или транскрипта стоят $600.00 без кэширования и $129.00 с кэшированием, что дает экономию в $471.00.

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

Как это выглядит в ежемесячном счете

На графике ниже используется префикс токенов 8,000 из примера выше, системный промпт и определения инструментов при частоте попаданий 90 процентов, с масштабированием до ежемесячных объемов запросов.

[
  {
    "label": "10k requests",
    "uncached_usd": "400.00",
    "cached_usd": "86.00",
    "saved_usd": "314.00"
  },
  {
    "label": "100k requests",
    "uncached_usd": "4,000.00",
    "cached_usd": "860.00",
    "saved_usd": "3,140.00"
  },
  {
    "label": "1M requests",
    "uncached_usd": "40,000.00",
    "cached_usd": "8,600.00",
    "saved_usd": "31,400.00"
  }
]

При 10,000 запросов в месяц экономия составляет $314.00 — это разница между $400.00 и $86.00. При 100,000 запросов экономия составляет $3,140.00. При миллионе запросов счет за входные токены без кэширования составит $40,000.00, а кэширование позволит сократить его на $31,400.00. Это касается только входных токенов. Выходные токены оплачиваются отдельно, и кэширование на них не влияет. Об этом стоит помнить, прежде чем обещать кому-либо снижение счета на 90 процентов. Кэширование является одним из методов, описанных в руководстве по контролю расходов на AI-агента на VPS.

Как убедиться, что кэширование работает

Не полагайтесь только на архитектуру. Изучите блок использования (usage) в ответе. Каждый ответ Messages API сообщает количество записанных в кэш токенов, количество прочитанных из кэша токенов и количество новых токенов, которые пришлось обработать.

from anthropic import Anthropic

client = Anthropic()

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=512,
    system=[
        {
            "type": "text",
            "text": POLICY_DOCUMENT,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": question}],
)

u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)

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

Аналогичная проверка из командной строки для тела запроса, сохраненного в request.json:

curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d @request.json | jq '.usage'

При корректной работе второй вызов выведет примерно следующее:

{
  "input_tokens": 42,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 20143,
  "output_tokens": 187
}

Одна строка скажет вам правду. Если cache_read_input_tokens остается равным 0 при повторных вызовах, вы каждый раз оплачиваете запись с коэффициентом 1.25x и не получаете никакой выгоды.

Для времени жизни в 1 час контрольная точка имеет время жизни (TTL):

{
  "type": "text",
  "text": "your stable prefix",
  "cache_control": {"type": "ephemeral", "ttl": "1h"}
}

Также существует автоматическое кэширование: поле cache_control верхнего уровня в запросе, после которого API самостоятельно управляет контрольными точками по мере роста диалога. Оно занимает один из четырех доступных слотов для контрольных точек. Начните с него. Переходите к явным контрольным точкам, когда вам нужно точно определить границы кэшируемого сегмента.

Правило порядка, снижающее эффективность кэширования

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

Отсюда следует одно правило без исключений. Всё, что меняется между вызовами, должно идти после всего, что остаётся неизменным.

Чаще всего проблему вызывает временная метка. Строка Current time: 2026-08-03T14:07:11Z в начале системной инструкции гарантирует 0 процентов попаданий в кэш, так как хеш префикса при каждом вызове будет разным, и ни одна предыдущая запись не сможет совпасть. Переместите её в сообщение пользователя, в самый конец. Идентификатор сессии или nonce для каждого запроса нарушают работу аналогичным образом, и решение для них такое же. Полученные документы, которые различаются в каждом запросе, также должны располагаться после кэшируемого блока, иначе они сдвигают каждый стабильный токен за границу, которая постоянно перемещается.

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

Третья причина — изменение параметра, которое вы не рассматривали как содержимое промпта. У другой модели другой кэш. Изменение tool_choice аннулирует историю сообщений, хотя инструменты и системная инструкция остаются в кэше. Добавление или удаление инструмента аннулирует всё.

Минимальный префикс и отсутствие уведомлений

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

• 512 токенов для Claude Opus 5 и Claude Fable 5, а также для новых моделей Opus 5.5, Sonnet 5.5, Fable 5.1 и Haiku 5.5
• 1,024 токена для Claude Sonnet 5 и Claude Opus 4.8
• 4,096 токенов для Claude Haiku 4.5

Если оба счетчика показывают 0 для запроса, который, по вашему мнению, должен кэшироваться, в первую очередь проверьте длину префикса. Именно поэтому самая дешевая модель не всегда является наиболее выгодной для задач с использованием кэширования. Для модели Haiku 4.5 требуется префикс в восемь раз длиннее, чем для Opus 5, чтобы кэширование вообще начало работать. Таким образом, системный промпт объемом 2,000 токенов будет кэшироваться одной моделью и безмолвно игнорироваться другой.

Где Claude Code выполняет кэширование и где это невозможно

Claude Code кэширует свой префикс. Системный промпт и определения инструментов находятся в начале каждого запроса и не меняются, поэтому они записываются один раз и считываются в течение всей сессии. Именно поэтому стоимость одного шага в длинной сессии значительно ниже, чем можно предположить исходя из размера контекста, что отражается в счетчиках, описанных в как Claude Code сообщает об использовании токенов.

Кэширование не помогает в случае изменений в начале контекста. История диалога доступна только для добавления, поэтому обычные новые шаги расширяют уже закэшированный префикс. Редактирование файла, который был прочитан в начале сессии, не нарушает кэш, так как Claude Code добавляет примечание об изменении файла, а не перезаписывает предыдущее чтение. Кэш сбрасывается при смене моделей, так как у каждой модели свой собственный кэш. Подключение MCP-сервера, инструменты которого загружаются в префикс, также сбрасывает кэш, как и сжатие истории диалога. Каждое из этих действий приводит к тому, что на следующем шаге префикс записывается заново. Длительный простой приводит к тому же результату, так как срок действия записи истекает, и следующий шаг требует полной записи. Ни одно из этих явлений не является ошибкой. Это правило работы префикса, которое выполняется в точном соответствии с описанием.

Если вы пишете собственный клиент, используйте структуру из первого запроса, а не адаптируйте её позже: формируйте вызов так, как это делает первое приложение для Claude API на VPS, размещая стабильные блоки в начале, а изменяемые — в конце.

Режимы сбоев и их признаки

Каждый вызов — это запись. cache_creation_input_tokens принимает ненулевое значение при каждом запросе, в то время как cache_read_input_tokens остается равным 0. Что-то в точке останова или до нее меняется между вызовами. Выведите первые 200 символов собранного префикса для двух последовательных запросов и сравните их визуально.

Оба счетчика равны 0. Префикс короче минимально допустимого для модели, либо поле cache_control не дошло до API. Сначала подсчитайте токены префикса, затем выведите в лог тело запроса, которое вы фактически отправили.

Чтение работает, затем прекращается. Серия попаданий, затем запись, затем снова попадания. Интервал между запросами превысил время жизни (TTL). Примите факт записи или переключитесь на TTL 1 час после того, как убедитесь, что частота попаданий превышает 53 процента (или около 51 процента для моделей с коэффициентом чтения 0.05x или 0.025x).

Частота попаданий падает после развертывания. Было изменено описание инструмента или сама модель. И то, и другое делает весь префикс недействительным. Ожидайте один дорогостоящий цикл записи после каждого развертывания, затрагивающего промпт.

Счет за услуги вырос после включения кэширования. Частота попаданий ниже точки окупаемости. При значении ниже примерно 22 процентов для 5-минутного кэша отправка префикса без кэширования обходится дешевле; для 1-часового кэша этот порог составляет около 53 процентов. Для моделей с более дешевым чтением эти значения составляют примерно 20–21 процент и 51 процент соответственно.

FAQ

Сколько раз нужно повторно использовать промпт, чтобы кэширование стало выгодным?

Один раз при использовании 5-минутного кэша. Запись стоит 1.25x от базовой стоимости входных токенов, а чтение — 0.1x для большинства моделей. Таким образом, N запросов без кэша стоят N, а N запросов с кэшем стоят 1.25 плюс 0.1 умножить на N минус 1. Точка окупаемости находится на уровне N = 1.28, поэтому уже второй запрос становится выгоднее. Для моделей с коэффициентом чтения 0.05x или 0.025x точка окупаемости составляет N = 1.26, что дает тот же результат. 1-часовой кэш требует 2x за запись и окупается при N = 2.11, или примерно при 2.05 для более дешевых моделей чтения, поэтому для него требуется два обращения.

Почему значение cache_read_input_tokens всегда равно нулю?

Сначала проверьте длину префикса: если она меньше минимально допустимой для модели (512 токенов для Claude Opus 5 и 4,096 для Claude Haiku 4.5 по состоянию на октябрь 2026 года), кэширование пропускается без уведомлений, и оба счетчика показывают 0. Если префикс достаточно длинный, поищите контент, который меняется между вызовами и находится на точке разделения или перед ней, например, временную метку или идентификатор сессии в системном промпте. Если счетчики работали, но перестали, значит, интервал между запросами превысил время жизни кэша.

Меняет ли кэширование промптов ответы Claude?

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

Стоит ли платить за 1-часовой кэш?

Только если в вашем трафике есть паузы длиннее 5 минут, а частота попаданий в кэш (hit rate) при этом будет составлять примерно 53 процента, или около 51 процента для модели с более дешевым чтением. В случае промаха (miss) запись с коэффициентом 2x стоит в четыре раза дороже, чем запись 1.25x. Промах при 1-часовой записи приводит к потере полной стоимости базового ввода префикса, тогда как промах при 5-минутной записи обходится лишь в четверть этой суммы. 5-минутный кэш обновляется при каждом попадании, поэтому стабильный трафик поддерживает его активность по цене чтения, не требуя оплаты за более длительный срок хранения.