OpenAI Codex Multi-Agent v2: пер-тредовая маршрутизация runtime и что это меняет для операторов AI-шлюза

OpenAI Codex CLI 0.137.0, выпущенный 4 июня 2026 г., вводит multi-agent v2 с пер-тредовой маршрутизацией runtime — изменение, при котором каждый порождённый sub-agent несёт собственный выбор модели и provider вместо наследования единого глобального endpoint. Для инженерных команд, маршрутизирующих coding-агентов через AI-шлюз, этот архитектурный сдвиг означает, что решения о маршрутизации переходят с уровня сессии на уровень треда. В сочетании с новыми корпоративными лимитами кредитов, облачными config bundle и машиночитаемым выводом каталога плагинов обновление меняет способ управления cost attribution, выбором provider и governance в multi-agent-развёртываниях Codex.

Что изменилось в OpenAI Codex Multi-Agent v2

Changelog Codex CLI 0.137.0 содержит несколько изменений, непосредственно значимых для операторов:

Multi-agent v2 (PRs #25266, #25636, #25720–25722, #25841, #26114) — ключевое обновление релиза. Раньше все sub-agent'ы, порождённые из родительской сессии Codex, наследовали runtime-конфигурацию родителя: ту же модель, тот же provider endpoint, ту же approval policy. В v2 каждый тред сохраняет собственный выбор runtime. При порождении sub-agent'а дочерний процесс наследует дефолты родителя, но может независимо переопределить модель, provider или sandbox — формируя пер-тредовое дерево routing-решений вместо плоского session-wide назначения.

Корпоративные лимиты кредитов (PRs #24812, #24617–24620, #24622, #25963): ежемесячные лимиты расходов теперь задаются на уровне типа seat с возможностью переопределения для конкретного пользователя. Администраторы workspace Business и Enterprise могут устанавливать разные потолки для Codex-seat и ChatGPT-seat. Облачные config bundle позволяют централизованно раздавать командам конфигурации provider и модели без настройки на каждом устройстве.

Remote-control RPC (PRs #25675, #25785): клиенты удалённого управления теперь могут инициировать паринг, перечислять и отзывать разрешения контроллеров через app-server v2 RPC. Это новая governance-поверхность: организации, запускающие Codex в общих средах, теперь программно управляют тем, кто контролирует какого агента.

Машиночитаемый вывод плагинов (codex plugin list --json, PRs #25330, #25457): CI-пайплайны и инструменты автоматизации могут теперь перечислять доступные плагины без парсинга терминального вывода. Для команд, строящих внутренние платформы поверх Codex, инвентаризация плагинов становится программируемой.

Расширение hosted web и image tools в большее число code-mode потоков (PRs #25176, #25702, #25890, #25923): автономные веб-поиски теперь выполняются параллельно — sub-agent'ы Codex могут вести поиск в сети одновременно, а не последовательно.

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

Переход от session-wide к per-thread выбору модели имеет конкретное следствие для команд, маршрутизирующих coding-агентов через routing-шлюз: гранулярность маршрутизации возрастает на порядок.

До multi-agent v2 настройка Codex для работы через AI-шлюз означала, что все sub-agent'ы сессии обращались к одному и тому же model endpoint. Шлюз применял правила маршрутизации на уровне сессии — «маршрутизировать Codex-запросы на gpt-5 с fallback на deepseek-v4» — и все треды следовали одному пути.

В v2 каждый порождённый тред sub-agent'а может нести собственный идентификатор модели. Родительский агент, оркестрирующий сложную задачу, может породить:

• Sub-agent планирования, маршрутизированный к модели с оптимизированным рассуждением (например, gpt-5 или claude-opus-4)
• Sub-agent генерации кода, маршрутизированный к быстрой экономичной модели (например, deepseek-v4-flash или gpt-5-mini)
• Sub-agent ревью кода, маршрутизированный к другому provider для разнообразия (например, claude-opus-4 для adversarial-ревью)

Для операторов, управляющих provider routing, это означает три вещи:

1. Логика fallback должна быть тред-осведомлённой. Правило уровня шлюза «если provider X недоступен, переключиться на Y» по-прежнему работает, но cost attribution и отслеживание latency SLA теперь требуют тред-уровневого контекста. Каждый тред sub-agent'а — это отдельная единица биллинга и надёжности.

2. Лимиты кредитов взаимодействуют с числом тредов. Корпоративные лимиты по типу seat и пользователю, плюс разные ценовые точки для разных моделей в каждом треде, делают прогнозирование стоимости multi-agent-сессий нелинейным. Сессия, порождающая 6 параллельных sub-agent'ов через 3 разных модели, создаёт 6 независимых цепочек расхода кредитов.

3. Config bundle распространяются иначе. Облачные config bundle позволяют администраторам централизованно раздавать настройки, но пер-тредовые runtime-переопределения означают, что отдельные треды могут отклоняться от заданной администратором политики маршрутизации. Операторам необходима видимость: соблюдают ли порождённые sub-agent'ы централизованную конфигурацию.

Оператор-угол: что меняется на уровне routing-шлюза

С точки зрения routing-слоя, Codex multi-agent v2 создаёт три новых операционных задачи для команд, использующих multi-provider routing:

Маппинг сессия-тред. Традиционные AI-шлюзы отслеживают запросы на уровне сессии: одна сессия, одна routing-политика, одна fallback-цепочка. При пер-тредовом выборе runtime одна сессия Codex может порождать множество параллельных запросов к разным provider'ам. Шлюзу необходимо поддерживать тред-уровневое состояние маршрутизации внутри контекста сессии.

Гранулярность cost attribution. Когда каждый тред sub-agent'а выбирает собственную модель, биллинговая сверка должна атрибутировать затраты по тредам, а не по сессиям. Корпоративным командам, запускающим Codex через общий routing-шлюз, нужны записи request ledger, различающие тред-оркестратор и каждого порождённого sub-agent'а с указанием использованных модели и provider.

Сигналы здоровья provider на уровне треда. Если порождённый sub-agent маршрутизируется на provider A и получает timeout, routing-слой не должен помечать provider A как недоступный для всей сессии. Пер-тредовая маршрутизация означает, что сигналы здоровья и логика повторных попыток нуждаются в тред-скоуп-контексте, чтобы не реагировать избыточно на сбой одного sub-agent'а.

Чеклист оператора для Codex Multi-Agent v2

• Проверьте, поддерживает ли ваш шлюз параллельный multi-provider routing в рамках одной сессии. Если routing-слой предполагает «одна сессия = один provider», multi-agent v2 обнажит это допущение при одновременном поступлении cross-provider запросов.

• Обновите cost attribution с учётом тред-уровневых метаданных. Codex v2 передаёт parent_thread_id в порождённых агентах — используйте для иерархического биллинга, различающего оркестратор и sub-agent'ов.

• Протестируйте поведение fallback при смешанных provider sub-agent'ах. Породите сессию с sub-agent'ами, маршрутизированными на 2–3 разных provider, затем смоделируйте отказ одного. Убедитесь, что шлюз выполняет пер-тредовый failover без каскадных сбоев в соседних тредах.

• Проведите аудит распространения config bundle. Если организация использует облачные config bundle, убедитесь, что пер-тредовые runtime-переопределения намеренны, а не являются случайным дрейфом от централизованной конфигурации.

• Программируйте каталог плагинов. Используйте codex plugin list --json в CI-пайплайнах для верификации доступных плагинов и инструментов перед запуском Codex-сессий, особенно в governance-чувствительных развёртываниях.

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

TheRouter поддерживает OpenAI-compatible multi-provider routing, и Codex-трафик проходит через тот же путь запроса, что и другие OpenAI-compatible клиенты. С multi-agent v2 ключевые изменения таковы:

• Пер-тредовая маршрутизация модели работает из коробки. Routing-политики TheRouter применяются пер-запрос, а не пер-сессия, поэтому каждый тред sub-agent'а Codex автоматически получает независимое routing-решение — никаких session-affinity ограничений, препятствующих пер-тредовому выбору provider.

• Записи request ledger фиксируют тред-уровневый контекст. Каждый запрос sub-agent'а Codex порождает независимую запись ledger с указанием модели, provider, латентности и числа токенов — обеспечивая тред-уровневую cost attribution без кастомной инструментации.

• Fallback-политики применяются пер-тред. Если предпочтительный provider порождённого sub-agent'а недоступен, для этого конкретного треда запускается fallback-цепочка без воздействия на соседние треды или родительский оркестратор.

Для команд, исследующих multi-agent-развёртывания Codex, документация TheRouter по multi-provider routing и request ledger охватывает паттерны маршрутизации и cost attribution, значимость которых multi-agent v2 существенно повысил.