Ти побудував агентний цикл. Тули викликаються, результати повертаються, модель міркує над наступним кроком — вся ця штука гуде як маленький автономний мозок. Потім ти відкриваєш Anthropic usage dashboard після дня тестування. Це число — не друкарська помилка. Це ціна перевідправки того самого системного промпту і схем тулів на кожній ітерації, за повну вартість, у stateless API, яке не пам'ятає, що ти надіслав три секунди тому.

А якщо ти оновився до Opus 4.7 16 квітня 2026 року — а ти напевно це зробив — Саймон Віллісон заміряв, що новий токенізатор генерує в 1.46 раза більше токенів для ідентичних системних промптів. Твої витрати виросли на 35-40% за одну ніч за буквально той самий текст. Аналіз Finout (27 квітня 2026) підтверджує цю закономірність на різних навантаженнях.

Чому "просто оптимізуй промпти" не рятує

Очевидна відповідь: зроби промпти коротшими. Ну ок, обріж зайве. Але в реальному агентному циклі твій статичний префікс — системний промпт, визначення тулів (схеми, що пояснюють моделі, які інструменти їй доступні та які параметри вони приймають), та накопичена історія діалогу — легко сягає 10 000+ токенів. Із 6 тулами та нормальним системним промптом ти дивишся на ~11 000 токенів ідентичного контенту, що перевідправляється кожний хід.

За 10 ітерацій це 110 000 токенів чистого повторення по $5/MTok на Opus 4.7. Це $0.55 тільки на вхідні дані — просто за байти, які сервер уже бачив. Масштабуй до 50 ходів і ти спалюєш долари на одну розмову.

Ніяке підстригання промптів не виправить фундаментально stateless протокол. Тобі потрібно, щоб сервер запам'ятовував.

Рішення: prompt caching

Anthropicʼівський API prompt caching (GA з 17 грудня 2024) дозволяє тегувати блоки повідомлень маркером cache_control — точкою зупинки, що каже серверу "збережи все до цього місця". На наступних запитах, якщо байти збігаються точно, сервер читає з кешу і бере з тебе 10% від звичайної ціни за input. Згідно з документацією Anthropic, 5-хвилинний кеш (за замовчуванням) коштує 1.25x на початковий запис; 1-годинний кеш — 2x.

Математика проста: заплати 25% премії один раз, отримай 90% знижки на кожне наступне звернення. У циклі з 10 ходів це 1 запис + 9 читань. Він окупається вже після першого кеш-хіта.

Крок 1: Закешуй системний промпт

Системний промпт — це найстабільніший контент у твоєму циклі. Він не змінюється між ітераціями. Зроби його кешованим:

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    system=[{
        "type": "text",
        "text": "Your long system prompt with instructions...",
        "cache_control": {"type": "ephemeral"},  # 5-min TTL
    }],
    messages=[...],
)

Ключовий нюанс: на Opus 4.7 (а також Opus 4.5, Haiku 4.5) мінімальний кешований блок — 4 096 токенів. Якщо твій системний промпт коротший, Anthropic мовчки ігнорує маркер cache_control — без помилки, без кешу, просто витрачений намір. На Sonnet мінімум — 1 024 токени.

/faion — це загальний навичковий модуль faion-network, який підтягує релевантну методологію з 12 спеціалізованих доменів у розмову, тому перш ніж проєктувати стратегію кешування, запитай його:

/faion
I'm implementing Anthropic prompt caching for a multi-tool agentic loop.
What's the best strategy for placing cache_control breakpoints when I have
a system prompt, 6 tool schemas, and growing conversation history?

Крок 2: Закешуй визначення тулів

Схеми тулів — JSON-описи назви, параметрів та призначення кожного інструменту — сидять у масиві tools і обробляються перед системним промптом у ієрархії кешу. Постав cache_control на останній тул у масиві, щоб закешувати їх усі однією точкою зупинки:

tools = [
    {"name": "search_web", "description": "...", "input_schema": {...}},
    {"name": "read_file", "description": "...", "input_schema": {...}},
    {"name": "run_code", "description": "...", "input_schema": {...}},
    {"name": "write_file", "description": "...", "input_schema": {...}},
    {"name": "list_dir", "description": "...", "input_schema": {...}},
    {"name": "submit_result", "description": "...", "input_schema": {...},
     "cache_control": {"type": "ephemeral"}},  # caches ALL tools above
]

