Claude Code 2.1.260: Баг кэширования Fable 5.1, который незаметно опустошал кошелёк каждого агента с инструментами

Claude Code 2.1.260 не добавляет новых возможностей модели. Этот релиз закрывает дыру в биллинге, в которую проваливался каждый Fable 5.1-агент с инструментами с самого запуска Fable 5.1 1 сентября.

Конкретный баг: кэш промптов на Fable 5.1 не охватывал контекст, прикреплённый после результатов инструментов. В каждом последующем обороте с вызовом инструмента этот контекст уходил в API как некэшированные входные токены. Для агентов, которые часто вызывают инструменты — то есть для большинства из них — потери накапливаются быстро. Сессия с двадцатью вызовами инструментов и блоком системного промпта плюс история на 10K токенов выставляла полную стоимость за каждый из этих оборотов. Fable 5.1 стоит $10 за миллион входных токенов без кэша и $0.25 за миллион в режиме чтения из кэша — разница в 40 раз. Исправление вошло в 2.1.260, но окно уязвимости длилось с 1 сентября до момента обновления каждого конкретного деплоя.

Здесь важно сказать прямо: Fable 5.1 не ломался для разговорных агентов без инструментов. Проблема проявлялась только в сессиях, где результаты инструментов дописывались к контексту — а это описывает большинство продакшн-воркфлоу с coding-агентами и API-шлюзами.

Почему контекст после результатов инструментов выпадал из кэша

Механизм кэширования промптов Anthropic требует стабильного кэшируемого префикса между оборотами. Результаты инструментов дописываются в список сообщений после каждого вызова, обновляя контекст. Правильное поведение — кэшировать всё до текущего стабильного префикса (то есть до нового результата инструмента) и в следующем обороте тарифицировать эту часть по кэшированной ставке. Баг приводил к тому, что блок после результата инструмента помечался как некэшируемые входные данные, и при каждом вызове всё перевыставлялось по полной цене.

Контекст других провайдеров здесь существенен: этот сценарий отказа специфичен для механизма кэширования Anthropic. OpenAI обрабатывает продолжение после результатов инструментов иначе — клиент не отслеживает явную границу кэша. Операторы, использующие смешанную маршрутизацию (часть сессий на Anthropic, часть на OpenAI), могли замечать разницу в стоимости между аналогичными сессиями Fable 5.1 и GPT-5.6 с инструментами и объяснять её разницей в ценах, а не дефектом кэша. С этого релиза разница в биллинге устранена.

Для деплоев на TheRouter с включённым Fable 5.1: если вы логируете разбивку токенов по оборотам из поля usage в ответах API, вы можете рассчитать окно ущерба, суммировав uncached_input_tokens по оборотам Fable 5.1 с вызовами инструментов между 1 сентября и датой обновления до 2.1.260. Затронутые обороты — те, где cache_read_input_tokens равен нулю при непустом предыдущем контексте. После обновления исправление работает автоматически, никаких изменений конфигурации не требуется.

/cost теперь объясняет причину промаха кэша

Параллельно с исправлением бага 2.1.260 добавляет аннотации причины промаха в /cost и в поле prompt_cache строки статуса. Сообщаемые причины: изменились определения инструментов, изменился системный промпт, прошло время простоя сверх TTL.

До этого оператор, обнаруживший аномалию стоимости, был вынужден вручную сравнивать метаданные ответов API оборот за оборотом, чтобы восстановить причину пропажи кэша. Изменение определений инструментов — частый триггер в управляемых деплоях Claude Code, где плагины раскатываются на всех пользователей: если обновление плагина меняет схему инструмента, кэшированный префикс инвалидируется с этой точки. Промах из-за простоя сверх TTL в логах биллинга выглядит идентично смене системного промпта, если нет временных меток для сравнения.

Операционный воркфлоу, который это открывает: запустите /cost после подозрительной сессии, проверьте аннотированную причину промаха, прежде чем открывать тикет в биллинг. Если причина — изменение определений инструментов, расследование начинается с managed-настроек или плагинного деплоя. Если — смена системного промпта, с любого обновления CLAUDE.md или runtime-инъекции. Если — простой сверх TTL, сессия имела паузу, достаточно длинную для истечения кэша — это особенно актуально для Fable 5.1, поскольку долгоживущие coding-агенты естественным образом приостанавливаются в ожидании ручного ревью.

Откат разрешений Read(), который мог ускользнуть от аудита безопасности

