Промах кэша на Opus 5.5 стоит до 40 раз дороже попадания

Автор блога Dgrcode в разборе от 13 октября посчитал, во что обходится промах кэша промптов на Opus 5.5. Он сравнил два способа этого избежать: держать кэш живым через /loop или сжимать контекст через /compact.

Механика устроена так. Харнесс, в нашем случае Claude Code, на каждом ходу заново отправляет весь контекст: системный промпт, AGENTS.md, навыки и всю переписку. Модель не обрабатывает его с нуля. Она берёт из кэша сохранённый промежуточный результат (KV-представление, внутренние вычисления по уже прочитанному тексту) и досчитывает только новое. Claude Code по умолчанию хранит кэш час после последней записи или чтения. Потом запись удаляется, и следующее сообщение обрабатывает весь контекст заново. В документации Claude Code есть ещё две детали. Совпадение ищется по началу запроса и должно быть точным: правка в любом месте префикса пересчитывает всё, что идёт после неё. И у каждой модели свой кэш, так что при переключении модели запрос считается заново, даже если текст не изменился.

Opus 5.5 стоит 4 доллара за миллион входных токенов, а чтение из кэша стоит 0,20 доллара, в 20 раз дешевле. Запись в кэш на час обходится вдвое дороже обычного входа. Отсюда разница между попаданием и промахом до 40 раз. Если вы пишете свой харнесс поверх API, учтите: с 6 марта кэш без явно указанного ttl живёт пять минут, и часовое хранение нужно задавать в точке кэширования явно.

Пример автора: сессия с контекстом 300k токенов и новое сообщение на 1k. При попадании 300k читаются из кэша по 1/20 цены, а 1k пишется по двойной, итого 17k базовых входных токенов. При промахе все 301k пишутся в кэш по двойной цене, это 602k, больше чем в 35 раз дороже. В общем виде отношение равно 40(P+N)/(P+40N), где P - накопленный контекст, а N - новое сообщение. Чем больше контекст и короче сообщение, тем ближе разница к 40 разам.

Петля за копейки

Первый способ - не дать кэшу истечь. Достаточно до конца часа отправить что-нибудь вроде «wait, I'm still working on this». В сообщении около 10 токенов, но в кэш при этом пишется больше 100: вместе с ним уходят предыдущий ответ модели и служебные метки ролей. Даже при контексте 100k такое сообщение обходится в 38,5 раза дешевле промаха. Асимметрию автор формулирует так: первый час кэша стоит двойную цену контекста, а каждое попадание продлевает его ещё на час всего за 0,05. При идеальной автоматизации два часа обходятся в 2,05, три часа в 2,1.

Автоматизирует это команда /loop, которая шлёт сообщение по расписанию. Примерно 40 таких отправок стоят столько же, сколько один промах. Правда, «каждые 50 минут» в синтаксисе cron не запишешь, поэтому автор ставит запуск на :00 и :30, и 40 итераций растягиваются на 20 часов.

Сколько стоит /compact

Второй способ - /compact, который сворачивает разговор в сводку. Инструкция на сжатие в Claude Code занимает около 2k токенов, а весь контекст при этом читается из кэша: на сессии в 300k это 19k базовых токенов. Дороже всего обходится сводка. Её Claude пишет на выходе, а выходные токены у Opus 5.5 стоят в пять раз дороже входных. Сводка обычно меньше 30k токенов, но и это эквивалент 150k базовых.

Первое сообщение после сжатия записывает в кэш сводку, системный промпт с инструментами (в примере ещё 30k, но это сильно зависит от настройки, проверить можно через /context) и само сообщение, итого 122k. Всё сжатие стоит 291k, примерно половину промаха, но несравнимо больше 17k при попадании. Окупается оно потом: каждое следующее сообщение читает из кэша около 60k вместо 300k и стоит около 5k вместо 17k.

Когда что выбирать

Автор свёл всё в правило: сжимать при большом контексте или долгой паузе, иначе гонять петлю. Большим он считает контекст около 600k токенов, долгой паузу от 8 часов. Подробная схема проверяется сверху вниз:

• контекст меньше 100k: пусть кэш истекает, вы всё усложняете;
• контекст больше 600k: сжимать, скоро всё равно придётся;
• пауза до 2 часов: петля;
• пауза от 16 часов: сжимать;
• пауза 8-16 часов: сжимать при контексте больше 200k, иначе петля;
• контекст меньше 300k: петля;
• пауза от 4 часов: сжимать.

Паузу в 2-4 часа автор считает серой зоной. Если в этой сессии предстоит ещё много работы, скорее стоит сжать, а если до конца задачи осталась пара промптов, лучше петля. Против сжатия у него и другой довод: часть контекста, которая потом понадобится, может не попасть в сводку. Переход от 800k к 30k означает сжатие больше чем в 26 раз. Исследования сжатия промптов, на которые ссылается автор, называют оптимумом 10-20 раз, а заметное падение качества фиксируют около 25. Правда, там сжимают сам промпт, а не пересказывают его. Автор при этом ожидает, что с ростом моделей сводки будут лучше.

Claude Code сжимает сам

Пока автор писал разбор, Claude Code сжал его контекст в простое и сообщил: «Compacted while idle, before the prompt cache expired». Контекст перед этим занимал 220,3k токенов, а отсутствовал автор чуть больше часа. По его словам, Anthropic, похоже, тоже считает промах кэша серьёзной проблемой, но с выбором стратегии для этого случая он не согласен: по его же схеме при паузе до двух часов выгоднее петля.

Автор хотел бы видеть в Claude Code настройку истечения кэша с тремя режимами: Keep Alive (держать кэш живым, как его петля), Smart Cache (выбирать между сжатием и петлёй по размеру контекста и времени отсутствия) и Let Expire. Сколько вы будете отсутствовать, по его замыслу, харнессу сообщал бы сам пользователь.