Claude Code enforceAvailableModels закрывает лазейку Default-модели в управляемых настройках

Claude Code v2.1.175 добавляет enforceAvailableModels: теперь allowlist из availableModels также ограничивает Default-модель, а проектные и пользовательские настройки не могут его расширить. Для корпоративных команд это закрывает долгое время существовавший обход.

TheRouter Newsroomисточник Anthropic
Схема архитектуры, показывающая уровень managed settings, контролирующий шлюз allowlist для путей разрешения Default-модели в Claude Code

Claude Code v2.1.175, выпущенный на этой неделе, добавляет один новый управляемый параметр — enforceAvailableModels, — который устраняет реальный пробел в управлении моделями, вокруг которого команды были вынуждены выстраивать обходные решения с момента появления allowlist из availableModels.

Что произошло

До этого релиза управляемый параметр availableModels в Claude Code позволял операторам определять список допустимых идентификаторов моделей. Однако у этого механизма было два пути обхода, которые большинство команд не замечали:

  1. Псевдоним Default-модели не был ограничен allowlist. Если Default-модель организации разрешалась, например, в Opus 4.8, а эта модель отсутствовала в списке availableModels, сессия всё равно использовала Opus 4.8: allowlist блокировал только явный выбор через пикер /model, но не путь разрешения Default.
  2. Проектные и пользовательские настройки могли расширять allowlist. Разработчик мог добавить в .claude/settings.json или ~/.claude/settings.json модель, намеренно исключённую из управляемого списка, и Claude Code принимал эту настройку.

При enforceAvailableModels: true на уровне managed settings оба пути обхода закрыты. Default-модель теперь откатывается к первой разрешённой модели в списке, если её целевое разрешение заблокировано. Проектные и пользовательские настройки больше не могут расширять управляемый список availableModels — уровень managed теперь является потолком, а не полом.

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

Корпоративные команды применяют availableModels по двум основным причинам: контроль расходов (предотвращение доступа к более дорогостоящим уровням моделей) и соответствие требованиям (обеспечение того, чтобы весь LLM-трафик проходил через утверждённые, прошедшие аудит модели — что часто требуется соглашениями об обработке данных или внутренней политикой управления AI).

Пробел до v2.1.175 означал, что управляемый allowlist вида ["claude-sonnet-4-6", "claude-haiku-4-5"] всё равно пропускал сессии на Opus или Fable 5 через путь Default — как правило, самый дорогой уровень в корпоративных pay-as-you-go аккаунтах. Аудиты выявляли перерасход, но не всегда указывали на первопричину.

Ещё критичнее: compliance-команды, полагавшиеся на availableModels для ограничения того, какие модели обрабатывают чувствительные данные, теперь получают более надёжную гарантию. Путь Default-fallback всегда был наиболее рискованным исключением — он оставался невидимым для большинства разработчиков, которые никогда явно не выбирали модель и потому не замечали, что оказались за пределами allowlist.

Взгляд со стороны router/operator

Для команд, маршрутизирующих сессии Claude Code через AI gateway — через ANTHROPIC_BASE_URL, указывающий на прокси, или через нативный деплой Bedrock/Vertex/Foundry — enforceAvailableModels имеет важное взаимодействие с тем, как gateway получает идентификаторы моделей.

При включённом параметре и разрешении Default в первую разрешённую модель идентификатор модели, отправляемый upstream, становится детерминированным: он больше не зависит от типа аккаунта (на Max/Team Premium Enterprise Default разрешался в Opus, на Pro/Team — в Sonnet). Это означает:

  • Таблицы маршрутизации становятся предсказуемыми. Не нужно учитывать, в какой идентификатор модели разрешится Default в зависимости от типа аккаунта. Gateway всегда будет получать первую запись из управляемого списка.
  • Атрибуция расходов становится чище. Любое использование токенов, приписанное неразрешённой модели после включения enforceAvailableModels, является ошибкой конфигурации, а не обходом политики — это проще выявлять при аудите.
  • Allowlist взаимодействует с fallbackModel. Если в managed settings определены и availableModels, и fallbackModel, убедитесь, что fallbackModel также входит в allowlist. Модель fallback, отсутствующая в списке, теперь будет заблокирована enforceAvailableModels, что может привести к сбою сессии вместо деградации. Протестируйте эту конфигурацию в staging-среде до развёртывания в production.

