Claude Code Поради щодо економії коштів: інженери за тиждень заощадили 300 мільйонів токенів завдяки кешуванню, ключ у тому, щоб не переривати

Код Claude довгий діалоговий ліміт? Інженер Nate Herk розкриває, що за тиждень за допомогою кешування зекономив 3 мільярди токенів, максимум за день — 91 мільйон. Ключ не в тому, скільки коду написано, а в тому, як не «перервати» кеш, щоб повторне використання контексту більше не коштувало додаткових витрат.
(Попередній огляд: проект badclaude з відкритим кодом для прискорення Claude code, який був отриманий повідомленням про порушення авторських прав від Anthropic)
(Додатковий фон: у Claude Code додано функцію планових завдань у хмарі! Не потрібно включати комп’ютер, AI автоматично перевіряє PR, оновлює)

Зміст статті

Перемикач

• Вартість кешування становить лише 10%, 9100 тисяч токенів — це 900 тисяч
• Тришарова архітектура: система, проект, діалог, шарами накладаються
• Найпоширеніша пастка «розриву»: перемикання моделі та вікно у 1 годину
• Саморобна панель інструментів інженера: перегляд Cache Read та Create
• Практичний підхід: Session Handoff економить більше, ніж /compact

Багато розробників, використовуючи Claude Code для написання коду, найголовніша проблема — швидке вичерпання ліміту токенів у довгих діалогах, майже як розкіш.

Але інфлюенсер у спільноті, Nate Herk, який часто ділиться порадами щодо AI у соцмережах, у твіті @X розкрив, що справжній фактор витрат — не кількість коду, а ефективність системи у використанні prompt caching. За тиждень він зекономив понад 3 мільярди токенів, максимум за день — 91 мільйон: оскільки вартість кешованих токенів лише 10% від звичайних, то за підрахунками, за день витрачається лише близько 900 тисяч токенів, що майже «безкоштовно» подовжує життєвий цикл діалогів.

Цього тижня я зекономив 3 мільярди токенів, за день — 91 мільйон, за тиждень — понад 3 мільярди.

Я не змінював налаштувань. Це просто нормальна робота prompt caching у фоновому режимі.

Але коли я зрозумів, що таке кеш і як уникнути його «розриву», при однаковому ліміті використання мої сесії могли тривати довше. Тому тут зібрав короткий 80/20 гайд по prompt caching для Claude Code, без глибоких технічних деталей API.

Вартість токенів кешу — лише 10% від звичайних токенів. 9100 тисяч кешованих токенів — це фактично близько 900 тисяч оброблених токенів.

Підписка Claude Code має TTL кешу 1 година; за замовчуванням API — 5 хвилин; суб-агенти — завжди 5 хвилин.

Кешування має три рівні: системний, проектний, діалоговий.

Перемикання моделі посередині розмови руйнує кеш, включно з режимом «opus plan».

coding agents need glass boxes now

jianshuo/ccglass

111 зірок на github
створено вчора
mit + javascript
локальний проксі + веб-панель для claude code, codex, deepseek-tui, і kimi
показує повний системний промпт, схеми інструментів, історію повідомлень, токени/кошти/вартість, і… фото.twitter.com/Wot5SFV16N

— Beau Johnson (@BeauJohnson89) 24 травня 2026

Вартість кешу — лише 10%, 9100 тисяч токенів — це 900 тисяч

Кожен кешований токен коштує 10% від звичайного.
Тому, коли моя панель показує, що у певний день було 9100 тисяч токенів у кеші, фактично платіж — приблизно за 900 тисяч токенів. Це пояснює, чому при довготривалому використанні Claude Code здається, що діалоги майже «безкоштовні» і можна їх подовжувати.

На панелі є два важливих числа:

Cache create: одноразові витрати на запис у кеш. Вони починають діяти у наступній сесії.
Cache read: токени, які Claude повторно використовує з кешу, наприклад, ваш CLAUDE.md, визначення інструментів, попередні повідомлення. Вони коштують у 10 разів менше, ніж обробка нових вхідних даних.

Якщо число Cache read високі — це означає, що ви ефективно використовуєте кеш; якщо низькі — ви платите за одні й ті ж контексти кілька разів.

Thariq з Anthropic сказав дуже важливу фразу: «Ми фактично моніторимо рівень попадань у кеш prompt, і якщо він низький, запускаємо попередження або навіть оголошуємо аварійну ситуацію SEV.»

Він також написав хорошу статтю у X. Коли рівень попадань у кеш високий, відбувається чотири речі: Claude Code працює швидше, зменшуються витрати Anthropic, ваш ліміт стає більш довговічним, і довгі сесії кодування стають реальністю.

Але якщо рівень попадань низький — всі програють.

Три рівні архітектури: система, проект, діалог — шарами накладаються