Критичне правило: ієрархія кешу — tools → system → messages. Зміна будь-якого визначення тула між ітераціями (додавання тула, перейменування параметра) інвалідує кеш для тулів, системного промпту ТА повідомлень. В агентному циклі тримай набір тулів замороженим.

Крок 3: Закешуй префікс історії розмови

Коли діалог росте, старіші повідомлення стають статичними — вони більше не зміняться. Постав точку зупинки на останньому повідомленні "стабільної" частини:

messages = [
    {"role": "user", "content": "Initial task..."},
    {"role": "assistant", "content": "I'll start by..."},
    {"role": "user", "content": [{  # last stable message
        "type": "text",
        "text": "Tool result from step 3...",
        "cache_control": {"type": "ephemeral"},
    }]},
    {"role": "assistant", "content": "Now processing..."},  # new, uncached
]

Тепер у тебе 3 точки зупинки (тули, система, історія). API дозволяє максимум 4. Збережи останній слот на крайні випадки.

Крок 4: Трюк із переміщенням

Цей прийом від команди ProjectDiscovery, які опублікували свої результати 10 квітня 2026. Вони запускають 26-кроковий агентний сканер безпеки з 40 викликами тулів. Їхній початковий cache hit rate був жалюгідні 7%.

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

Рішення: вони перемістили весь динамічний контент з системного промпту в повідомлення з роллю user наприкінці розмови. Системний промпт став побайтово ідентичним між викликами. Їхній cache hit rate стрибнув з 7% до 74% за одну ніч, а з подальшим тюнінгом дійшов до 84% — зниження витрат на 70%.

/faion
How should I separate static vs. dynamic content in an agentic system
prompt to maximize cache hit rates? What patterns exist for the
static-system-prompt + dynamic-user-reminder split?

Крок 5: Перевір, що воно справді працює

Кеш-хіти невидимі, поки не подивишся. Більшість SDK-обгорток і фреймворків логування не показують метрики кешу. Потрібно перевіряти явно:

usage = response.usage
print(f"Cache written: {usage.cache_creation_input_tokens}")
print(f"Cache read:    {usage.cache_read_input_tokens}")
print(f"Uncached:      {usage.input_tokens}")

hit_rate = usage.cache_read_input_tokens / (
    usage.cache_read_input_tokens +
    usage.cache_creation_input_tokens +
    usage.input_tokens
) * 100
print(f"Cache hit rate: {hit_rate:.1f}%")

На другій ітерації циклу cache_read_input_tokens має бути великим. Якщо він нуль — щось інвалідує кеш. Шукай побайтові розбіжності у своєму "статичному" контенті.

Підводні камені, що коштуватимуть тобі грошей

1. 5-хвилинний обрив. TTL за замовчуванням (time-to-live — скільки сервер пам'ятає твій закешований контент) — 5 хвилин. Якщо виклик тула займає 6 хвилин (таймаут зовнішнього API, довгі обчислення), кеш протухає. Ти знову платиш премію за запис. Рішення: використовуй "ttl": "1h" для повільних воркфлоу, але знай, що запис коштує 2x замість 1.25x. І довші TTL повинні йти перед коротшими в запиті — інакше отримаєш помилку.

2. Порядок ключів у JSON. Деякі мови рандомізують порядок ключів при серіалізації. Інший порядок ключів = інші байти = cache miss. Зафіксуй порядок серіалізації або використовуй sort_keys=True.

3. Lookback на 20 блоків. Система шукає закешовані записи максимум у 20 блоках контенту назад. У довгих розмовах (>20 блоків) старі точки зупинки випадають за межі вікна пошуку. Додавай свіжі breakpoints кожні ~18 блоків. Дослідження PwC від січня 2026 року виявило, що саме тут виникає більшість "загадкових cache miss'ів".

4. Кешування короткого контенту коштує дорожче. PwC заміряли, що промпти менше 500 токенів дають на 10-18% гіршу затримку через накладні витрати кешування. Не кешуй свій 200-токеновий системний промпт. Він і так має подолати мінімум у 4 096 токенів на Opus.

Що робити прямо зараз

У тебе три точки зупинки — тули, система, префікс історії — і один патерн моніторингу. Той самий агентний цикл, що спалював $0.55 за 10-ходову розмову на Opus 4.7, тепер коштує ~$0.12. Це не похибка округлення — це різниця між прототипом, який ти демонструєш один раз, і системою, яку ти реально випускаєш. 35% податок токенізатора від Opus 4.7? Все ще там, але ти платиш його один раз на кеш-запис, а не кожний хід. Ласкаво просимо в ту частину, де сторінка білінгу перестає лякати.