Claude Code 2.1.202: атрибуты OTel для workflow и контроль динамического масштаба меняют подход к управлению мультиагентными запусками

Changelog Claude Code 2.1.202 выглядит как обычный технический релиз, однако среди исправлений скрываются два изменения, принципиально важных для операторов: новые атрибуты OpenTelemetry на уровне workflow и пользовательский контроль над динамическим масштабом workflow. Оба изменения меняют то, как инженерные команды могут управлять и наблюдать за мультиагентными оркестровочными запусками.

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

Claude Code 2.1.202 вносит три ключевых изменения для команд, запускающих динамические workflow в продакшне:

1. Настройка динамического размера workflow — в /config появился новый параметр, позволяющий задать рекомендуемый размер (small / medium / large по числу агентов), которым руководствуется Claude при принятии решения о количестве sub-agent'ов. В примечаниях к релизу явно указано: это рекомендация, а не жёсткое ограничение. Тем не менее это первый случай, когда подобный выбор оформлен как настраиваемый параметр, а не скрыт в системном промпте.

2. Атрибуты workflow.run_id и workflow.name в OTel — вся телеметрия, генерируемая агентами внутри workflow, теперь содержит эти два новых поля. Операторы, использующие OpenTelemetry collector, получают возможность связать каждый вызов инструмента, запрос к модели и событие расхода токенов с конкретным именованным запуском workflow — без ручного сшивания деревьев span.

3. Исправление ротации mTLS — устранены транзитные сбои handshake при обновлении клиентского сертификата «на лету». Это важно для операторов, запускающих Claude Code за mutual-TLS шлюзом или корпоративным прокси с краткосрочными сертификатами.

Из прочих исправлений надёжности: /review <pr> возвращён к быстрому однопроходному режиму (мультиагентное ревью теперь через /code-review <level> <pr#>), устранено длительное восстановление фоновых сессий в репозиториях с большим числом worktree, а также исправлен бесконечный цикл повторных попыток голосового ввода при сбое микрофона.

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

С момента появления динамических workflow в версии 2.1.160 — когда Claude самостоятельно пишет и выполняет оркестровочные скрипты, распределяя задачи между десятками sub-agent'ов — эта функция оставалась наименее прозрачной частью Claude Code с операционной точки зрения. Расход токенов в крупном workflow-запуске сложно предсказать и ещё сложнее атрибутировать постфактум.

Два изменения в 2.1.202 решают обе проблемы с разных сторон:

Рекомендация по размеру как операторский рычаг управления. Раньше количество sub-agent'ов в workflow определялось исключительно моделью. Новая настройка small/medium/large предоставляет операторам задокументированный способ управлять совокупным параллелизмом — особенно важный там, где бюджет API, rate limits или квоты provider не позволяют выдержать высокую параллельную нагрузку. Это не жёсткий лимит, но это предпочтение, которое сохраняется при переписывании промптов и смене контекста.

Атрибуты OTel workflow как слой атрибуции расходов. workflow.run_id — это стабильный идентификатор, объединяющий все span'ы одного выполнения workflow. workflow.name привязан к человекочитаемой метке. Для команд, которым нужно распределять затраты на API по проектам, клиентам или тикетам, эти два атрибута превращают телеметрию workflow из инструмента отладки в слой атрибуции расходов — при условии, что AI gateway передаёт данные OTel, а pipeline учёта затрат умеет их потреблять.

Исправление mTLS — меньший, но важный сигнал надёжности: Anthropic активно усиливает интеграционную поверхность Claude Code с gateway, а не оставляет пограничные TLS-сбои в категории известных проблем.

Анализ с позиции router/operator

Динамические workflow создают routing-проблему, которую большинство операторов решают неудовлетворительно: запросы от sub-agent'ов к модели неотличимы на уровне gateway — один и тот же API key, одна и та же модель, никакого контекста о принадлежности к workflow. С появлением workflow.run_id в OTel корректно настроенный gateway получает возможность:

• Принудительно применять бюджеты токенов на уровне workflow — останавливать вышедший из-под контроля workflow, уже исчерпавший свою квоту, не прерывая несвязанные сессии на том же ключе.
• Атрибутировать затраты по именам workflow — разбивать расходы на API по типу workflow, а не только по пользователю или команде.
• Аудировать поведение sub-agent'ов — восстанавливать точную последовательность вызовов инструментов и запросов к модели в рамках workflow-запуска, привязанную к стабильному run ID.

Рекомендация по динамическому размеру добавляет взаимодополняющий контроль на входе: если ваш gateway применяет ограничение по параллелизму, настройка Claude на «small» workflow снижает коэффициент burst ещё до того, как запросы дойдут до provider.

По исправлению mTLS: если ваша команда запускает Claude Code за корпоративным mutual-TLS прокси с краткосрочными сертификатами, следует обновиться до 2.1.202 до следующего окна ротации. В предыдущих версиях возможны были молчаливые сбои в период handshake.

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

Атрибуты OTel workflow создают ценность только при их фактическом сборе в pipeline наблюдаемости. Проверьте, настроен ли ваш AI gateway или OTel collector на передачу атрибутов span от экспортёра Claude Code — если да, после обновления до 2.1.202 workflow.run_id и workflow.name начнут автоматически появляться в ваших trace-данных.

По настройке размера workflow: если вы работаете на тарифных планах с ограниченными rate limits или сталкивались с пиками расхода токенов в крупных workflow-запусках, установите параметр динамического размера в /config на small или medium. Это не гарантия, но это стабильная отправная точка для поведения модели.

Если ваша команда оценивает варианты управления затратами на мультиагентные workflow, комбинация рекомендации по размеру и OTel-атрибуции в 2.1.202 — это наиболее близкое к нативной наблюдаемости workflow, что Claude Code выпустил на сегодня. Построить слой учёта затрат сейчас, до того как workflow станут стандартной практикой для команды, проще, чем ретроактивно внедрять его позже. В документации TheRouter описано, как подключить собственный OTel collector для атрибуции на уровне gateway.