Інженер компанії OpenAI Майкл Болін опублікував детальний технічний розбір того, як усередині працює Codex CLI — агентний інструмент для програмування, який може писати код, запускати тести та виправляти помилки під наглядом людини.
AI-агенти для програмування переживають свій «момент ChatGPT». Такі інструменти, як Claude Code з Opus 4.5 та Codex із GPT-5.2, досягли нового рівня практичної корисності — вони дозволяють швидко створювати прототипи, інтерфейси та генерувати шаблонний код. Публікація OpenAI з’явилася саме в той момент, коли AI-агенти починають перетворюватися на інструменти щоденної роботи.
Водночас ці системи залишаються суперечливими для частини розробників. Раніше OpenAI повідомляла, що використовує Codex для розробки самого Codex. Практичний досвід показує, що такі агенти надзвичайно швидкі в простих завданнях, але залишаються крихкими за межами навчальних даних і потребують постійного людського контролю в продакшені. Загальний каркас проєкту створюється швидко, однак деталізація вимагає тривалого налагодження та обходу обмежень, які агент не може подолати самостійно.
Болін не уникає цих інженерних проблем. У матеріалі він описує:
• неефективність квадратичного зростання промптів;
• втрати продуктивності через cache miss;
• виявлені баги, зокрема неконсистентну нумерацію MCP-інструментів, які довелося виправляти.
Такий рівень технічної відкритості є нетиповим для OpenAI. Компанія зазвичай не публікує детальних описів внутрішньої роботи таких продуктів, як ChatGPT. Водночас програмування, за словами OpenAI, є сферою, яка особливо добре підходить для великих мовних моделей.
Варто зазначити, що і OpenAI, і Anthropic відкривають вихідний код своїх CLI-клієнтів для програмування на GitHub, дозволяючи розробникам безпосередньо вивчати реалізацію. Водночас вебінтерфейси ChatGPT і Claude залишаються закритими.
Як працює агентний цикл Codex
У центрі Codex знаходиться agent loop — логіка, що керує взаємодією між користувачем, AI-моделлю та інструментами. Агент приймає запит користувача, формує текстовий промпт і надсилає його до Responses API, яка виконує інференс моделі.
Модель або повертає відповідь користувачу, або запитує виклик інструмента — наприклад, запуск shell-команди чи читання файлу. Якщо відбувається виклик інструмента, агент виконує його, додає результат до промпту і повторно звертається до моделі. Цикл повторюється доти, доки модель не припиняє виклики інструментів і не формує фінальне повідомлення.
Початковий промпт формується з кількох компонентів із різними рівнями пріоритету: system, developer, user і assistant. Він включає інструкції з конфігураційного файлу або базові налаштування CLI, перелік доступних інструментів (shell-команди, планування, вебпошук, MCP-сервери), контекст середовища виконання та запит користувача.
Кожна нова ітерація включає повну історію попередніх повідомлень і викликів інструментів. Codex не використовує параметр previous_response_id, тому кожен API-запит є повністю статeless — уся історія передається щоразу заново. За словами Боліна, це спрощує роботу API та підтримує сценарії Zero Data Retention, коли OpenAI не зберігає дані користувача.
Таке квадратичне зростання промптів є неефективним, однак його частково компенсує кешування. Cache hit можливий лише за повного збігу префікса промпту, тому будь-яка зміна інструментів, моделі або sandbox-конфігурації може призвести до втрати кешу й падіння продуктивності.
Коли кількість токенів перевищує допустимий поріг, Codex автоматично стискає контекст розмови. Для цього використовується спеціальний API-ендпоінт, який зберігає стисле «розуміння» попередніх подій у зашифрованому вигляді. Раніше цей процес був ручним, але зараз відбувається автоматично.
Болін зазначає, що в наступних матеріалах планує розповісти про архітектуру CLI, реалізацію інструментів та модель sandbox-ізоляції Codex.
Читайте на ProIT: Codex-Max працює годинами без втручання.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
