Cache-стратегия Claude Pro: как я сэкономил 85% стоимости запросов

За 6 месяцев активной работы с Claude Code на Pro-подписке я научился осмысленно работать с моделью кэширования Claude. Цифры моих реальных сессий: 94% попаданий в кэш, экономия 85% стоимости запросов. Это не теория и не маркетинг — это данные, выгруженные из Anthropic Console.

На Pro-подписке вы не платите за каждый токен — у вас квота. Но эффективное использование кэша = квота растягивается в разы. Те же сессии при работе через API дали бы прямой эффект в счёте за месяц.

Этот пост — про то, что я понял про кэш Claude, какие ошибки сделал на старте, и как теперь выбираю модель и структурирую сессии.

Table of contents

Как работает кэш Claude (за одну минуту)

Anthropic предоставляет prompt caching: повторно используемые куски запроса (system prompt, ранние сообщения диалога, большие документы в контексте) помечаются как кэшируемые. Тогда:

• Cached read стоит 10% от обычной цены input-токена — то есть 90% скидка
• Cache write стоит +25% к обычной цене (для default ephemeral TTL 5 минут) или +100% (для 1-hour TTL beta)
• Кэш привязан к точному префиксу запроса. Если изменится один символ в начале — весь кэш ниже инвалидируется
• TTL: 5 минут (default) или 1 час (beta ephemeral_1h). Каждое попадание в кэш обновляет TTL
• Кэш — per-model. Кэш для Opus не знает про кэш для Sonnet, даже если запрос идентичный
• Минимум для кэширования: 1024 токена (Opus / Sonnet), 2048 (Haiku)

Это API-уровень. В Claude Code и Claude.ai кэш применяется автоматически — вам не нужно расставлять cache_control руками. Но поведение пользователя влияет на то, какая доля запросов реально попадает в кэш.

Что я наблюдаю на реальных сессиях

Мои сессии в Claude Code — длинные. От 30 минут до нескольких часов работы с одним проектом. Когда я выгрузил данные из Anthropic Console (там есть раздельная статистика cached input vs uncached input), получилось так:

• Cache hit rate: 94% — из каждых 100 input-токенов 94 поданы из кэша
• Экономия стоимости: ~85% (если бы платил по API) — потому что cache writes + uncached input всё равно стоят полную цену, а cached reads только 10%
• Соотношение write : read ≈ 1 : 15 — на каждый записанный в кэш блок я в среднем 15 раз его прочитал

Это работает потому что:

• Я не открываю новый чат на каждую задачу — продолжаю в существующем
• У меня большой system prompt (CLAUDE.md, библиотека сценариев, инструкции — это всё кэшируется)
• Я не переключаю модели в одной сессии
• Я работаю в одной модели достаточно долго, чтобы кэш окупился многократным чтением

Anti-pattern №1: model ping-pong

Самая дорогая ошибка из тех что я сделал на старте — переключение моделей в одной сессии.

Сценарий: пишу архитектурное решение на Opus, по ходу переключаюсь на Sonnet чтобы “быстро мелкие правки внести”, потом обратно на Opus.

Что происходит на уровне кэша:

1. Кэш Opus — отдельный, кэш Sonnet — отдельный
2. При переключении на Sonnet первый запрос требует прогрева кэша Sonnet с нуля — это cache write на весь system prompt и накопленный контекст
3. При возврате к Opus — если уложился в 5-минутный TTL, кэш Opus ещё живой; если нет — снова cache write на весь контекст

Цена одного такого переключения — примерно 50–100 тысяч токенов на cache write (зависит от размера контекста). Если ping-понг между моделями 5 раз за сессию — счёт легко уходит за 500к токенов только на повторные cache writes. На квоте Pro-подписки это превращается в “почему я так быстро упёрся в лимит сегодня”.

Правило: выбирайте модель один раз на сессию. Если осознанно нужна другая модель — открывайте новую сессию.

Anti-pattern №2: правки system prompt mid-session

Менее очевидная ловушка. Если в середине длинной сессии я редактирую CLAUDE.md, SOUL.md или другие identity-файлы, которые попадают в system prompt — следующий запрос обнаружит, что префикс изменился, и инвалидирует весь кэш ниже.

