1 сентября 2026 года Anthropic уронила чтение из кэша на 75% - с $1 до $0,25 за миллион токенов. Считаю на примере, почему счёт упал не вчетверо, где кэш ломается и почему Google в свежей работе предлагает историю диалога вообще выбросить.
В релизе новой модели меня зацепили не бенчмарки, а строчка в прайсе: вход и выход не изменились ни на цент, а чтение из кэша упало вчетверо. Полез считать - и выяснил, что счёт при этом падает совсем не вчетверо. Разбираю, куда делась разница.
1 сентября 2026 года Anthropic выпустила Claude Fable 5.1 и Claude Mythos 5.1. Это одна и та же модель под двумя именами: Fable 5.1 открыта всем по API, а Mythos 5.1 раздают по программе ограниченного доступа проверенным организациям в кибербезопасности и биологии - тем, кому штатные предохранители мешают работать.
Главное в релизе - прайс. По документации Anthropic чтение из кэша у Fable 5.1 стоит $0,25 за миллион токенов против $1 у Fable 5. Вход остался $10, выход - $50, оба ровно как были.
Компания оценивает эффект в 25% экономии на типовых нагрузках и до 45% на агентных. Держите в голове, что это её собственная оценка на её сценариях, а не независимый замер (VentureBeat).
Кэш - это когда провайдер запоминает начало вашего промпта и на следующем запросе не считает его заново. У него две разные операции с разными ценами, и вот тут вся соль. Цифры за миллион токенов:
вход - $10, это обычные токены, которые модель читает впервые;
запись в кэш на 5 минут - $12,50, то есть на 25% дороже обычного входа;
запись в кэш на 1 час - $20, вдвое дороже входа;
чтение из кэша - $0,25, было $1 у Fable 5;
выход - $50, это то, что модель генерирует.
Подешевела ровно одна строчка из пяти - чтение. У Fable 5.1 попадание в кэш считается по множителю 0,025 от цены входа, тогда как у всех остальных моделей Anthropic - по стандартным 0,1.

В чате вы платите в основном за то, что модель написала. У агента наоборот: он делает десятки шагов подряд и на каждом заново отправляет одно и то же - системный промпт, описания инструментов, куски кода. Главная строка в его счёте давно не «сколько я сгенерировал», а «сколько раз я перечитал одно и то же».
Возьмём агента, который чинит баг в репозитории. Стабильный префикс - системный промпт, определения инструментов и куски кода - 50 000 токенов. Агент делает 40 шагов: один раз пишет префикс в кэш, дальше 39 раз его перечитывает. Считаю только строку префикса, генерация тут ни при чём.
Без кэша вообще: 40 × 50 000 = 2 000 000 токенов входа × $10 / 1 000 000 = $20.
На Fable 5: запись 50 000 × $12,50 / 1 000 000 = $0,63, плюс 39 чтений 1 950 000 × $1 / 1 000 000 = $1,95. Итого $2,58.
На Fable 5.1: запись те же $0,63, плюс 39 чтений 1 950 000 × $0,25 / 1 000 000 = $0,49. Итого $1,11.
Вот и ответ: чтение подешевело в 4 раза, а строка префикса - в 2,3 раза. Потому что запись не подешевела вообще, и теперь именно она главная. Раньше она была 24% от этой строки, а стала 56% - за одну ночь поменялись местами.
Запись в кэш на 5 минут стоит $12,50 против $10 за обычный вход. Значит, если ваш префикс на каждом шаге пересоздаётся заново и ни разу не попадает, вы платите за кэш штраф, а не экономите.
Тот же агент, но с ломающимся кэшем: 40 × 50 000 × $12,50 / 1 000 000 = $25. Это дороже, чем вообще не включать кэширование ($20), и в 22 раза дороже работающего кэша ($1,11).
Ломает попадание любая правка в начале промпта: кэш идёт иерархией инструменты → системный промпт → сообщения, и изменение на любом уровне обнуляет этот уровень и все следующие. Правка имён, описаний или параметров инструментов обнуляет кэш целиком.
Классический способ выстрелить себе в ногу - подставить в системный промпт текущее время, номер шага или счётчик итераций. Префикс становится уникальным на каждом шаге, попадание нулевое, счёт растёт.
Гадать не нужно: API возвращает это в блоке usage каждого ответа.
# первый запрос сессии - платим за запись
"usage": {
"input_tokens": 312,
"cache_creation_input_tokens": 50000,
"cache_read_input_tokens": 0
}
# следующие 39 шагов - платим за чтение
"usage": {
"input_tokens": 180,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 50000
}Если cache_creation_input_tokens большой на КАЖДОМ шаге, а cache_read_input_tokens при этом нулевой - кэш не работает, и вы переплачиваете. Ищите, что меняется в начале промпта.
Ловушка для коротких промптов: у Fable 5.1, Mythos 5.1, Opus 5 и Fable 5 минимальная длина кэшируемого промпта - 512 токенов. Короче - не закэшируется вообще, молча.
Opus 5 стоит $5 за вход и $25 за выход - вдвое дешевле Fable 5.1 по обеим строкам. Но чтение из кэша у него $0,50, а запись - $6,25. То есть у Fable 5.1 вход дороже, а попадание в кэш вдвое дешевле в абсолютных деньгах.
Считаем, с какого шага это отбивается. Пусть N - число обращений с одним префиксом размером P миллионов токенов:
Fable 5.1: P × (12,5 + (N − 1) × 0,25)
Opus 5: P × (6,25 + (N − 1) × 0,5)
Приравниваем: 6,25 = (N − 1) × 0,25, откуда N = 26. На 26 обращениях паритет, с 27-го строка префикса у Fable 5.1 дешевле, чем у Opus 5 - и дальше разрыв только растёт. На примере с 40 шагами: $1,11 против $1,29.
Только не переносите вывод на весь счёт: выход у Fable 5.1 вдвое дороже, и если агент много пишет, экономия на префиксе сгорает в генерации.

