OpenAI Codex 0.143: Token-бюджеты и политика делегирования мультиагентов закрывают пробел в управлении для операторов

Codex 0.143.0 добавляет настраиваемые rollout token-бюджеты, политику многоагентного делегирования на уровне потока и ограниченный веб-поиск по белому списку URL — три механизма управления, которых операторам не хватало с момента перехода Codex в мультиагентный режим.

TheRouter Newsroomисточник OpenAI Codex
Абстрактная схема управляемых token-бюджетных потоков и шлюзов политики делегирования для мультиагентного управления Codex

Когда OpenAI Codex стал мультиагентным, недостающим элементом оказался не доступ к моделям — а контроль расходов и управление правами делегирования на стороне оператора. Codex 0.143.0, выпущенный 22 июня, закрывает этот пробел тремя production-механизмами: rollout token-бюджеты, отслеживающие и ограничивающие расходы по всем агентным потокам; политика мультиагентного делегирования, позволяющая операторам app-server выбирать точный уровень автономии субагентов; и режим индексированного поиска, ограничивающий прямой доступ к страницам одобренными сервером URL. Для команд, использующих Codex через AI gateway или операторный стек, это не постепенные улучшения — это переосмысление того, кто и чем управляет.

Что изменилось в Codex 0.143.0

Rollout token-бюджеты. Клиенты app-server теперь могут настраивать token-бюджет, который отслеживает использование по всем агентным потокам сессии, отправляет модели напоминания об остатке бюджета и автоматически прерывает ход выполнения при исчерпании лимита. Бюджет охватывает полный граф агентных потоков — не только корневой ход, — поэтому потребление токенов субагентами суммируется под единым ограничением. Модель получает напоминания об остатке бюджета в середине сессии, что позволяет ей скорректировать стратегию до достижения предела, а не быть прерванной в середине задачи.

Политика мультиагентного делегирования. Клиенты app-server могут задавать режим делегирования disabled, explicit-request-only или proactive отдельно на уровне потока и на уровне хода. В режиме disabled Codex не порождает субагентов вне зависимости от сложности задачи. В explicit-request-only субагенты порождаются только по явному запросу пользователя. В proactive Codex самостоятельно решает, когда делегирование субагенту уместно для данного хода. Такая гранулярность — независимые настройки для потока и хода — означает, что оператор может разрешить проактивное делегирование при исследовании, но принудительно установить explicit-request-only при записи в защищённые ветки.

Режим индексированного веб-поиска. Новая конфигурация поиска позволяет ограничить прямой доступ к страницам белым списком URL, одобренным сервером, при этом сохраняя возможность выполнять запросы. Это разграничивает «может искать» и «может посещать любой URL» — значимое различие для операторов, которые хотят, чтобы агенты были осведомлены о веб-контексте, но не имели доступа к произвольным сайтам.

Устойчивость exec-server. Процессы exec-server и сессии stdio MCP теперь переживают кратковременные разрывы соединения, включая обновление подписанных URL и retry-безопасные операции записи в stdin. Удалённые среды сохраняют нативные пути executor, оболочки, обнаружение AGENTS.md и поведение sandbox на разных операционных системах.

Улучшения плагинов. В релиз входят погашение кредитов через /usage, организованные разделы плагинов (куратируемые / рабочее пространство / общие) и снижение задержки при запуске за счёт отложенных DNS-операций, предварительного прогрева кэша модели и параллельного чтения метаданных навыков.

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

Управление бюджетом оставалось нерешённым операционным долгом в мультиагентных развёртываниях Codex. До версии 0.143.0 у platform-команд было два неудобных варианта: доверять самоограничению агентов или жёстко ограничивать использование на уровне учётных данных API — что не позволяет отличить одну длительную задачу от десятков параллельных потоков субагентов. Rollout token-бюджеты делают бюджет полноценным routing-сигналом: отслеживаемым в рамках сессии, отображаемым модели во время выполнения и принудительно применяемым на границе хода.

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

Индексированный поиск завершает триаду управления. Агент, который может искать, но посещать только предварительно одобренные URL, значительно проще проверить, чем агент с неограниченным доступом. Белый список контролирует оператор сервера, что позволяет предоставлять возможность веб-поиска широкой аудитории, ограничивая доступ на уровне браузера только проверенными сценариями.

Угол routing/operator

Эти три функции определяют матрицу управления, которая естественно отображается на слой AI gateway:

Маршрутизация по бюджету. Рассматривайте rollout token-бюджет как расходный конверт для каждой сессии, а не просто инструкцию для модели. На уровне gateway это должно сочетаться с отслеживанием затрат на уровне запроса, чтобы сигнал бюджета коррелировал с реальными строками счёта. Сессия, прерванная по исчерпании бюджета, должна генерировать событие расхода, а не молча завершаться по таймауту.

