Головна › Гайди по екосистемі Claude

Prompt caching у Claude: повторне використання стабільного префікса

Prompt caching зберігає великий стабільний префікс вашого prompt — довгий system prompt, великий документ, фіксований перелік інструментів — щоб повторні запити до Claude використовували його, а не платили за обробку тих самих токенів.

Востаннє переглянуто: 2026-09-04 · In English

Що саме кешує prompt caching

Кожен запит до Claude обробляється з першого байта: модель прочитує весь prompt, перш ніж згенерувати бодай один токен відповіді. Коли велика частина цього prompt однакова в багатьох запитах — розгорнутий system prompt, довідковий документ, фіксований набір прикладів — ви платите за обробку одного й того самого тексту знову і знову. Prompt caching дозволяє API зберегти вже оброблений префікс і повторно його використати, тож повторні запити пропускають цю роботу.

Ви позначаєте точку в prompt як межу кешу (cache breakpoint). API тримає знімок усього до цієї точки. Наступний запит, який починається з тих самих байтів, читає збережений стан замість того, щоб рахувати його заново. Кешовані вхідні токени коштують малу частку від звичайних — приблизно на порядок дешевше — і повертаються швидше, бо дорогий етап prefill здебільшого оминається.

Стабільне — на початок, змінне — у кінець

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

Це диктує компонування prompt. Розмістіть незмінні частини вгорі, а те, що змінюється щоразу — часову мітку, поточне питання користувача, знайдені під запит фрагменти — покладіть униз, після межі кешу. Упорядкуйте prompt від найстабільнішого до найзмінливішого, і кеш лишатиметься теплим. Добрі кандидати на кешований префікс:

• Довгий, багаторазовий system prompt або опис ролі
• Великий документ чи база знань, за якою відповідає модель
• Фіксований набір few-shot прикладів
• Довгий перелік визначень інструментів

Коли кеш окупається, а коли ні

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

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

Короткий час життя і як підтвердити влучання

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

Ніколи не припускайте, що кеш працює; вимірюйте. Відповідь містить статистику токенів, яка окремо показує читання з кешу й свіжо оброблений вхід. Слідкуйте за лічильником cache-read: якщо він росте на ваших повторних запитах, префікс збігається. Якщо лишається на нулі — щось у префіксі змінюється між викликами (рухома часова мітка, переставлене поле, різниця в пробілах), і ви щоразу платите повну ціну.

Типові пастки

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

Кеш також не змінює того, що модель знає чи як вона міркує — це суто оптимізація вартості й затримки для тексту, який модель і так прочитала б. Він лежить під retrieval, tool use та extended thinking, а не конкурує з ними. А оскільки записи швидко спливають, ендпоінт із низьким трафіком може так і не отримати другого влучання до зникнення кешу — тож перевіряйте на реальному трафіку, а не одним тестовим викликом.

Часті запитання

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

Ні. Він лише зберігає й повторно використовує вже оброблений префікс, щоб заощадити час і кошти; модель бачить ті самі токени й дає такий самий результат, як і без кешу.

Як зрозуміти, що prompt caching працює?

Подивіться на статистику токенів у відповіді — вона окремо показує cache-read токени. Зростання лічильника на повторних запитах означає, що префікс збігся; стійкий нуль — що щось у префіксі змінилося між викликами.

Чому мій кеш постійно промахується?

Майже завжди тому, що змінний вміст стоїть усередині кешованого префікса. Рухома часова мітка, ідентифікатор користувача чи переставлене поле перед межею руйнують збіг — тримайте все над межею побайтово однаковим.

Далі в цьому треку