За тиждень економія 300 мільйонів токенів, посібник з кешування коду Claude інженерів Anthropic

Оригінальна назва: Як інженери Anthropic насправді економлять токени
Автор оригіналу: Nate Herk
Переклад: Peggy, BlockBeats

Автор оригіналу:律动BlockBeats

Джерело оригіналу:

Перепублікація: Mars Finance

Редакторський коментар: Багато хто при використанні Claude Code найінтуїтивніше відчуває, що витрати токенів занадто швидкі, а довгі сесії легко з’їдають ліміт. Але з точки зору інженерів Anthropic, справжнім чинником, що впливає на вартість, зазвичай є не кількість написаного коду, а чи системи постійно переиспользують вже оброблений контекст.

Основна ідея цієї статті — як за допомогою кешування економити токени. Автор за тиждень переиспользував понад 300 мільйонів токенів через кешування, а щоденний обсяг кешу досягав 91 мільйон. Оскільки вартість кешованих токенів становить лише 10% від звичайних вхідних токенів, це означає, що 91 мільйон кешованих токенів фактично коштує приблизно 9 мільйонів звичайних токенів. Довгі сесії Claude Code здаються більш «стійкими» не тому, що модель працює безкоштовно, а тому, що багато повторюваного контексту успішно переиспользується.

Ключ до Prompt caching — «не переривати кешування». Claude Code кешує системні підказки, визначення інструментів, CLAUDE.md, правила проекту та історію діалогів у шарах; якщо префікс запиту згодом залишається однаковим, Claude може безпосередньо читати кеш, а не переробляти весь контекст знову. Внутрішньо в Anthropic також контролюють рівень переиспользування prompt cache, оскільки це впливає не лише на ліміт користувача, а й безпосередньо на вартість обслуговування моделі та її продуктивність.

Для звичайних користувачів не потрібно розбиратися у всіх технічних деталях, достатньо засвоїти кілька ключових правил: не залишайте сесію без активності більше ніж на 1 годину; при переключенні завдань виконуйте передачу сесії; уникайте частих перемикань моделей; великі документи краще зберігати у Projects, а не вставляти їх повторно у діалог.

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

Нижче наведено оригінал:

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

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

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

TL;DR

Вартість кешованих токенів становить лише 10% від звичайних вхідних токенів. 91 мільйон кешованих токенів фактично коштує приблизно 9 мільйонів токенів.

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

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

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

Як рахується вартість кешування?

Кожен кешований токен коштує 10% від звичайного вхідного.

Тому, коли на панелі показано, що у певний день було використано 91 мільйон токенів із кешу, фактично оплата приблизно відповідає обробці 9 мільйонів токенів. Це пояснює, чому при довгому використанні Claude Code здається, що сесія майже «безкоштовна» і триває довше.

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

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

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

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

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

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

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

Як кешування зростає у кожному раунді діалогу?

Кеш залежить від префіксного співпадіння, тобто «переднього співпадіння».

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

Як працює новий діалог?

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

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

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

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

Кеш можна поділити на три рівні:

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

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

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

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

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

Мікс між 1 годиною і 5 хвилинами

Це найпоширеніша плутанина.

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

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

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

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

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

Три звички для покриття 95% користувачів

Ось ті, що я вважаю дійсно корисними у щоденному використанні:

Не залишайте сесію без активності понад годину

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

При переключенні завдань одразу перезапускайте

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

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

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

У довгих документах у Claude краще зберігати їх у Projects

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

Що може несподівано зруйнувати кеш?

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

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

Мій безкоштовний дашборд токенів

Знімки, які я показував раніше, — це з дашборду токенів.

Це простий репозиторій на GitHub. Ви даєте посилання Claude Code, і він налаштовує локальний сервер, що зчитує всі ваші попередні сесії, а не починає з нуля. Ви одразу бачите щоденні дані про input, output, cache create і cache read.

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

Підсумки

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

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

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 5
  • Репост
  • Поділіться
Прокоментувати
Додати коментар
Додати коментар
GateUser-0fdb3438
· 8год тому
Кешування +1, наступного разу при проектуванні архітектури потрібно добре спланувати життєвий цикл контексту
Переглянути оригіналвідповісти на0
BudgetDeFi
· 11год тому
Кешування повторного використання — це справжня майстерність зниження витрат, 300 мільйонів токенів економії вистачить на скільки завгодно раундів тестування.
Переглянути оригіналвідповісти на0
0xPeachy
· 11год тому
Хочу знати, скільки з цих 300 мільйонів — це повторювані фрагменти коду, здається, рівень повторного використання коду в проекті має бути дуже високим
Переглянути оригіналвідповісти на0
DrawTheCandlestickChartIn
· 11год тому
Користувач Claude Code у захваті, нарешті дізнався, куди зникли ліміти
Переглянути оригіналвідповісти на0
GateUser-83c80dd0
· 11год тому
9100万 одноденний обсяг кешування, наскільки високий має бути цей показник? Цікаво, які деталі їхньої стратегії кешування
Переглянути оригіналвідповісти на0
  • Закріплено