Маршрутизация по уровню делегирования. Сопоставьте режимы disabled / explicit-request-only / proactive с уровнями пользователей, степенью риска репозитория или этапом рабочего процесса. Путь записи в production-ветку должен по умолчанию использовать explicit-request-only; изолированная исследовательская сессия может применять proactive. Если ваш операторный стек поддерживает конфигурацию на уровне проекта, храните режим делегирования там, а не требуйте индивидуальной настройки от пользователей.

Маршрутизация URL-белого списка. Управляйте белым списком URL для индексированного поиска централизованно вместе с политиками API-ключей. Задавайте разрешения на уровне доменов, а не отдельных страниц — домен инструментов разработчика безопаснее общего белого списка, а домен внутренней документации безопаснее любого из них. Изменения белого списка следует рассматривать как изменения контроля доступа, а не просто правки конфигурации.

Устойчивость exec-server. Улучшения переподключения MCP-сессий в 0.143.0 означают, что длительные мультиагентные задачи реже завершаются аварийно из-за кратковременных сетевых проблем. Для gateway, проксирующих exec-server-соединения, это меняет расчёт error-бюджета: ошибки кратковременных разрывов теперь следует повторять на транспортном уровне до передачи в дашборд оператора.

Команды, использующие документацию TheRouter для routing и управления, должны добавить настройку политики делегирования и token-бюджета в тот же файл политики, который регулирует выбор модели и поведение fallback. Это не отдельные темы — они относятся к единой конфигурационной поверхности оператора.

Чек-лист решений для операторской конфигурации Codex 0.143.0

Перед обновлением Codex в совместном операторском развёртывании проверьте следующее:

  1. Уровень token-бюджета: устанавливайте rollout token-бюджет для каждой сессии исходя из средней сложности задач, а не пиковых значений; оставляйте запас для накладных расходов субагентов.
  2. Режим делегирования по контексту: определите сопоставление disabled, explicit-request-only, proactive для основных категорий рабочих процессов — например, запись в защищённую ветку → explicit, read-only-аудит → proactive.
  3. Область URL-белого списка: перечислите домены, к которым агенты правомерно обращаются. Начните с документации и реестров пакетов; добавляйте общие поисковые домены только после проверки.
  4. Подключение событий бюджета: свяжите прерывания ходов по исчерпании бюджета с биллинговой системой, чтобы неудачные ходы атрибутировались, а не терялись.
  5. Политика переподключения exec-server: при проксировании exec-server-соединений настройте retry с экспоненциальной задержкой на транспортном уровне и подавляйте ложные оповещения о разрыве в окне переподключения.
  6. Политика переопределения на уровне хода: определите, могут ли отдельные пользователи переопределять режим делегирования потока на уровне хода; если да, требуйте записи в журнал аудита.

Codex 0.143.0 впервые делает мультиагентный Codex управляемым на операторском уровне. Token-бюджет, политика делегирования и URL-белый список совместно образуют минимальную, но достаточную control plane для оператора. Команды, интегрирующие эти механизмы в существующую конфигурацию gateway уже сейчас, получат более чёткий журнал аудита при следующем росте масштаба мультиагентной работы.

Дашборд атрибуции затрат по API-ключам с разбивкой по путям маршрутизации

Атрибуция затрат по API-ключам OpenAI теперь программируема: что должен изменить каждый оператор маршрутизации

4 августа OpenAI добавила измерение api_key в API использования и затрат. Для команд, использующих несколько ключей в одной организации, это закрывает главный пробел в атрибуции затрат по пути запроса — без создания отдельных организаций.

источник OpenAI
Редакционная диаграмма: иерархия проектов OpenAI, объявленная в файлах Terraform; ресурсы rate limit и model controls соединяются с routing-слоем шлюза

OpenAI выпускает официальный Terraform provider: IaC-управление платформой для команд AI-шлюзов

Официальный Terraform provider от OpenAI, выпущенный 29 июля, позволяет управлять проектами, сервисными аккаунтами, rate limit, контролем моделей и spend-алертами через код. Разбираем topology-паттерн для routing-слоя.

источник OpenAI
Дашборд маршрутизации, показывающий достижение жёсткого лимита расходов: API-запрос заблокирован, сигнал 429 insufficient_quota отображён в панели управления оператора

Жёсткие лимиты расходов OpenAI теперь блокируют API-запросы: что должен проверить каждый оператор шлюза

OpenAI добавил жёсткие месячные лимиты расходов: при превышении порога запросы возвращают 429 insufficient_quota. Для шлюзов это новый режим отказа — стандартная логика повторных попыток не справляется. Чек-лист для операторов.

источник OpenAI
Помощь и контакты