От редактора: Когда многие люди используют Claude Code, самое непосредственное впечатление — токены расходуются слишком быстро, длинные сессии легко "съедают" лимит. Но с точки зрения инженеров Anthropic, реальное влияние на стоимость оказывает не то, сколько кода вы написали, а то, насколько система постоянно повторно использует уже обработанный контекст.

Основная идея, которой делится эта статья, — как экономить токены с помощью механизма кэширования. Автор за неделю сэкономил более 300 миллионов токенов благодаря кэшированию, достигнув 91 миллиона в один день. Поскольку стоимость кэшированного токена составляет всего 10% от стоимости обычного входного токена, это означает, что 91 миллион кэшированных токенов фактически стоят примерно как 9 миллионов обычных токенов. Причина, по которой длинные сессии Claude Code кажутся более "выносливыми", не в том, что модель работает бесплатно, а в том, что большое количество повторяющегося контекста успешно переиспользуется.

Ключ к кэшированию промптов (prompt caching) — "не прерывать кэш". Claude Code кэширует системные подсказки, определения инструментов, CLAUDE.md, правила проекта и историю диалогов послойно; до тех пор, пока префикс последующих запросов остаётся неизменным, Claude может напрямую читать из кэша, а не обрабатывать весь контекст заново. Внутри Anthropic также отслеживают показатель повторного использования кэша промптов, поскольку это влияет не только на лимиты пользователей, но и напрямую на стоимость обслуживания модели и эффективность работы.

Обычным пользователям не нужно понимать все технические детали, достаточно усвоить несколько ключевых привычек: не оставлять сессию бездействующей более 1 часа; правильно выполнять "передачу сессии" (session handoff) при смене задачи; избегать частой смены моделей; большие документы по возможности помещать в Projects, а не постоянно вставлять их в диалог.

Эта статья — скорее не просто рассказ о технике экономии токенов, а предложение подхода к использованию Claude Code, более близкого к мышлению инженера: рассматривать контекст как актив, который нужно управлять, чтобы кэш постоянно переиспользовался, а длинные сессии выполняли меньше повторяющихся вычислений.

Ниже оригинальный текст:

На этой неделе я сэкономил 300 миллионов токенов, 91 миллион за день, за неделю — более 300 миллионов.

Я не менял никаких настроек. Это просто обычная работа промпт-кэширования в фоновом режиме.

Но когда я действительно понял, что такое кэш и как избежать его "сброса", при том же самом лимите использования мои сессии стали длиться дольше. Итак, вот краткое руководство 80/20 по промпт-кэшированию в Claude Code, без глубоких технических деталей уровня 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 повторно использует из кэша, например, ваш CLAUDE.md, определения инструментов, предыдущие сообщения и т.д. По сравнению с повторной обработкой как ввода, они дешевле в 10 раз.

Если у вас высокий показатель Cache read, значит, вы эффективно используете кэш; если этот показатель низкий, значит, вы платите за один и тот же контекст снова и снова.

У Тарика из Anthropic есть фраза, которая меня глубоко впечатлила: "Мы фактически отслеживаем процент попаданий в промпт-кэш (cache hit rate), и как только он становится слишком низким, срабатывает сигнал тревоги, даже объявляется инцидент уровня SEV."

Он также написал хорошую статью в X. Когда процент попаданий в кэш высок, происходят четыре вещи одновременно: Claude Code ощущается быстрее, стоимость обслуживания Anthropic снижается, ваша подписка кажется более "выносливой", а длинные сессии кодирования становятся более реальными.

Но если процент попаданий низкий, проигрывают все.

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

Как кэш увеличивается в каждом раунде диалога?

Кэширование зависит от префиксного совпадения (prefix matching).

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

Новая сессия обычно разворачивается примерно так:

Согласно документации Claude Code, новая сессия обычно работает так:

Первый раунд диалога: Кэша ещё нет. Системные промпты, контекст вашего проекта (например, CLAUDE.md, memory, правила), а также ваше первое сообщение обрабатываются заново и записываются в кэш.

Второй раунд диалога: Весь контент из первого раунда теперь закэширован. Claude нужно обработать только ваш новый ответ и следующее сообщение. Стоимость этого раунда будет намного ниже.