Эффект: на следующем сообщении — full cache write на новый system prompt + весь накопленный диалог. Снова 50–100к токенов в трубу.

Правило: правки в identity-файлы (CLAUDE.md и подобные) делайте между сессиями, не во время. Если правишь в процессе — будь готов к тому, что эта сессия только что стала дороже.

Decision matrix: какую модель в какой момент

Из своего опыта я вывел простое правило выбора модели — по downstream impact задачи, то есть насколько решение повлияет на дальнейшую работу.

Простой эвристический критерий: “Если задача — это if-условие или прямое сопоставление, это скрипт, а не промпт”. AI остаётся для задач, где нужно суждение или творчество.

Правильный вопрос — не “какая модель моя default”, а “имеет ли эта задача downstream impact”. Если да — Opus как инвестиция, не как трата. Если нет — Sonnet или Haiku, сохраняем квоту.

Subagents — отдельная кэш-территория

В Claude Code есть subagents (через Task tool) — возможность запустить параллельную сессию для конкретной задачи. Это полезно для:

• Файлов больше 300 строк (изолировать большой контекст от основной сессии)
• Параллельных исследований без захламления основного диалога
• Self-contained работы, которая не должна влиять на основную ветку

Что важно про кэш и subagents:

• Subagent не наследует кэш родителя — у него другой prefix (свой system prompt из агентного описания)
• Subagents одного типа делят кэш между собой — если в течение TTL запустить 5 subagent-ов одного типа, они переиспользуют кэш друг друга
• Anti-pattern: запускать subagent на Opus только потому что main session на Opus. Subagent — это новая сессия и новый cache write на 50–100к токенов. Если задача механическая — пусть подагент будет на Sonnet или Haiku

Ещё одна ловушка наследования: если main session работает на Opus, и вы не указали модель явно для subagent — он унаследует Opus. Так все subagents окажутся на самой дорогой модели. На квоте Pro это квота-leak ×15.

Правила для subagents:

1. Всегда явно указывайте модель subagent, не полагайтесь на наследование
2. Кластеризуйте subagent-ы одного типа во времени (одна “пачка”)
3. Параллельный запуск через одно сообщение лучше последовательного (потенциальная дедупликация cache write на стороне Anthropic)
4. Используйте subagent только когда задача требует больше 2 итераций — иначе overhead на cache write не окупится

Практический чек-лист

Перед началом сессии:

• Выбрал модель под задачу по downstream impact
• Если предполагается длинная работа — открыл новый чат, чтобы стартовать с чистой кэш-территории
• Identity-файлы (CLAUDE.md, skills) уже актуальны — не буду редактировать в процессе

Во время сессии:

• Не переключаю модели mid-session
• Не редактирую файлы, попадающие в system prompt
• Если задача “переключи контекст” — открываю новую сессию, не использую существующую

С subagents:

• Не использую subagent для задач меньше 2 итераций (overhead не окупится)
• Кластеризую subagent-ы одного типа
• Явно задаю модель subagent-у, не наследую от parent

С API напрямую:

• Большой и редко меняющийся контекст помечен cache_control
• Изменения в начале запроса минимизированы (все динамические части — в конце)
• Если знаю, что сессия будет длиннее 5 минут — рассматриваю ephemeral_1h

Заключение

Кэш-aware подход — это не “оптимизация ради оптимизации”. Это про то, что вы получаете в разы больше работы за ту же квоту или те же деньги. На Pro-подписке это означает что реже упираетесь в лимит. На API — десятки тысяч рублей экономии каждый месяц при активной работе.

Главное — это не “техника”, а дисциплина:

• выбрать модель один раз на сессию
• не дёргать identity-файлы посреди работы
• не использовать subagent-ы там, где это не нужно
• не открывать новый чат когда можно продолжить в старом

Кэш — это архитектурная фича, а не магия. Она работает на вас, если вы строите рабочий процесс осознанно. И против вас — если работаете “как привыкли”.

Если ваш Cache hit rate в Anthropic Console меньше 80% — есть что улучшить. Начните с двух правил выше (не переключать модели, не править identity-файлы) и проверьте метрики через неделю.