Самое недооценённое с DevDay: harness Codex открыт, и его можно встраивать к себе 🧩
Все обсуждают dots и новые модели. А мне как человеку, который внедряет AI SDLC в компаниях, интереснее другое. На DevDay OpenAI отдельно подчеркнула, что Codex, Work и dots работают на одном harness. Он лежит в open source, и теперь его можно запускать ещё и в их облаке.
Что такое harness. Это всё, что вокруг модели: агентный цикл, работа с контекстом, вызов тулов, песочница, апрувы человека, перенос работы между шагами. Код здесь: github.com/openai/codex
Почему это важно. Обвязка влияет на результат не меньше, чем модель. У OpenAI есть наглядный пример: на ARC-AGI-3 GPT-5.6 Sol вырос с 13.3% до 38.3% только за счёт сохранения reasoning и компакции контекста. Выходных токенов при этом стало в 6 раз меньше. Модель та же, обвязка другая, и результат втрое лучше и дешевле.
Как встроить, три уровня:
▫️ codex exec. Неинтерактивный запуск для скриптов и CI-джоб со структурированным выводом. Ревью MR, генерация тестов, разбор упавшего пайплайна прямо в CI.
▫️ Codex SDK. Запуск, продолжение и стриминг агентных задач из своего кода.
▫️ app-server. Для случаев, когда агент становится частью продукта: держит диалоги, стримит события, обрабатывает апрувы. UI, MCP-тулы и правила твои, агентный цикл их.
Главная мысль, под которой подпишусь: не надо загонять людей в очередной чат с ИИ. Агента нужно встраивать туда, где работа уже идёт: в дашборды, очереди, таск-борды. Перевёл задачу в Ready, и агент начал реализацию. Так и выглядит зрелый AI SDLC.
Кто уже так делает. GitHub и JetBrains встроили Codex в IDE, Cisco использует SDK в своём App Builder. В налоговом пилоте Thrive обработали 7000 деклараций и сократили время подготовки примерно на треть.
🔒 А что с закрытым контуром?
Открыт harness, а не модель. Но Codex умеет работать с кастомными провайдерами: в config.toml указываешь свой base_url и подключаешь внутренние Qwen или DeepSeek.
Нюанс, на котором спотыкаются многие: с февраля Codex говорит только на Responses API. «OpenAI-совместимость» в привычном смысле /chat/completions не подойдёт, и Codex будет стучаться в несуществующий маршрут. Нужен шлюз, который умеет новый формат.
У многих в контуре перед моделями как раз стоит LiteLLM, а он поддерживает Responses API. Выглядит как готовое решение: Codex смотрит в LiteLLM, LiteLLM в во внутренние open-source модели - всё внутри периметра. Скоро прогоню на реальных задачах и расскажу, что получилось.
Что это даёт: не нужно писать свой агентный рантайм. Песочница, апрувы, компакция контекста, MCP и стриминг событий уже есть, а codex exec встраивается прямо в CI.
Чего не стоит ждать: harness отлажен под модели OpenAI. На Qwen и DeepSeek качество tool calling и длинных сессий может просесть, поэтому мерить надо на своих задачах, а не верить на слово. И отключите встроенный веб-поиск, в закрытом контуре он ни к чему.
Даже если строите на другом стеке, как референсную архитектуру агентного рантайма это стоит изучить.
Кто уже подключал Codex к своим моделям через шлюз? Делитесь в комментах 👇
Все обсуждают dots и новые модели. А мне как человеку, который внедряет AI SDLC в компаниях, интереснее другое. На DevDay OpenAI отдельно подчеркнула, что Codex, Work и dots работают на одном harness. Он лежит в open source, и теперь его можно запускать ещё и в их облаке.
Что такое harness. Это всё, что вокруг модели: агентный цикл, работа с контекстом, вызов тулов, песочница, апрувы человека, перенос работы между шагами. Код здесь: github.com/openai/codex
Почему это важно. Обвязка влияет на результат не меньше, чем модель. У OpenAI есть наглядный пример: на ARC-AGI-3 GPT-5.6 Sol вырос с 13.3% до 38.3% только за счёт сохранения reasoning и компакции контекста. Выходных токенов при этом стало в 6 раз меньше. Модель та же, обвязка другая, и результат втрое лучше и дешевле.
Как встроить, три уровня:
▫️ codex exec. Неинтерактивный запуск для скриптов и CI-джоб со структурированным выводом. Ревью MR, генерация тестов, разбор упавшего пайплайна прямо в CI.
▫️ Codex SDK. Запуск, продолжение и стриминг агентных задач из своего кода.
▫️ app-server. Для случаев, когда агент становится частью продукта: держит диалоги, стримит события, обрабатывает апрувы. UI, MCP-тулы и правила твои, агентный цикл их.
Главная мысль, под которой подпишусь: не надо загонять людей в очередной чат с ИИ. Агента нужно встраивать туда, где работа уже идёт: в дашборды, очереди, таск-борды. Перевёл задачу в Ready, и агент начал реализацию. Так и выглядит зрелый AI SDLC.
Кто уже так делает. GitHub и JetBrains встроили Codex в IDE, Cisco использует SDK в своём App Builder. В налоговом пилоте Thrive обработали 7000 деклараций и сократили время подготовки примерно на треть.
🔒 А что с закрытым контуром?
Открыт harness, а не модель. Но Codex умеет работать с кастомными провайдерами: в config.toml указываешь свой base_url и подключаешь внутренние Qwen или DeepSeek.
Нюанс, на котором спотыкаются многие: с февраля Codex говорит только на Responses API. «OpenAI-совместимость» в привычном смысле /chat/completions не подойдёт, и Codex будет стучаться в несуществующий маршрут. Нужен шлюз, который умеет новый формат.
У многих в контуре перед моделями как раз стоит LiteLLM, а он поддерживает Responses API. Выглядит как готовое решение: Codex смотрит в LiteLLM, LiteLLM в во внутренние open-source модели - всё внутри периметра. Скоро прогоню на реальных задачах и расскажу, что получилось.
Что это даёт: не нужно писать свой агентный рантайм. Песочница, апрувы, компакция контекста, MCP и стриминг событий уже есть, а codex exec встраивается прямо в CI.
Чего не стоит ждать: harness отлажен под модели OpenAI. На Qwen и DeepSeek качество tool calling и длинных сессий может просесть, поэтому мерить надо на своих задачах, а не верить на слово. И отключите встроенный веб-поиск, в закрытом контуре он ни к чему.
Даже если строите на другом стеке, как референсную архитектуру агентного рантайма это стоит изучить.
Кто уже подключал Codex к своим моделям через шлюз? Делитесь в комментах 👇