Agent Router Codex: policy lanes для долгих AI-задач

Новое исследование OpenAI о Codex важно не как рассказ о продуктивности, а как предупреждение для архитектуры. Когда agents переходят от коротких ответов в чате к делегированным задачам, API operations должны управлять длительностью, параллелизмом, идентичностью и cost attribution. Маршрутизируется уже не один model call, а задача, которая может идти минуты или часы, вызывать tools, работать с файлами и создавать бизнес-риск за пределами engineering-команды.

Что изменилось

OpenAI опубликовала экономический материал «How agents are transforming work» на основе adoption Codex среди individual users, organizational users и собственной рабочей силы OpenAI. Данные достаточно конкретные: к маю 2026 г. 80.6% sampled individual users сделали хотя бы один Codex request, оцененный как более 30 минут человеческой работы; 70.2% — request более чем на час; 25.6% — request более чем на восемь часов.

Внутри OpenAI Codex перешёл из coding tool в основную рабочую поверхность для AI. Компания пишет, что каждый отдел теперь использует Codex как primary AI tool, включая Legal, Finance и Recruiting. Для среднего сотрудника OpenAI Codex даёт более 85% output tokens, а в общем внутреннем weekly output tokens его доля заявлена как 99.8%. Non-developer adoption рос особенно быстро: с августа 2025 г. число non-developer users выросло в 137 раз у individual users, в 189 раз у organizational users и в 12 раз внутри OpenAI.

Самая важная операционная деталь — concurrency. OpenAI сообщает, что к июню 2026 г. пользователи в 99-м перцентиле регулярно генерировали более 60 часов Codex agent turns в день, распределённых между несколькими parallel agents. Это уже не chat workflow, а небольшой agent fleet.

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

Исследование даёт практический сигнал командам, которые внедряют Codex, Claude Code, Cursor, Kimi Code или другие agentic workbenches: спрос на agents не останется внутри developer org. Как только инструмент может превращать хаотичные файлы, повторяемый анализ и лёгкую automation в готовую работу, им начнут пользоваться legal, finance, recruiting, support и operations.

Из-за этого меняется задача контроля. Coding team часто может принять high-context model, широкий доступ к repository и большой token burn, потому что результат проходит review в PR. Workflow для recruiting или finance может требовать более строгого file access, меньшего data-retention risk, явного human approval и другого budget owner. Если оба workflow используют один provider key и один default model, компания не сможет чисто ответить, кто потратил деньги, какие задачи требовали premium routing и какие tool calls пересекли policy boundary.

Меняется и capacity planning. Long-horizon tasks создают очереди, retries и всплески parallel work. Provider outage или rate-limit event в середине часового agent run дороже, чем неудачный chat completion: он может потерять промежуточную работу, контекст или оставить business process незавершённым.

Взгляд со стороны роутинга и эксплуатации

Router decision должен перейти от вопроса «какая model лучшая?» к вопросу «какой task class заслуживает какую execution lane?». Практичная policy имеет как минимум четыре измерения.

Во-первых, routing по длительности задачи. Short Q&A, 30-минутная delegated work и многочасовой agent run не должны иметь одинаковые timeout, retry и fallback assumptions. Во-вторых, routing по blast radius. Read-only synthesis может использовать более широкий fallback, а задачи, которые пишут files, открывают PR или трогают private business data, требуют более жёстких provider и tool constraints. В-третьих, routing по budget department. Legal analysis agent и CI repair agent могут оба использовать Codex-style execution, но их cost centers и audit trail должны различаться. В-четвёртых, routing по statefulness. Если agent session накапливает memory, checkpoints или environment state, fallback — это уже не второй model call, а continuation strategy.

Здесь OpenAI-compatible routing layer становится больше, чем удобной обёрткой. Команды, которые используют TheRouter docs, должны рассматривать agent work как governed workload: разделять API keys или virtual providers по team, маркировать traffic по task class, делать fallbacks явными и сверять costs после run, а не только считать tokens в момент request.

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

Используйте цифры OpenAI как stress test для собственного agent rollout. Если non-developers в вашей компании увеличат использование agents в 100 раз, сможет ли gateway ответить на эти вопросы?

• Какой отдел владеет spend для parallel agent run?
• Какие task classes могут fallback на более дешёвого provider, а какие должны оставаться у конкретного provider из-за quality, privacy или tool compatibility?
• Что происходит, если long-running agent через 45 минут упирается в provider limit?
• Можете ли вы отделить read-only synthesis от workflows, которые пишут code, редактируют documents или вызывают external systems?
• Хранят ли logs достаточно request, tool и user context для debug результата без раскрытия sensitive files?

Следующая волна agent adoption будет меньше похожа на покупку дополнительных chat seats и больше — на эксплуатацию fleet. Победят не те команды, которые просто дадут каждому сотруднику самую сильную model. Победят те, кто определит lanes для long-horizon work, привяжет к ним budgets и approvals и сделает provider fallback видимым до того, как придёт первый неконтролируемый agent bill.