Режим fallbacks "default" доступен на Opus 5 — а speed: fast для Opus 4.7 теперь возвращает жёсткую ошибку 400

В обновлении Anthropic API от 24 июля появились два изменения, которые operator-команды должны проверить в своих конфигурациях прямо сейчас.

Первое — уже активное breaking change: speed: "fast" для claude-opus-4-7 теперь возвращает жёсткую ошибку 400. Модель больше не деградирует до стандартной скорости, как делал Opus 4.6. Любой production-путь с захардкоженным fast mode на Opus 4.7 тихо выдаёт ошибки уже четыре дня.

Второе — расширение routing-примитива, который раньше был доступен только в Fable 5: fallbacks: "default" — серверный fallback Anthropic по категориям отказов — теперь работает на Claude Opus 5 и Claude Opus 4.8, то есть именно на тех моделях, которые большинство команд использует для production agentic-задач.

Что сломалось: fast mode для Opus 4.7 — жёсткая ошибка, не плавная деградация

История fast mode в линейке Opus асимметрична, и её важно знать:

Главное для operator: Opus 4.7 не деградирует плавно. Если в конфигурации gateway есть speed: "fast" привязанный к claude-opus-4-7 — в переменной окружения, файле конфигурации модели или таблице routing-политики — вы генерируете 400-ошибки вместо ответов. Сама модель по-прежнему доступна на стандартной скорости; отвергается только параметр speed.

Путь миграции:

# До (теперь возвращает 400 для claude-opus-4-7)
{
  "model": "claude-opus-4-7",
  "speed": "fast",
  ...
}

# После: перейдите на Opus 5 или Opus 4.8, чтобы сохранить fast mode
{
  "model": "claude-opus-5",
  "speed": "fast",
  ...
}
# ИЛИ: уберите параметр speed и используйте Opus 4.7 на стандартной скорости
{
  "model": "claude-opus-4-7"
  # без параметра speed
}

Если вы используете anthropic SDK middleware, проверьте, установлено ли поле speed на уровне SDK или приходит из конфигурации среды — SDK-умолчания могут сохраняться после обновления модели.

Что появилось: режим fallbacks "default" теперь работает на Opus 5 и Opus 4.8

Серверный fallback API позволяет объявить резервную модель прямо в запросе. Вместо того чтобы перехватывать ответ с stop_reason: "refusal" и делать повторный запрос другой модели на стороне клиента, API обрабатывает retry за один round-trip. Ответ приходит либо от основной модели, либо от fallback — без дополнительной задержки для вашей retry-логики.

Режим "default" — когда Anthropic сам выбирает рекомендуемый fallback по категории отказа — раньше был доступен только на Fable 5 и Mythos 5. С 24 июля он также работает на Opus 4.8 и Opus 5:

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "..."}],
    fallbacks="default",
    betas=["server-side-fallback-2026-07-01"],
)
# response.model показывает, какая модель фактически обработала ответ
print(response.model)

То же самое работает через curl, TypeScript, Go, Java, PHP и Ruby — beta header server-side-fallback-2026-07-01 является переключателем, а fallbacks: "default" — режимом.

Что конкретно делает режим "default": Anthropic перенаправляет отказанные запросы на рекомендуемый fallback по категории отказа. Для категорий без рекомендованного fallback отказ возвращается как есть. Вы не контролируете, какая именно модель обрабатывает retry — это компромисс за нулевую клиентскую сложность. Если вам нужно указать конкретную fallback-модель, явная форма (fallbacks: [{model: "claude-sonnet-5"}]) по-прежнему доступна.

Архитектурный вывод для routing

Эти два изменения тянут в разные стороны, но указывают на один и тот же operator-урок.

Ситуация с Opus 4.7 fast mode показывает цену устаревшей конфигурации модели: значение параметра, работавшее на прошлой неделе, теперь тихо генерирует ошибки. Исправление — одна строка конфига, но ущерб (4+ дня ошибок 400) уже нанесён, потому что никто не поймал изменение.

fallbacks: "default" для Opus 5 показывает, как выглядит продуманная обработка пути вперёд: один параметр сообщает API, что делать, когда основная модель отказывает, — без поддержки собственной retry-логики и без захардкоженных имён fallback-моделей, которые сами потребуют ротации.

Вместе они аргументируют routing-политику, которая явно учитывает жизненный цикл модели, а не предполагает, что параметр, работающий сегодня, переживёт следующий релиз API.

Что проверить в routing-конфигурации сегодня

1. Аудит настроек fast mode: Найдите в кодовой базе и конфигурационных файлах speed.*fast или "fast-mode". Если любой путь указывает на claude-opus-4-7, уберите параметр speed или переведите модель на Opus 4.8 или Opus 5.

2. Проверьте обработку ошибок 400: Если ваш gateway считает любую 400-ошибку хардфэйлом без анализа тела ответа, вы можете молча терять запросы вместо того, чтобы маршрутизировать их в fallback. Добавьте явную обработку для ошибок параметра speed.

3. Оцените fallbacks: "default" для рабочих нагрузок на Opus 5: Если вы запускаете Opus 5 для agentic-задач, которые задействуют контент-классификаторы (анализ документов, суммаризация, agentic-браузинг), режим "default" теперь доступен без дополнительных накладных расходов на управление моделями.

4. Проверяйте response.model в логах: При активном серверном fallback поле model в ответе будет отличаться от отправленного. Убедитесь, что ваши pipeline биллинг-реконсиляции и observability читают response.model, а не предполагают совпадение модели запроса и ответа.

Для полной настройки серверного fallback, включая поведение billing credit при попадании prompt cache на отказе основной модели, см. более ранний анализ TheRouter и документацию Anthropic по отказам и fallback.