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

Ціна prompt caching до того, як він почне економити

Prompt caching дає змогу Claude повторно використовувати початок prompt замість того, щоб читати його під час кожного виклику. Уся оцінка зводиться до двох множників базової ціни input для вашої моделі. Станом на August 2026 запис у cache коштує 1.25x базової ціни input для lifetime 5 minutes або 2x для lifetime 1 hour. Читання з cache коштує 0.1x. Ці множники однакові для всього списку моделей, тому наведена нижче точка беззбитковості не змінюється, коли змінюється ціна за token.

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

Беззбитковість в одному рядку алгебри

Позначимо через 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 з кешуванням на 5 хвилин.

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

Ціна низького cache hit rate

Реальний трафік містить промахи. Запит, який не знайшов дані в cache, але все ще містить breakpoint, оплачується як write. Тому коректно моделювати вартість як функцію hit rate. На наведеній нижче діаграмі це показано для 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"
  }
]

За hit rate 0 відсотків ви платите $125.00 замість $100.00, а cache на 1 hour подвоює рахунок до $200.00. Розв’язок рівняння 1.25 мінус 1.15h = 1 показує, що cache на 5 minutes починає заощаджувати кошти за hit rate приблизно 22 відсотки. Тому за 25 відсотків уже відображається $96.25. Аналогічний розрахунок для write із коефіцієнтом 2 дає приблизно 53 відсотки для cache на 1 hour. Тому за hit rate 50 відсотків вартість усе ще становить $105.00, тобто перевищує рівень без cache. За 90 відсотків значення становлять $21.50 і $29.00. За 99 відсотків короткостроковий cache досягає $11.15, що близько до мінімальної вартості, яка становить одну десяту ціни без cache.

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

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

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

Системний промпт із простим токеном 2,000 заощаджує $7.85 на 1,000 запитів порівняно з $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 (application programming interface) містить кількість токенів, записаних у кеш, кількість токенів, прочитаних із кешу, і кількість нових токенів, які потрібно було обробити.

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 не має безкоштовного тарифу, хоча для префікса на 20,000 токенів зазначена вище пара коштує приблизно чотирнадцять центів.

Таку саму перевірку можна виконати з shell для тіла запиту, збереженого у 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 керує точками переривання в міру зростання розмови. Це поле використовує один із чотирьох доступних слотів точок переривання. Почніть із цього варіанта. Перейдіть до явних точок переривання, коли потрібно точно визначити межу.

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

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

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

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

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

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

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

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

Скільки разів потрібно повторно використати prompt, щоб caching окупився?

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

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

Спочатку перевірте довжину prefix: якщо вона менша за мінімум моделі — 512 tokens для Claude Opus 5 і 4,096 для Claude Haiku 4.5 станом на August 2026, caching мовчки пропускається, а обидва лічильники мають значення 0. Якщо prefix достатньо довгий, перевірте, чи немає вмісту, який змінюється між викликами та розташований на або перед breakpoint, наприклад timestamp або session identifier у system prompt. Якщо лічильники працювали, а потім перестали, проміжок між запитами був довшим за cache lifetime.

Чи змінює prompt caching відповіді Claude?

Ні. Cache зберігає оброблену форму tokens, які ви вже надіслали, а model в обох випадках отримує той самий prompt. Це функція для billing і зменшення latency, а не зміна поведінки. Тому caching можна ввімкнути для prompt, який уже працює, без повторного запуску evaluations.

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

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