2.1.260 откатывает изменение из 2.1.259. Это изменение применяло правила запрета Read() к аргументам Bash, из-за чего npm run build блокировался правилом Read(./**/build/**) в любом режиме. Откат убирает это поведение.

Последствия для безопасности двусторонние. До 2.1.259 правила запрета Read() контролировали только чтение файлов, но не аргументы Bash, которые случайно указывали на совпадающие пути. Изменение 2.1.259 пыталось закрыть этот пробел — правило «не читать из директории build» не блокировало бы выполнение cd build && grep. Откат означает, что пробел вернулся.

Для операторов, которые быстро прошли путь с 2.1.258 через 2.1.259 до 2.1.260, аудит разрешений выглядит так: правила запрета Read(), которые вы рассчитывали распространить и на аргументы путей Bash, больше не работают таким образом. Read(./**/build/**) заблокирует чтение файлов из build/, но не выполнение grep -r build/. Если это различие важно для вашей позиции безопасности, добавьте явные правила запрета Bash() в дополнение к Read().

Попутное исправление, на которое стоит обратить внимание: 2.1.260 также устраняет проблему, при которой permissions.blockReadsOutsideWorkingDirectories на macOS скрывал от изолированного суб-агента его собственный checkout в рабочем дереве. Если вы используете изолированные рабочие деревья суб-агентов и эта настройка включена, проверьте доступность агентом своих же файлов до широкого деплоя обновления.

Управляемый CLAUDE.md больше не требует одобрения оператором безопасности

2.1.260 меняет поведение управляемых настроек: CLAUDE.md, отправленный через claudeMd в серверных управляемых настройках, больше не вызывает диалог одобрения безопасности, который по-прежнему требуется для хуков, shell-команд, правил sandbox и небезопасных записей env.

Для операторов, которые управляют флотом Claude Code через серверные настройки и централизованно отправляют содержимое CLAUDE.md, это означает: рутинные обновления CLAUDE.md будут вступать в силу без запроса одобрения у пользователя. Хуки и shell-правила по-прежнему требуют одобрения. Это различие важно, поскольку CLAUDE.md управляет поведением агента на уровне промпта — что Claude знает о проекте, его стилевые предпочтения, реакция на инструкции. Этот контент может существенно влиять на поведение даже без доступа к shell.

Контекст между провайдерами: для OpenAI или DeepSeek-бэкендов аналогичного слоя управления в Claude Code нет. Это разграничение одобрений специфично для стека Anthropic managed-settings. Если часть сессий Claude Code маршрутизируется через Anthropic API, а другая — через не-Anthropic, изменение управления CLAUDE.md затрагивает только Anthropic-managed-путь. Не-Anthropic-пути по-прежнему применяют CLAUDE.md из локального файла в рабочей директории — без централизованной отправки и без диалога одобрения.

Практическое изменение для операционных команд: если ваш управляемый CLAUDE.md включает подсказки маршрутизации, предпочтения модели или поведенческие переопределения, которые вы прежде тестировали в staging-среде перед раскаткой, — шаг одобрения служил естественным шлюзом. Без него путь от обновления managed-settings до активной пользовательской сессии стал короче. Рассмотрите отдельное логирование деплоев управляемых CLAUDE.md, чтобы в ходе постинцидентного анализа можно было восстановить, какая версия была активна в любой данной сессии.

oidc.scope_on_refresh для IdP с нестандартным поведением при обновлении токена

Claude apps gateway добавляет oidc.scope_on_refresh для поддержки IdP, которые возвращают id_token при обновлении только в том случае, если scope openid явно запрошен снова. Это точечное исправление, применимое ровно в одной конфигурации: Claude apps gateway с IdP, который не включает openid в запрос обновления токена автоматически.

Последствие для оператора: если сессии Claude Code через ваш шлюз незаметно деградировали из аутентифицированного в неаутентифицированное состояние — особенно длительные coding-сессии — и ваш IdP соответствует описанному паттерну, эта настройка восстанавливает id_token при обновлении. Без id_token шлюз, использующий OIDC-клеймы для валидации идентичности сессии, увидит ошибку при обновлении и либо отклонит сессию, либо откатится к анонимной обработке — в зависимости от вашей политики при ошибках.

Установите oidc.scope_on_refresh: "openid" в конфиге Claude apps gateway, если запросы на обновление сейчас возвращают токен без ожидаемых клеймов. Не устанавливайте, если ваш IdP уже по умолчанию включает этот scope при обновлении — лишний параметр только добавит бесполезный цикл.