Тому, мотивація обох сторін — однакова: Anthropic прагне підвищити рівень попадань у кеш, а ви — теж. Єдине, що може гальмувати — це кілька дрібних звичок, які, здавалося б, незначні, але тихо руйнують кеш.

Кеш базується на prefix matching, тобто «пошуку за префіксом».

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

Загалом, новий діалог починається так:

Згідно з файлами Claude Code, новий діалог зазвичай виконується так:

Перша репліка: ще немає кешу. системний промпт, контекст проекту (наприклад, CLAUDE.md, пам’ять, правила), і перше повідомлення обробляються заново і записуються у кеш.

Другий раунд: все, що було у першому — вже у кеші. Claude обробля лише нову відповідь і наступне повідомлення. Вартість цього раунду значно нижча.

Третій раунд: аналогічно. попередні повідомлення залишаються у кеші, обробляється лише остання репліка.

Найпоширеніша пастка «розриву»: перемикання моделі та вікно у 1 годину

Кеш має три рівні:

Згідно з статтею Thariq:

Системний рівень (System layer): включає базові команди, визначення інструментів (read, write, bash, grep, glob) і стиль виводу. Це глобальний кеш.

Проектний рівень (Project layer): включає CLAUDE.md, пам’ять, правила проекту. Це кеш для конкретного проекту.

Діалоговий рівень (Conversation): включає відповіді і повідомлення, що зростають з кожним раундом.

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

Це найчастіша причина неправильного розуміння.

Підписка Claude Code: TTL за замовчуванням — 1 година.

Саморобна панель інструментів: перегляд Cache Read і Create

API Claude: TTL за замовчуванням — 5 хвилин. Можна платити більше і підвищити до 1 години.
Для будь-якого плану суб-агент: завжди 5 хвилин.

Веб-чат на Claude.ai: офіційно не має чіткої документації. Можливо, так само, як і підписка, але я ще не перевіряв.

Кілька місяців тому багато хто скаржився, що ліміт швидко вичерпується. Тоді хтось думав, що Anthropic таємно зменшив TTL з 1 години до 5 хвилин без повідомлення. Але це не так — TTL для Claude Code залишається 1 година.

Проблема у тому, що файли для Claude Code і API зберігаються окремо, і це спричиняє плутанину.

Якщо ви виконуєте багато workflow через Sub-agent або безпосередньо через API — 5 хвилин важливі. Але для 95% користувачів Claude Code важливіше — саме 1-годинний віконний період.

Ось кілька порад, що справді корисні у щоденному використанні:

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

Команди /compact або /clear автоматично руйнують кеш, тому краще зробити це свідомо і знову збудувати кеш.

Практичний підхід: Session Handoff економить більше, ніж /compact

Я створив власний навик — Session Handoff, щоб замінити /compact. Він підсумовує, що вже зроблено, що ще потрібно зробити, які файли найважливіші і з чого продовжити. Потім я викликаю /clear і вставляю цей підсумок — і можу продовжувати без перерв.

Команда /compact іноді працює повільно. Цей навик зазвичай виконується менш ніж за хвилину.

Механізм кешування на Claude.ai не має офіційної детальної документації, але проєкти явно використовують інші оптимізації. Тому, якщо потрібно вставити великі файли — краще додавати їх у проект, а не безпосередньо у діалог.

Декілька ситуацій, що без попередження повністю перезапускають кеш:

Перемикання моделі: оскільки кеш залежить від префіксного співпадіння, і кожна модель має свій кеш. Переключення моделі — і наступний запит починається без кешу, зчитуючи історію заново.
Режим «Opus plan»: цей режим використовує Opus під час планування і Sonnet під час виконання. Я раніше рекомендував його у відео про оптимізацію токенів — і не дарма. Але потрібно розуміти: кожне перемикання плану — це фактично перемикання моделі, і кеш потрібно оновлювати. Це довгостроково допомагає подовжити сесію, але важливо знати, що саме відбувається під капотом.

Редагування CLAUDE.md під час сесії можливо — зміни не застосовуються миттєво, а тільки при перезапуску. Тому поточний кеш не змінюється.

На скріншоті — панель з даними по токенах.

https://github.com/nateherkai/token-dashboard
Це дуже простий репозиторій на GitHub. Ви даєте посилання Claude Code, і він у локальній системі на localhost виконує деплой, читає всі ваші попередні сесії, а не починає з чистого стану. Ви одразу бачите дані по input, output, cache create і cache read за кожен день.

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

Prompt caching — дуже глибока тема. Стаття Thariq описує її ще детальніше. Якщо хочете побачити повну картину — варто почитати.

Але вам не потрібно знати всі деталі, щоб отримати користь. Достатньо засвоїти найважливіше 80/20: кеш токенів у 10 разів дешевший за звичайний; TTL для Claude Code — 1 година; перемикання моделі руйнує кеш; і чіткий перехід між задачами — зазвичай дешевше, ніж чекати, поки старий діалог «застигне» і його доведеться знову запускати.