Claude Code fallbackModel: поддержка цепочки из трёх fallback-моделей и усиление границы доверия между сессиями

Релиз Claude Code от 6 июня (v2.1.166) содержит два изменения, которые непосредственно влияют на конфигурацию надёжности у операторов и архитектуру доверия в мульти-агентных развёртываниях. Центральная функция — обновлённая настройка fallbackModel, принимающая упорядоченный список до трёх резервных моделей. Сопутствующее изменение — существенное усиление безопасности: сообщения, ретранслированные через SendMessage из других сессий Claude, больше не несут пользовательских полномочий, а получатели отклоняют ретранслированные запросы на разрешения.

Оба изменения появились одновременно не случайно: они решают противоположные стороны одной проблемы — сохранять работоспособность долгоживущих agentic-рабочих процессов при отказе основных ресурсов, не допуская при этом скрытого переноса авторизации между сессиями.

Что изменилось в claude code fallbackModel three-model fallback chain

До v2.1.166 fallbackModel был однозначной настройкой: при 529-ошибке перегрузки или недоступности основной модели Claude Code пробовал одну альтернативную модель и затем сразу выдавал ошибку пользователю.

Новое поведение:

• fallbackModel принимает упорядоченный массив до трёх идентификаторов моделей.
• Claude Code перебирает их последовательно: primary → fallback[0] → fallback[1] → fallback[2].
• Флаг --fallback-model теперь применяется к интерактивным сессиям, а не только к headless-вызовам claude -p. Это существенно: раньше интерактивные пользователи всё равно упирались в жёсткие 529-ошибки.
• Отдельно: когда API возвращает неожиданную, неповторяемую ошибку, Claude Code делает одну повторную попытку на первой доступной fallback-модели. Ошибки аутентификации, rate-limit, превышения размера запроса и транспортные ошибки явно исключены и по-прежнему немедленно поднимаются наверх.

Типичная конфигурация settings теперь выглядит так:

{
  "model": "claude-opus-4-8",
  "fallbackModel": ["claude-sonnet-4-6", "claude-haiku-4-5", "deepseek/deepseek-v4-flash"]
}

Это даёт трёхуровневую деградацию: Opus 4.8 как основная модель → Sonnet 4.6 при перегрузке → лёгкий Haiku 4.5 → внешняя OpenAI-совместимая модель как последний рубеж перед видимой пользователю ошибкой.

Усиление безопасности между сессиями

Claude Code поддерживает мульти-агентные паттерны, при которых одна сессия Claude отправляет задачи другой через SendMessage. Ранее ретранслированные таким образом сообщения наследовали пользовательские полномочия исходной сессии — это означало, что запрос на разрешение, переданный через relay, мог быть принят получателем как будто его одобрил сам пользователь.

В v2.1.166 эта уязвимость закрыта:

• Сообщения, ретранслированные через SendMessage из других сессий Claude, больше не несут пользовательских полномочий.
• Сессии-получатели отклоняют ретранслированные запросы на разрешения.
• Auto-режим явно блокирует ретранслированные запросы, которые иначе были бы автоматически одобрены.

Для команд, запускающих Claude Code в мульти-агентных топологиях, это важное архитектурное уточнение: граница доверия теперь проходит по краю сессии, а не по краю сообщения. Оркестрирующая сессия не может эскалировать свои полномочия путём ретрансляции через sub-сессию.

Почему это важно для AI-инженерных команд

Планирование надёжности на стороне оператора

Трёхуровневая fallback-цепочка меняет расчёт надёжности для команд, использующих Claude Code в промышленном масштабе. До этого длительная перегрузка Anthropic API приводила либо к тихой деградации до одной запасной модели, либо к полному отказу. Теперь можно явно задать политику поуровневой деградации:

• Уровень 1 (primary): Opus 4.8 — для высокоточных задач с интенсивным рассуждением.
• Уровень 2 (fallback[0]): Sonnet 4.6 при ограниченной ёмкости Opus — чуть ниже по возможностям, заметно быстрее, часто дешевле.
• Уровень 3 (fallback[1]): Haiku 4.5 или аналогичная лёгкая модель для чувствительных к стоимости и задержке задач.
• Уровень 4 (fallback[2]): Гетерогенный provider (например, OpenAI-совместимый endpoint за routing-шлюзом) как финальная страховка.

По сути это клиентская routing-цепочка — аналог того, что AI-шлюз делает на сетевом уровне, но описанный декларативно в файле настроек Claude Code и применяемый на уровне инструментов.

