Claude Code 2.1.267: Ограничение уровня Effort для операторов, стабилизация кэша промптов и исправление обхода контейнера маркетплейса

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

Управление уровнем Effort: что реально ограничивает maxEffortLevel

Новая настройка maxEffortLevel может быть размещена на верхнем уровне claude.json или внутри записи конкретной модели в modelSettings. Она устанавливает потолок уровня effort для всех провайдеров, через которые маршрутизирует оператор, — включая Bedrock, Vertex и Foundry, — а не только для прямого подключения к Anthropic.

Ключевое поведение: пользователи по-прежнему могут выбрать уровень effort ниже потолка. Выше — нельзя. Это потолок, а не пол и не фиксированное значение.

Почему это важно для управления стоимостью: уровни effort на моделях с расширенным мышлением мультипликативно влияют на потребление токенов. Пользователь, запускающий каждую сессию на максимальном effort в кластерном развёртывании, может генерировать расходы на порядок выше базового уровня. Ранее единственными инструментами контроля были общеорганизационные управляемые настройки или ограничения уровня модели — ни один не позволял сказать «этот деплой работает на opus-4.7, но effort не выше medium».

Формат конфигурации:

// Глобальный потолок — применяется ко всем моделям
{
  "maxEffortLevel": "medium"
}

// Потолок для конкретной модели — удобен для смешанных кластеров
{
  "modelSettings": {
    "claude-opus-4-7": {
      "maxEffortLevel": "high"
    },
    "claude-fable-5-1": {
      "maxEffortLevel": "low"
    }
  }
}

Область действия на всех провайдерах — ключевая часть. До этой настройки у операторов, маршрутизирующих через Bedrock или Vertex, не было контроля уровня effort, сохраняющегося при смене провайдера. Теперь ограничение следует за сессией независимо от того, какой бэкенд обрабатывает запрос.

--system-prompt-snapshot off и итеративные рабочие процессы

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

--system-prompt-snapshot off отключает шаг записи. Системный промпт читается заново из файла конфигурации на каждой границе запроса. Компромисс явный: повторное использование кэша промптов для системного префикса падает до нуля, поскольку префикс больше не стабилен между витками. Для итерации в период развёртывания и A/B-тестирования вариантов системного промпта это правильный компромисс; для стабильного продакшена следует оставить настройку по умолчанию.

Флаг полезен именно в период, когда оператор настраивает развёрнутый системный промпт и запускает оценочные сессии на реальных пользовательских входных данных. Без отключения снапшота каждая оценочная сессия тестирует промпт из записи, а не с диска, что даёт вводящий в заблуждение сигнал.

Обход контейнера маркетплейса: что сломалось и кого затрагивает

Путь к записи маркетплейса, содержащий обратный слэш, мог обойти проверку контейнера для загруженных маркетплейсов на macOS и Linux. Проверка валидирует, что разрешённый путь остаётся внутри настроенного корня маркетплейса; обратный слэш приводил к тому, что нормализация пути давала строку, проходящую проверку, но разрешающуюся в расположение за пределами корня.

Затронутые: операторы, запускающие самостоятельно развёрнутый Claude Code с кастомным маркетплейсом, где манифесты записей маркетплейса содержат пути с обратными слэшами. На Unix-системах это редкость, но возможно, если записи маркетплейса создавались на Windows или генерировались инструментами, использующими разделитель с обратным слэшем.

Исправление нормализует путь до проверки контейнера, а не после. Действий оператора не требуется, если только существующие записи маркетплейса не содержат обратные слэши в путях — в этом случае следует немедленно провести аудит. Аналогичное исправление уже было выпущено в 2.1.265 для путей плагинов в --plugin-dir; данное исправление закрывает тот же класс проблемы в пути загрузки маркетплейса.

Стабильность кэша промптов: двенадцать исправлений, одна строка в бюджете

2.1.267 содержит двенадцать отдельных исправлений условий разрушения кэша промптов. Перечислять каждое по отдельности означает недооценивать совокупный эффект; стоит назвать паттерн, который они устраняют.

Основная проблема: Claude Code кэширует префикс системного промпта и определения инструментов при открытии сессии. Любое событие, вызывающее повторную отрисовку этих элементов в середине сессии — смена модели, переподключение инструмента, переподключение MCP-сервера, форк субагента, восстановление сессии — разрушает кэш и снова выставляет счёт за токены префикса как за некэшированный ввод. При цене $3–15 за миллион кэшированных токенов против $15–75 за миллион некэшированных повторные разрушения в длинных сессиях или высоконагруженных пайплайнах накапливаются быстро.

Исправления охватывают конкретные триггерные условия:

• Смена модели через /model: ранее повторно отправлялись все определения инструментов, вызывая полный промах кэша. Теперь список инструментов стабилен при смене модели.
• Переподключение MCP-сервера в середине сессии: ранее добавление переподключённых инструментов разрушало стабильный префикс. Исправлено для моделей с поиском инструментов (отложенные определения) и прочих.
• Форк и восстановление субагента: начальный контекст субагента и предзагруженные навыки перемещались из префикса промпта в последующих витках, делая кэш для собственных запросов субагента недействительным.
• Восстановление сессии после /compact: вставлялся лишний виток «Продолжить с того места, где вы остановились», изменяя префикс системного промпта и делая кэш всей восстановленной сессии недействительным.
• Сессии с --system-prompt и --append-system-prompt: теперь системный промпт и определения инструментов записываются один раз, а не перерисовываются при каждом витке.

Для операторов, использующих рабочие процессы с длинными сессиями, частыми переключениями /model или MCP-коннекторами, переподключающимися после сбоев, совокупный эффект этих исправлений должен быть измерим в детализации токенного биллинга. Показатель попаданий в кэш промптов для многовитковых сессий должен вырасти после обновления.

Что нужно сделать

• maxEffortLevel: установите, если у вас есть требования по управлению стоимостью для развёртываний с моделями расширенного мышления. Гранулярность по моделям в modelSettings удобна для смешанных кластеров. Если расширенное мышление не используется — действий не требуется.
• --system-prompt-snapshot off: используйте в период активной итерации системного промпта; вернитесь к поведению по умолчанию, когда промпт стабилизируется.
• Аудит маркетплейса: если записи вашего маркетплейса содержат пути с обратными слэшами, проведите аудит немедленно. Исправление есть в 2.1.267; до этого выпуска такие записи проходили проверку контейнера.
• Обновление для стабильности кэша: если промах кэша промптов является проблемой стоимости, 2.1.267 — существенное улучшение. Изменений конфигурации не требуется; исправления работают на уровне поведения.