Пока Anthropic делает перечитывание дешевле, исследователи Google зашли с другой стороны: перестать перечитывать вообще. В работе SKILL.state: Scalable Long-Horizon Agent Skills (версия от 28 августа 2026 года, принята на EMNLP) они предлагают выбросить растущую историю диалога и заменить её явным структурным состоянием.
На каждом шаге модель получает только неизменную спецификацию навыка, текущее состояние и последнее наблюдение. Промежуточные рассуждения выбрасываются сразу после обновления состояния - и промпт перестаёт расти: он держится плоским, 1 736-1 905 токенов на любом горизонте.
Цифры из статьи, задача про управление складом на Gemini-3-Flash, горизонт 100 шагов. Подход с полной историей (LangGraph) сжёг 1 062 387 токенов при точности 0,91, SKILL.state - 65 408 токенов при точности 0,94. Сокращение в 16,2 раза, причём точность не упала, а выросла.
Оба, потому что чинят разные половины одной проблемы. Дешёвый кэш решает денежную часть: перечитывать много - больше не разорительно. А работа Google показывает вторую половину, деградацию качества: у ReAct с полной историей точность на 100 шагах 0,84, на 200 шагах - 0,74, у SKILL.state на обоих горизонтах 0,94.
Отравление контекста накопленным мусором кэш не лечит, он лишь делает его дешёвым. Так что не радуйтесь возможности пихать в контекст всё подряд: кэшируйте то, что нужно на каждом шаге, а промежуточную возню агента складывайте в состояние, а не в историю.
Посмотрите usage в ответах. Если cache_creation_input_tokens ненулевой на каждом шаге - кэш не попадает, и это ваша главная переплата, а не цена модели.
Вычистите изменчивое из начала промпта. Время, счётчики, случайные идентификаторы - им место в конце сообщения, а не в системном промпте.
Заморозьте определения инструментов. Набор инструментов не должен собираться динамически под каждый шаг - иначе кэш обнуляется целиком.
Выберите TTL по паузам, а не по интуиции. Если между шагами бывают паузы длиннее 5 минут, пятиминутный кэш умирает и запись идёт заново: две записи по $12,50 дороже одной часовой за $20. Часовой кэш окупается со второго пересоздания.
Пересчитайте выбор модели по формуле выше. Длинная сессия с большим префиксом и скупой генерацией - случай, где более дорогая по входу модель выходит дешевле.
Счёт правда упадёт на 25-45%? Это оценка Anthropic на её сценариях. На расчёте выше строка префикса падает в 2,3 раза, но общий счёт зависит от объёма генерации - выход не подешевел.
Fable 5.1 и Mythos 5.1 - разные модели? Одна модель под двумя именами: первая доступна всем по API, вторая - по ограниченному доступу для проверенных организаций в кибербезопасности и биологии.
Кэш подешевел у всех моделей Anthropic? Нет. Множитель 0,025 от цены входа - только у Fable 5.1 и Mythos 5.1, у остальных стандартные 0,1.
Какой контекст у Fable 5.1? 1 млн токенов на вход, до 128 тыс. токенов на ответ - столько же, сколько у Opus 5 и Sonnet 5.
Стоит ли переписывать агента под SKILL.state? Это исследовательская работа, а не готовый фреймворк. Но идею забрать можно: держать состояние отдельной структурой и не таскать в промпте все прошлые рассуждения.
Цена токена перестала быть тем числом, по которому выбирают модель для агента. Считать теперь надо не «сколько стоит миллион», а «сколько раз мой агент перечитает один и тот же префикс и попадёт ли он в кэш».
Загляните в usage своего агента - какая у вас доля попаданий? Подозреваю, у многих там честный ноль.