Взаимодействие с gateway-уровневым routing

Если ваша команда направляет Claude Code через AI-шлюз (например, через ANTHROPIC_BASE_URL), клиентский fallbackModel и шлюзовый routing дополняют друг друга, а не дублируют.

Шлюз решает задачи уровня provider: балансировку по регионам, агрегацию quota, мультиоблачную дистрибуцию через Bedrock/Vertex/Foundry, повторные попытки на уровне запросов, атрибуцию затрат. Клиентская fallback-цепочка решает задачи уровня модели: к какой Claude-модели или OpenAI-совместимой модели перейти, когда текущая перегружена или недоступна. Оба уровня могут работать одновременно без конфликтов.

Практическая схема для команд, использующих routing-слой TheRouter:

1. Указать ANTHROPIC_BASE_URL на endpoint своего шлюза.
2. Настроить трёхуровневую fallbackModel-цепочку в settings Claude Code.
3. На шлюзовом уровне задать retry-политику и бюджеты задержки для каждого provider.

Это даёт два независимых fallback-механизма: шлюз повторяет попытки между инстансами provider для одной и той же модели; Claude Code переходит к другому уровню модели, когда шлюз исчерпал варианты для основной модели.

Последствия для безопасности мульти-агентных развёртываний

Изменение полномочий между сессиями требует целенаправленного аудита для команд, работающих с топологиями orchestrator/sub-agent.

Если ваша текущая архитектура полагается на передачу запросов разрешений из оркестрирующей сессии в sub-сессии — и те автоматически одобряют их, видя «пользовательские полномочия» — этот паттерн в v2.1.166 работать не будет. Вам нужно:

1. Провести аудит потоков SendMessage, чтобы найти места, где делегирование полномочий происходило неявно.
2. Явная предварительная авторизация: заранее одобрить конкретные инструменты, нужные sub-сессии, в её allow-list — вместо опоры на runtime-approval через relay.
3. Использовать allowedTools в settings, чтобы давать sub-сессиям минимально необходимый набор разрешений.
4. Рассматривать границу сессии как границу доверия: проектировать оркестрационную топологию так, чтобы каждая сессия работала в рамках минимального предварительно определённого набора разрешений.

Это приводит модель безопасности Claude Code в соответствие с тем, как работает scoping API-ключей на шлюзовом уровне: downstream-потребитель получает ограниченный токен, а не делегирование основных полномочий.

Фреймворк решений для оператора: обновление fallbackModel

Для команд, использующих fallbackModel как единственную строку, путь обновления прямолинеен:

Шаг 1: Определите бюджет деградации. Какие компромиссы между возможностями и стоимостью приемлемы для уровней 2 и 3?

Шаг 2: Проверьте доступность модели на каждом уровне. Если вы маршрутизируете через шлюз — убедитесь, что каждая fallback-модель есть в списке allowed-providers вашего шлюза.

Шаг 3: Установите fallbackModel как массив. Первая запись — приоритетный fallback, пробуемый до второго, и так далее.

Шаг 4: Если команда использует Claude Code в интерактивном (не headless) режиме — проверьте новое поведение --fallback-model для интерактивных сессий и обновите runbook.

Шаг 5: Для мульти-агентных топологий проведите описанный выше аудит SendMessage до развёртывания v2.1.166 в production-оркестрацию.

На что обратить внимание

Текущая fallback-цепочка разрешает идентичность модели — она не выбирает следующую модель динамически по сигналам стоимости, задержки или качества во время выполнения. Если команде нужны динамические routing-решения (например, «переходить на Haiku при задержке ответа >5 с, а не только при 529-перегрузке Opus»), эта логика по-прежнему живёт на шлюзовом уровне.

Следите за будущими релизами, которые могут добавить метаданные fallback по каждому туру в OTEL-трейсы — это позволит системам мониторинга на шлюзовом уровне коррелировать момент срабатывания клиентского fallback с целевым уровнем модели.

В части безопасности: изменение границы доверия SendMessage для сценариев auto-mode и relay-разрешений завершено в v2.1.166. Если ваши оркестрационные паттерны зависят от переноса возможностей между сессиями иными способами (общий контекст, общие наборы инструментов) — проверьте, что они работают как ожидается.

Связанные материалы

• Настройка routing-политик для мульти-провайдерного fallback
• Паттерны маршрутизации моделей и fallback
• Руководство по интеграции Claude Code