Важный нюанс для операторов: enforceAvailableModels является параметром исключительно уровня managed. Он не может быть установлен в проектном или пользовательском scope — это сделано намеренно. Если бы его можно было отключить на уровне проекта, это подрывало бы саму его цель.

Что проверить перед включением параметра

Для команд, готовых включить enforceAvailableModels, рекомендуется выполнить следующие предварительные шаги:

  1. Проверьте текущее разрешение Default-модели. Запустите claude /status в типичной сессии, чтобы увидеть, в какую модель сейчас разрешается Default. Если она отсутствует в allowlist availableModels, после включения параметра сессии тихо переключатся на первую разрешённую модель.
  2. Выстройте allowlist в порядке приоритета. Первая запись в availableModels становится фактическим Default, когда enforceAvailableModels включён и Default в противном случае был бы заблокирован. Порядок списка — это политическое решение.
  3. Проверьте цепочку fallback. Любой fallbackModel, настроенный пользователями или проектами, должен также присутствовать в управляемом allowlist, иначе он будет заблокирован.
  4. Согласуйте с таблицами маршрутизации gateway. Если ваш AI gateway маршрутизирует по идентификатору модели, убедитесь, что ожидаемый идентификатор (первая разрешённая модель) сопоставлен с правильным upstream provider/деплоем.

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

Командам, маршрутизирующим сессии Claude Code через TheRouter с применением managed settings для управления моделями, следует добавить enforceAvailableModels: true рядом с availableModels в конфигурацию managed settings. Это закрывает обход Default-модели и делает идентификатор модели видимым и детерминированным на уровне gateway — существенное улучшение для команд, использующих правила маршрутизации TheRouter для разделения трафика Sonnet-уровня и Opus-уровня по стоимости или provider.

Параметр доступен начиная с Claude Code v2.1.175. Запустите claude update для обновления.

Схема двухуровневого контроля доступа к моделям: потолок на уровне организации и ограничения effort на уровне роли, модели Claude скрыты за шлюзами доступа

Claude Enterprise Model Entitlements: ролевые ограничения доступа к моделям и уровней effort вышли в бета

Новая функция Anthropic позволяет администраторам ограничивать доступ к конкретным моделям Claude по ролям и устанавливать максимальный уровень effort на роль — тем самым напрямую ограничивая расход токенов. Разбираем, что нужно настроить AI-командам.

источник Anthropic
Абстрактная схема: org-level MCP server governance — поток конфигурации от администратора к параллельным Claude Code сессиям

Claude Code 2.1.259: Org-Level MCP Server Push и исправление потери состояния при параллельных сессиях

Claude Code 2.1.259 добавляет managedMcpServers для централизованного развёртывания HTTP/SSE MCP серверов, меняет семантику allowedMcpServers и закрывает баг, из-за которого параллельные сессии тихо перезаписывали состояние ~/.claude.json в CI-окружениях.

источник Claude Code CHANGELOG
Абстрактная диаграмма маршрутизации с границей containment вокруг облачных credential-путей, стиль редакционного ньюсрума

Claude Fable 5.1: Containment Escape блокирует получение облачных credentials по умолчанию

Claude Code 2.1.257 выпускает Fable 5.1 с 1M контекстом и жёсткой блокировкой запросов к облачным metadata-сервисам в auto-режиме — вот что нужно проверить операторам production-пайплайнов.

источник Anthropic Claude Code
Поддержка