Claude Code 2.1.247: команда /claude-api cost-optimize меняет подход к аудиту расходов на API

Большинство проблем с расходами в AI gateway-развёртываниях остаются невидимыми до прихода счёта. Команды обнаруживают, что кэширование было отключено, все sub-agent'ы использовали флагманскую модель для задач, которые справился бы малый вариант, или что контекст восстанавливался полностью при каждом повторе — не в момент API-вызова, а через недели, когда кто-то запускает sum(cost) на экспортированном CSV. Claude Code 2.1.247 сокращает этот разрыв: в релизе появилась встроенная команда профилирования и исправлен сбой, при котором fallback-цепочка молча разрывалась при первом неудачном вызове модели в sub-agent.

Что появилось в релизе

Два изменения в 2.1.247 важны для операторов, развёртывающих Claude Code в рабочем контуре.

/claude-api cost-optimize — новая встроенная команда, которая профилирует расходы текущего проекта на Claude API и шаг за шагом проводит через рычаги снижения затрат. Охватываются: кэширование (cache hit rate, reads-per-write, настройка TTL), token hygiene (раздутый контекст, порог compaction, длина сессии), применимость batch API, настройка reasoning effort и выбор tier модели. Каждый рычаг сопровождается измерением до и после, а не просто рекомендацией.

Fallback-цепочка модели для sub-agent при 404 — исправление давней проблемы. Когда первый API-вызов sub-agent возвращал 404 (неверное имя модели в конфигурации, модель выведена из эксплуатации, gateway роутит к provider, у которого нет этой модели), прежние версии позволяли sub-agent упасть на этом вызове. Ошибка, переданная в родительскую сессию, не содержала request id и имени модели, что затрудняло корреляцию в логах. В 2.1.247 sub-agent проходит через настроенный fallback-список моделей сессии; при успехе продолжает работу. При неудаче всех fallback'ов ошибка, возвращаемая в родительскую сессию, включает тип ошибки, HTTP-статус, request id и имя модели.

Релиз также добавляет явное оповещение о сбое подключения MCP server на Bedrock, Vertex и Foundry (и любой конфигурации с отключённой телеметрией), а также исправляет восстановление облачной сессии при перезапуске контейнера между ходами.

Почему профилирование расходов должно работать внутри клиента

Стандартный рефлекс при контроле расходов на AI — добавить proxy: перехватывать запросы на уровне gateway, тегировать по модели и команде, экспортировать в хранилище данных. Для атрибуции биллинга это работает, но для оптимизации — нет. Proxy видит форму запроса, но не контекст сессии. Он не может сказать, что sub-agent'ы тянут полные истории на 100K токенов из-за неправильно настроенного compaction, или что для конкретного рабочего процесса переход с auto-effort на medium сэкономил бы 40%, потому что proxy ничего не знает о структуре сессии.

/claude-api cost-optimize работает внутри сессии, где видны рост контекста, соотношение cache hit к структуре prompt и связь между настройками reasoning effort и сложностью задач в данном проекте. Вывод применим к конкретному проекту, а не к агрегированным данным по всем командам.

Для операторов, управляющих множеством команд, это меняет разговор о поддержке. Вместо «ваши расходы высоки, проверьте настройки кэширования» можно попросить команду запустить /claude-api cost-optimize и получить точную картину: какой именно рычаг виноват. Чаще всего это неправильная настройка TTL кэша промптов или флагманская модель, выбранная на этапе прототипирования и никогда не замененная в routing-политике для продакшена.

Разрыв в fallback-цепочке sub-agent при 404

До 2.1.247 последовательность отказа при неверно настроенном sub-agent выглядела так.

Sub-agent стартует, отправляет первый API-вызов с моделью A. API возвращает 404. Sub-agent падает. В родительскую сессию передаётся обобщённое сообщение без имени модели и request id. Родительская сессия не может определить, нужно ли повторить попытку с другой моделью или sub-agent успел выполнить часть работы.

Gateway fallback-цепочки существуют именно для таких ситуаций — если модель A недоступна, пробуем B, затем C. Но fallback-цепочка активировалась только для прямых вызовов родительской сессии, не для первого вызова sub-agent.

Исправление в 2.1.247 означает, что sub-agent'ы участвуют в fallback-цепочке сессии с первого же вызова. Для операторов, работающих с multi-provider routing, это даёт конкретный результат: sub-agent, настроенный на модель, недоступную у одного provider'а, теперь переходит к следующей модели в fallback-списке, а не завершается молча.

Структурированный формат ошибки — тип ошибки, HTTP-статус, request id, имя модели — теперь корректно попадает в логи gateway. Раньше 404 от sub-agent порождал непрозрачную ошибку в контексте родителя, сложно поддающуюся трассировке.

Отчётность о сбоях подключения MCP server на управляемых backend'ах

На Bedrock, Vertex и Foundry была тихая точка трения: сбои подключения MCP server не сообщались. Claude доходил до момента, где требовался инструмент от MCP server, не сумевшего подключиться, не находил инструментов и делал вывод, что их не существует — иногда пытаясь обойтись без них, иногда останавливаясь с непонятной ошибкой. Реальная причина была видна в логах, но до модели не доходила.

Изменение в 2.1.247 отправляет модели явное сообщение при сбое подключения MCP server. Модель теперь может сообщить пользователю, например, что «MCP server code-search не подключился — запущен ли сервер?», а не молча завершить сессию. Для операторов это означает меньше обращений вида «Claude сказал, что не может сделать X, хотя инструмент должен быть доступен»: сбой теперь виден прямо в сессии.

Что проверить в вашем развёртывании

Оптимизация расходов: запустите /claude-api cost-optimize на проектах с наибольшими расходами. Самая частая находка — конфигурация кэша: кэш отключён, TTL короче длины сессии или sub-agent'ы не разделяют кэш с родительской сессией. На втором месте — tier модели: команды, начавшие прототипирование с флагманской моделью и никогда не скорректировавшие routing-политику для продакшена.

Fallback sub-agent: проверьте конфигурации sub-agent'ов на предмет имён моделей, которые могут быть недоступны у всех provider'ов в fallback-цепочке. При двойной конфигурации (например, Anthropic direct + Bedrock) убедитесь, что оба provider'а имеют модель, указанную в sub-agent, или явно добавьте fallback-модель в конфигурацию сессии. Изменение в 2.1.247 обрабатывает сбой на уровне runtime, но правильное решение — согласовать список моделей sub-agent с покрытием provider'ов.

Сбои подключения MCP: если вы управляете MCP server'ами на Bedrock или Vertex, убедитесь, что ошибки подключения теперь отображаются в выводе сессии. Если нет — проверьте, что версия Claude Code 2.1.247 или выше.

Что стоит проверить пользователям TheRouter

Поведение fallback модели sub-agent напрямую взаимодействует с routing-политикой gateway. Если вы маршрутизируете Claude Code через gateway, который переписывает имена моделей или маппит их на идентификаторы конкретного provider'а, fallback-цепочка в 2.1.247 будет обращаться к gateway с переписанным именем — gateway должен единообразно обрабатывать 404-ответы по всем backend'ам provider'ов. Если gateway поглощает 404 и возвращает другой код ошибки, fallback-цепочка может не активироваться корректно.

Проверьте поведение вашего gateway при прозрачной передаче 404-ответов модели от Bedrock, Vertex и прямых Anthropic-эндпоинтов. В документации по роутингу описана настройка обработки ошибок конкретных provider'ов в TheRouter.