Claude prompt caching: розрахунок точки беззбитковості

Вартість кешування промптів до отримання економії

Кешування промптів дає змогу Claude повторно використовувати початок промпту замість того, щоб зчитувати його під час кожного виклику. Усе рішення зводиться до двох множників базової ціни вхідних даних для вашої моделі. Станом на August 2026 запис у кеш коштує 1.25x базової ціни вхідних даних за час життя 5 minutes або 2x за час життя 1 hour. Читання з кешу коштує 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. Для довгого кешу потрібно два читання, щоб досягти точки беззбитковості. Саме тому цей варіант не є типовим.

На графіку нижче наведено вартість для префікса на 20,000 токенів у Claude Opus 5, де базова ставка за вхідні дані станом на August 2026 становить $5 за мільйон токенів. Для моделі зі ставкою $3 за мільйон помножте кожне значення на 0.6. Форма кривої не змінюється.

[
  {
    "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 із кешуванням, тому кешування одноразового prompt є чистою втратою. Для другого запиту кеш на 5 хвилин уже дає $0.135 проти $0.20. На цьому етапі кеш на 1 годину все ще дорожчий: $0.21 проти того самого $0.20. Він стає дешевшим за варіант без кешування лише на третьому запиті: $0.22 проти $0.30. Для 20 запитів різниця становить $2.00 проти $0.315.

Влучання в кеш також поновлює запис. Саме тому в опублікованій таблиці цін цей стовпець називається cache hits and refreshes. Тому активний endpoint може необмежено довго підтримувати запис у кеші на 5 хвилин за ціною читання. Час життя 1 година дає перевагу подвійного запису лише тоді, коли між запитами є реальні паузи.

Ціна низького відсотка влучань

Реальний трафік містить промахи. Запит, який не знаходить дані в кеші, але все одно передає breakpoint, тарифікується як запис, тому коректно моделювати вартість як функцію відсотка влучань. На наведеній нижче діаграмі це показано для 1,000 запитів, кожен із яких передає однаковий префікс на 20,000 токенів.

[
  {
    "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, а кеш на 1 годину збільшує рахунок удвічі — до $200.00. Розв’язання рівняння 1.25 мінус 1.15h = 1 показує, що кеш на 5 хвилин починає заощаджувати кошти приблизно за 22 відсотків влучань. Саме тому за 25 відсотків уже відображається $96.25. Такий самий розрахунок для запису з коефіцієнтом 2x дає приблизно 53 відсотки для кешу на 1 годину. Тому за 50 відсотків влучань він усе ще коштує $105.00, тобто більше, ніж без кешування. За 90 відсотків обидва варіанти дають $21.50 і $29.00. За 99 відсотків короткостроковий кеш досягає $11.15, що близько до мінімуму, який становить одну десяту ціни без кешування.

Відсоток влучань потрібно вимірювати, оскільки після фіксації розміру префікса це єдиний параметр, яким ви можете керувати.

Які префікси варто кешувати

Запит може містити до чотирьох кешованих префіксів, тому важливо визначити, які блоки цього варті. Кандидатами є блоки, ідентичні на рівні байтів у різних викликах і достатньо великі, щоб це мало значення. На наведеній нижче діаграмі показано вартість чотирьох поширених структур для 1,000 запитів за 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"
  }
]

Системний prompt без інструментів обсягом 2,000 токенів заощаджує $7.85 на 1,000 запитів порівняно з $10.00 без кешування. На великому обсязі це реальні кошти, але саме кешування цікавим робить не це. Додайте визначення інструментів — і отримаєте 8,000 токенів та $31.40 заощаджень. Документ політики обсягом 25,000 токенів, про який користувач ставить запитання в кожному запиті, заощаджує $98.12. Останній рядок змінює архітектуру: контекст кодової бази або транскрипту обсягом 120,000 токенів коштує $600.00 без кешування і $129.00 з кешуванням, тобто заощадження становить $471.00.

Заощадження зростають разом із розміром префікса та часткою влучань у кеші, і більше ні з чим. Це змінює підхід до того, що взагалі варто додавати в prompt: скільки насправді коштує мільйон токенів 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 враховує лише токени після останньої точки збереження, тому під час коректного другого виклику це значення невелике — зазвичай воно охоплює лише нове повідомлення користувача.

Таку саму перевірку з оболонки можна виконати для тіла запиту, збереженого у 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 hour точка збереження має time to live (TTL):

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

Також доступне автоматичне кешування: додайте одне поле cache_control на верхньому рівні запиту, після чого API керуватиме точками збереження в міру зростання розмови. Це поле використовує один із чотирьох доступних слотів точок збереження. Почніть із цього варіанта. Перейдіть до явних точок збереження, коли потрібно точно визначити межу.

Правило порядку, яке знижує частоту влучань у кеш

Кеш порівнює префікс побайтно від початку запиту, а запит формується у фіксованому порядку: інструменти, потім system, потім повідомлення. Зміна на будь-якому рівні інвалідовує цей рівень і все, що розташоване після нього. Якщо змінити опис одного інструмента, system prompt і вся історія повідомлень також інвалідовуються, навіть якщо ви їх не змінювали.

Це дає одне правило без винятків. Усе, що змінюється між викликами, має розташовуватися після всього, що не змінюється.

Зазвичай проблему спричиняє timestamp. Рядок Current time: 2026-08-03T14:07:11Z на початку system prompt гарантує частоту влучань 0 відсотків, оскільки хеш префікса відрізняється під час кожного виклику, і жоден попередній запис не може з ним збігтися. Перемістіть його в user message, у кінець. Ідентифікатор сесії або nonce для кожного запиту спричиняє таку саму проблему й потребує такого самого виправлення. Отримані документи, які відрізняються для кожного запиту, також мають розташовуватися після кешованого блоку. Інакше вони переміщують усі стабільні токени за межу, яка змінюється.

Друга проблема — встановлення точки розділення на блоці, який змінюється. Запис у кеш відбувається в точці розділення. Тому якщо цей блок щоразу відрізняється, стабільний вміст ніколи не зберігається, а під час пошуку враховуються лише записи, які попередні запити створили у власних змінних точках розділення. Розмістіть cache_control на останньому блоці, вміст якого однаковий у всіх запитах.

Третя проблема — зміна параметра, яку ви не вважаєте частиною вмісту prompt. Для іншої моделі використовується інший кеш. Зміна вибору інструмента інвалідовує вміст від рівня system і далі. Додавання або видалення інструмента інвалідовує все.

Мінімальна довжина префікса та непомітна відсутність дії

Префікс, коротший за мінімальну довжину моделі, не кешується, і система нічого про це не повідомляє. Немає ні помилки, ні попередження. Запит виконується успішно, а обидва лічильники показують 0. Станом на August 2026 опубліковані мінімальні значення такі:

• 512 токенів для Claude Opus 5 і Claude Fable 5
• 1,024 токени для Claude Sonnet 5 і Claude Opus 4.8
• 4,096 токенів для Claude Haiku 4.5

Якщо обидва лічильники показують 0 для запиту, який, на вашу думку, має використовувати кеш, спочатку перевірте довжину префікса. Саме тому найдешевша модель не обов’язково є найдешевшою для робочого навантаження з кешуванням. Для Claude Haiku 4.5 потрібен префікс у вісім разів довший, ніж для Claude Opus 5, щоб кешування взагалі активувалося. Тому системний промпт на 2,000 токенів кешується в одній моделі та непомітно ігнорується в іншій.

Де Claude Code кешує дані, а де кеш не допомагає

Claude Code кешує власний префікс. Системний prompt і визначення інструментів розташовані на початку кожного запиту та не змінюються, тому їх записують один раз, а потім зчитують протягом решти сесії. Саме тому вартість кожного наступного запиту в довгій сесії набагато нижча, ніж можна припустити за розміром контексту. Це відображається у лічильниках, описаних у як Claude Code показує використання токенів.

Кеш не допомагає, якщо змінюється фрагмент на початку контексту. Історія розмови доступна лише для додавання, тому звичайні нові запити розширюють префікс, який уже закешовано. Якщо змінити файл, прочитаний на початку сесії, вміст у середині цього префікса зміниться, і кожен токен після цієї зміни доведеться записати повторно. Тривала пауза бездіяльності дає такий самий результат, оскільки запис кешу стає недійсним, і наступний запит потребує повного запису. Це не помилка. В обох випадках правило префікса працює саме так, як визначено.

Якщо ви натомість пишете власний клієнт, застосуйте цю структуру вже в першому запиті, а не перебудовуйте її пізніше: сформуйте виклик так, як показано в першому застосунку Claude API на VPS, розмістивши стабільні блоки на початку, а змінні — в кінці.

Режими відмов і їхні ознаки

Кожен виклик є операцією запису. cache_creation_input_tokens має ненульове значення під час кожного запиту, а cache_read_input_tokens залишається рівним 0. Щось у точці зупинки або перед нею змінюється між викликами. Виведіть перші 200 символів зібраного префікса у двох послідовних запитах і порівняйте їх візуально.

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

Читання працює, а потім припиняється. Спочатку є серія влучань, потім запис, а після нього знову влучання. Інтервал між запитами перевищив час життя запису. Прийміть операцію запису або перейдіть на TTL 1 hour після того, як перевірите, що частка влучань перевищує 53 percent.

Частка влучань зменшується після розгортання. Було змінено опис інструмента або модель. Обидві зміни роблять увесь префікс недійсним. Після кожного розгортання, яке змінює prompt, очікуйте один дорогий цикл записів.

Рахунок збільшився після ввімкнення кешування. Ваша частка влучань нижча за поріг беззбитковості. За частки нижче приблизно 22 percent у кеші 5 minute надсилати префікс без кешування дешевше. Для кешу 1 hour це так само за частки нижче приблизно 53 percent.

FAQ

Скільки разів потрібно повторно використати промпт, щоб кешування стало вигідним?

Один раз для кешу на 5 хвилин. Запис коштує 1.25x базової вартості вхідних даних, а читання — 0.1x. Тому N запитів без кешу коштують N, тоді як N кешованих запитів коштують 1.25 плюс 0.1, помножене на N мінус 1. Точка перетину — N = 1.28, тому вже другий запит є вигіднішим. Для кешу на 1 годину запис коштує 2x, а точка перетину настає при N = 2.11, тому потрібні два читання.

Чому cache_read_input_tokens завжди дорівнює нулю?

Спочатку перевірте довжину префікса: якщо вона менша за мінімум для моделі — 512 токенів для Claude Opus 5 і 4,096 для Claude Haiku 4.5 станом на серпень 2026 року — кешування без повідомлення пропускається, а обидва лічильники мають значення 0. Якщо префікс достатньо довгий, перевірте, чи немає в точці розриву або перед нею вмісту, який змінюється між викликами, наприклад часової позначки або ідентифікатора сеансу в системному промпті. Якщо лічильники працювали, а потім перестали, проміжок між запитами перевищив час життя кешу.

Чи змінює кешування промптів відповіді Claude?

Ні. Кеш зберігає оброблену форму вже надісланих токенів, а модель в обох випадках отримує той самий промпт. Це функція для керування вартістю та затримкою, а не зміна поведінки. Тому її можна ввімкнути для робочого промпту без повторного запуску оцінювань.

Чи варто платити за кеш на 1 годину?

Лише якщо у вашому трафіку є перерви довші за 5 хвилин і частка влучань у кеш усе одно становитиме приблизно 53 відсотки або більше. Запис за 2x удвічі дорожчий у разі промаху, ніж запис за 1.25x. Запис у кеші на 5 хвилин оновлюється під час кожного влучання, тому стабільний трафік підтримує його активність за ціною читання, без оплати довшого часу життя.