Третий раунд диалога: Логика та же. Предыдущий диалог по-прежнему хранится в кэше, только последний раунд взаимодействия нужно обработать заново.

Сам кэш можно разделить на три уровня:

Из статьи Тарика в X:

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

Проектный уровень (Project layer): Включает CLAUDE.md, memory, правила проекта. Этот уровень кэшируется по проектам.

Уровень диалога (Conversation): Включает ответы и сообщения, растёт с каждым раундом диалога.

Если в середине сессии что-либо на системном или проектном уровне изменяется, весь контент должен быть заново закэширован с самого начала. Это самая "дорогая" операция. Представьте: вы уже дошли до 16-го сообщения, и вдруг меняете системный промпт, или делаете перерыв на час, тогда все токены, начиная с первого сообщения, должны быть обработаны заново.

Путаница с 1 часом и 5 минутами

Это место, где легче всего запутаться.

Подписочная версия Claude Code: TTL по умолчанию — 1 час.

Claude 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% пользователей

Вот то, что я считаю по-настоящему полезным в повседневном использовании.

Не делайте слишком долгих перерывов

Если вы бездействовали более часа, предыдущий контент в основном уже "протух" в кэше. Ваше следующее сообщение будет заново строить кэш. В этом случае вместо того, чтобы возобновлять уже "остывшую" старую сессию, часто дешевле сделать чёткую передачу (handoff) и начать новую сессию.

При смене задачи — просто начните заново

/compact или /clear сами по себе сбрасывают кэш, так что лучше использовать этот момент для полного сброса.

Я сделал себе навык "session handoff skill" (навык передачи сессии) вместо /compact. Он подводит итог тому, что мы завершили, какие решения ещё в ожидании, какие файлы самые важные и с чего следует продолжить. Затем я выполняю /clear, вставляю это резюме и могу продолжать так, будто ничего не прерывалось.

Команда compact иногда тоже работает медленно. А этот handoff skill обычно выполняется меньше чем за минуту.

В чате Claude большие документы по возможности помещайте в Projects

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

Какие действия незаметно сбрасывают кэш?

Есть несколько вещей, которые полностью сбрасывают кэш без явного предупреждения.

Смена модели: Поскольку кэширование зависит от префиксного совпадения, а у каждой модели свой собственный кэш. Как только вы меняете модель, следующий запрос будет обрабатывать полную историю без каких-либо попаданий в кэш.

Режим "Opus plan": Эта настройка использует Opus на этапе планирования, а Sonnet — на этапе выполнения. Я рекомендовал её в некоторых видео по оптимизации токенов не просто так. Но важно понимать, что каждое переключение плана по сути является сменой модели, а значит, требует перестройки кэша. В долгосрочной перспективе это всё равно помогает продлить сессии, но вам нужно знать, что происходит на самом деле.

Редактирование CLAUDE.md в середине сессии возможно: Это изменение не вступит в силу немедленно, а будет применено при следующем перезапуске. Таким образом, текущий кэш не пострадает.

Моя панель управления "бесплатными" токенами

Скриншоты, которые я показывал ранее, взяты из токен-панели управления.

Это простой репозиторий на GitHub. Вы даёте ссылку Claude Code, чтобы он развернул его локально на localhost, и он будет читать все ваши прошлые записи сессий, а не начинать статистику с нуля. Сразу же вы увидите ежедневные данные по input, output, cache create и cache read.

Но есть один нюанс: эта панель управления считает данные по токенам на локальном устройстве. Если вы переключитесь с настольного ПК на ноутбук, цифры не будут полностью совпадать. У каждого устройства свой собственный набор статистики.

Итог

Промпт-кэширование — это тема, в которую можно глубоко погрузиться. В статье Тарика всё описано полнее, чем здесь, если хотите увидеть полную картину, стоит почитать.

Но вам не нужно полностью понимать все детали, чтобы извлечь выгоду. Достаточно усвоить ключевые 80/20: кэшированные токены в 10 раз дешевле обычных; TTL Claude Code — 1 час; смена модели сбрасывает кэш; чёткая передача между задачами обычно выгоднее, чем продолжение использования старой сессии после её "протухания".