Claude Code проти Codex: сім протокольних відмінностей, на які ми натрапили, під'єднавши обидва рушії до однієї віддаленої системи

Розкриття інтересу: ми розробляємо PandaNpc — систему, яка дозволяє віддалено отримувати доступ до кодувальних агентів Claude Code, Codex тощо та використовувати їх кільком людям одночасно. Оскільки нам довелося підтримувати всі ці рушії на одній сторінці та в одному ланцюжку повідомлень, ми мусили вирівняти їхню протокольну поведінку один за одним. Ця стаття описує відмінності, на які ми фактично натрапили в цьому процесі, — це не порівняння бенчмарків: ми не проводили контрольних тестів, тож у статті не буде жодних цифр про швидкість, рівень успішності тощо. Подальші плани описано в кінці.

Примітка: Codex у цій статті означає інструмент командного рядка OpenAI Codex, а не інший продукт із такою самою назвою.

Підсумок одним реченням: якщо використовувати їх локально в терміналі, різниця в досвіді набагато менша, ніж ви очікуєте; але щойно ви під'єднуєте їх до власної системи (віддалене керування, синхронізація між пристроями, відновлення сесій, затвердження інструментів), майже всі відмінності зосереджені на рівні протоколу — і про ці відмінності ми тоді не могли дізнатися заздалегідь із документації: на всі з них ми натрапили лише на практиці.

Якщо ви шукаєте Codex vs Claude Code, щоб дізнатися, «який обрати», ця стаття, можливо, не той вид порівняння, який вам потрібен, — вона не порівнює, хто краще пише код, а відповідає на інше, конкретніше питання: з чим ви зіткнетеся, коли захочете інтегрувати їх як програмований бекенд.

Кому варто це прочитати

Розробникам, які хочуть підтримувати обидва рушії одночасно або перейти з одного на інший
Тим, хто хоче створювати периферійні інструменти на кшталт віддаленого керування / синхронізації між пристроями / спільних сесій
Тим, хто хоче знати, «у чому саме відрізняються моделі сесій цих двох CLI»

Якщо ви просто хочете писати код на власному комп'ютері й не плануєте інтеграцію, цінність цієї статті обмежена — швидше буде просто переглянути офіційну документацію обох.

Спочатку про спільне: чому вони «виглядають однаково»

Перш ніж говорити про відмінності, варто прояснити: ментальні моделі цих двох інструментів дуже схожі — обидва працюють у терміналі, обидва організовані навколо сесій, обидва можуть викликати інструменти для зміни файлів і виконання команд, обидва потребують підтвердження користувача для небезпечних операцій, обидва можуть безперервно обробляти багатокрокові завдання в межах однієї сесії. Саме тому під час інтеграції легко дійти висновку, що «досить написати один адаптаційний шар», — і саме так ми починали.

Відмінності не на рівні можливостей, а на рівні протоколу. Тобто поведінка, яку ви бачите в терміналі, може бути майже однаковою, але фрейми, які вони надсилають, їхній порядок і спосіб організації полів — різні. Саме тому такі відмінності важко виявити заздалегідь: використовуючи їх на власному комп'ютері, ви ніколи на них не натрапите.

Швидка довідкова таблиця семи відмінностей

#	Вимір	Поведінка Claude Code	Поведінка Codex	Кого «вкусить», якщо не обробити
1	Ідентифікатор повідомлень асистента	Має стабільний id	Може не мати	Тих, хто робить персистентність повідомлень / синхронізацію між пристроями
2	Перевірка живості сесії	Пакетна форма, одна група за раз	Очікує один id сесії	Тих, хто показує онлайн-статус
3	Порядок відтворення історії	Збігається з реальною хронологією	Фрейми активності підпотоків ідуть суцільним блоком у кінці	Тих, хто робить перегляд субагентів / багатопотокові перегляди
4	Структура команд виклику інструментів	Повна	Може бути фрагментованою	Тих, хто робить UI затвердження інструментів
5	Підписка на події каналу	Бере на себе роль виконавця перемикання сесій	Не може одночасно виконувати перемикання	Тих, хто робить багатоканальний relay
6	Квота онлайн-підключень	Спільний пул лічильників із Codex	Те саме	Тих, хто обмежує квоти
7	Продуктивність із довгою історією	Лінійна	За неправильної обробки деградує до нелінійної	Тих, хто робить мобільні застосунки

Нижче розглянемо кожну окремо, за схемою «симптом → як діагностувати → як виправити».

1. Чи мають повідомлення асистента стабільний id — це визначає вашу стратегію дедуплікації

Симптом: відкриваєте сесію Codex — щойно поспілкувавшись, усе нормально; якщо вийти й зайти знову, та сама відповідь асистента стає двома, трьома, і що більше заходів — то більше. Повідомлення користувача не страждають, розмножується лише відповідь асистента. У сесіях Claude Code цього не відбувається.

Як діагностувати: цей симптом дуже легко помилково сприйняти за проблему рендерингу на клієнті або дублювання під час завантаження історії, після чого пірнаєш у фронтенд. Правильний перший крок — подивитися, скільки записів насправді зберігається в кеші на сервері — якщо в кеші дійсно N записів, проблема на рівні даних, а не рендерингу. Саме цей крок тоді повернув нас із клієнтської сторони на правильний шлях.

Корінь проблеми: повідомлення асистента в Claude Code мають стабільний ідентифікатор, тож під час відтворення та в реальному часі їх можна дедуплікувати за id. Повідомлення асистента з боку Codex не гарантовано мають такий ідентифікатор, тож коли застосовується та сама логіка «дедуплікації за id», одна й та сама відповідь записується як два різні повідомлення.

Як виправити: для повідомлень без стабільного id використовуйте згортання за «якорем раунду + вмістом» — якір — це хеш найближчого повідомлення користувача перед цією відповіддю.

⚠️ Тут є пастка, про яку варто сказати окремо: наша перша версія згортала за чистим текстом, і після запуску, проглянувши історичні дані, ми виявили, що вона помилково видалила 691 однакову відповідь між різними раундами. Причина в тому, що короткі відповіді Codex мають надзвичайно високу повторюваність (наприклад, «Добре.», «Готово.»), а множина дедуплікації була на рівні сесії: щойно хеш якоїсь фрази запам'ятовувався, та сама фраза в будь-якому наступному раунді цієї сесії поглиналася. Це втрата вмісту, що серйозніше за дублювання. Рівень якоря не можна пропускати.

2. Перевірка живості: один очікує один запис, інший — пакет

Симптом: сесія насправді працює, але в інтерфейсі показується як офлайн.

Як діагностувати: ця відмінність дуже схожа на універсальну — назви полів з обох боків близькі, тож під час написання легко подумати, що один код впорається з обома. Спосіб перевірки простий: надішліть пакетну структуру й подивіться, чи повернення має форму, яку ви очікуєте.

Корінь проблеми: щоб визначити, «чи жива сесія», інтерфейси з обох боків мають різну форму. З боку Claude Code ми використовували пакетну форму — один виклик із групою id сесій; з боку Codex очікується один id сесії.

Як виправити: розділіть на два окремі шляхи викликів і не намагайтеся використовувати спільний. Сама по собі ця відмінність нескладна; проблема в тому, що вона не видає помилку: надсилання неправильної структури не викликає винятку, ви просто отримуєте семантично неправильну відповідь.

3. Різний порядок фреймів під час відтворення історії — стан субагента застрягає

Це найзаплутаніше місце в процесі діагностики.

Симптом: індикатор стану субагента на бічній панелі постійно пульсує оранжевим «виконується», хоча насправді він уже давно завершився або був перерваний. Оновлення сторінки не повертає його назад — щоразу після оновлення все повторюється. З'являється лише в сесіях Codex.

Як діагностувати: «оновлення не повертає назад» — ключовий критерій. Він показує, що проблема не в доставці в реальному часі, а в самому відтворенні історії — кожне відтворення щоразу заново записує неправильний стан.

Корінь проблеми: під час відтворення спочатку розкладаються всі записи батьківського потоку (зокрема фрейми-сповіщення «субагент завершився»), а потім фрейми активності кожного підпотоку додаються суцільним блоком у кінець. Тож клієнт отримує такий порядок: спочатку бачить сповіщення «перервано», а потім — фрейми активності, що хронологічно раніші. А логіка запису стану не порівнює часові мітки, тож останній прибулий блок раніших фреймів безумовно перезаписує кінцевий стан назад у «виконується».

Як виправити: додайте до гілки запису стану захисник кінцевого стану — стан, який уже є кінцевим (завершено/помилка/зупинено), може бути перезаписаний лише пізнішими фреймами. Зверніть увагу: критерій має використовувати той самий набір мапінгів станів, що й решта коду, — не пишіть окремий, інакше в двох місцях розуміння того, «що вважається кінцевим станом», розійдеться.

Спільна риса таких проблем: кожен окремий фрейм виглядає легітимним — помилковим є їхній відносний порядок. Тож, дивлячись лише на логи окремих фреймів, проблему ніколи не побачиш.

4. Структура команд виклику інструментів: може фрагментуватися

Симптом: у картках інструментів у сесії Codex команда відображається фрагментами на кшталт 1,220p або /pid=…/ {print}, іноді цілий скрипт розрізаний на частини, а іноді після завершення відповіді залишається купа незавершених карток інструментів.

Як діагностувати: дивіться на фактичну структуру поля команди в оригінальних фреймах, а не на результат рендерингу. Якщо ви за шляхом полів від Claude Code намагаєтеся отримати «яку команду виконав користувач», ви отримаєте розрізані фрагменти.

Як виправити**: напишіть для Codex окремий шар збирання команд, який склеює фрагменти в повну команду й лише тоді передає її в UI.

Ця відмінність особливо критична для тих, хто робить затвердження інструментів: користувач має натиснути «Дозволити / Відмовити» на телефоні, а команда на картці розірвана — це все одно що просити людину підписати наосліп. Коли функція безпеки втрачає сенс, це набагато серйозніше, ніж негарне відображення.

5. Різна поверхня підписки на події каналу

Симптом: два користувачі викидають одне одного з системи.

Корінь проблеми: якщо обидва relay-ланцюги підписані на події типу «перемикання сесії» й виконують їх, кожен бік викидає по одній жертві, утворюючи подвійне вигнання. Дія перемикання має мати єдиного виконавця.

Як виправити: ми зробили так, щоб ланцюг Codex підписувався лише на події викидання та інвалідації кешу й ніколи — на події перемикання, закріпивши право виконання перемикання за іншим ланцюгом.

Такі рішення «навмисно нічого не робити» зазвичай лишають у коді лише один рядок коментаря, але його додають уже після того, як на це наступили, — і щойно хтось пізніше «заодно доповнить» цю заборону, інцидент повториться. Тож у коментарі треба чітко пояснювати, чому цього не робиться, а не просто писати, що цього не робиться.

6. Квота та лічильник підключень об'єднані

Симптом: користувач думає, що квота ще є, а насправді її вже перевищено.

Корінь проблеми: якщо ви, як і ми, обмежуєте кількість онлайн-підключень, зверніть увагу: підключення обох рушіїв потрапляють в один спільний пул лічильників. Коли користувач тримає відкритими сесії Claude Code і Codex одночасно, вони споживають ту саму частку квоти.

Це не дефект, а дизайн-рішення: з погляду користувача «скільки всього сесій я можу відкрити одночасно» зрозуміліше, ніж «скільки можна відкрити для кожного рушія окремо». Але якщо ваша реалізація лічить окремо за рушіями, залишок, показаний у фронтенді, не збігатиметься з фактичним списанням на бекенді.

Як виправити: спочатку чітко визначте, яку семантику ви хочете, а потім переконайтеся, що фронтенд і бекенд використовують ту саму. Змішування двох семантик гірше, ніж обрана неправильна.

7. Різні характеристики продуктивності зі зростанням обсягу історії

Симптом: на мобільному застосунку відкриття сесії з довгою історією призводить до зависання.

Корінь проблеми: на iOS ми зіткнулися з помітним зависанням, причиною якого була операція обробки історії з квадратичним зростанням залежно від кількості повідомлень. Варто зазначити: це не проблема самого рушія, а наслідок невідповідності його структури історії нашому попередньому способу обробки — той самий спосіб обробки на іншому рушії себе не виявив.

Як виправити: замініть повторюване сканування, що зростає з кількістю повідомлень, на одноразовий індекс. Що важливіше — проєктуйте заздалегідь: довга історія має враховуватися з самого початку, а не тоді, коли користувач назбирає кілька тисяч повідомлень і проблему буде виявлено.

То що обрати?

Спершу зауважу: нижче — рекомендації з погляду інтеграції, а не оцінка здатності писати код. Ми не проводили контрольних тестів, тож жодне твердження на кшталт «хтось у стільки-то разів швидший» не походить із цієї статті.

Коли краще обрати Codex

Ваша команда вже в екосистемі OpenAI — акаунти, квоти та білінг в одному місці, на одну систему обліку й керування обліковими даними менше; цей виграш у зручності не варто недооцінювати.
Ваші процеси вже побудовані навколо його моделі сесій і завдань — рефакторинг периферійних інструментів заради міграції зазвичай невигідний; сім відмінностей вище, якщо розвернути, — це і є вартість міграції.

Коли краще обрати Claude Code

Ви плануєте створювати власні периферійні інструменти — з нашого досвіду інтеграції, стабільний ідентифікатор повідомлень робить персистентність і синхронізацію між пристроями набагато простішими; відмінності 1, 3 і 4 саме з цього боку обробляються легше.
Вам потрібна взаємодія на кшталт затвердження інструментів — структура команд повна, під час розробки UI затвердження не потрібне додаткове склеювання, а отже, не існує ризику «підпису наосліп».

Коли не обирати жоден

Якщо ваша мета — просто «змінити модель для тієї самої взаємодії», то краще змінити модельний бекенд, а не рушій. Частково саме тому ми створили PandaCode: шар взаємодії лишається незмінним, а модель замінюється.

Якщо ви мігруєте: обсяг змін, що відповідає семи відмінностям

Багато хто шукає ці дві назви, бо насправді оцінює: «якщо я вже користуюся одним, скільки коштуватиме перехід на інший». Нижче я переведу сім відмінностей вище у вартість міграції.

Варто зазначити: цей розділ — це обсяг змін, виведений із попередніх семи відмінностей, а не запис нашої повної міграції: наш шлях був «одночасне під'єднання», а не «перехід з одного на інший». Тож використовуйте це як контрольний список, а не як оцінку трудовитрат.

Під час міграції з Claude Code на Codex зміни зосереджені в таких місцях:

Логіку дедуплікації доведеться переписати (відмінність 1) — це найбільш недооцінюване місце. Наявний код дедуплікації за id не можна використати напряму, і до того ж помилка не подає жодного сигналу: вона просто мовчки додає або мовчки губить повідомлення. Якщо у вас є персистентність повідомлень, обов'язково продумайте, який якір брати, ще до міграції.
Перевірку онлайн-статусу треба змінити за формою виклику (відмінність 2) — обсяг роботи невеликий, але якщо це пропустити, буде «працює, а показує офлайн», і без жодного винятку.
Усе, що покладається на хронологію історії, треба перевірити заново (відмінність 3) — перегляд субагентів, індикатори прогресу, будь-яка логіка, що «визначає поточний стан з історії».
У UI затвердження інструментів треба додати шар збирання команд (відмінність 4) — якщо у вашому продукті є функція затвердження, цього не можна оминути, інакше це все одно що змушувати користувача підписувати наосліп.

Зворотний напрямок (з Codex на Claude Code) зазвичай простіший: дедуплікацію можна спростити назад до підходу за id, а для структури команд не потрібен шар збирання. Але зверніть увагу: не видаляйте сумісний шар, написаний для Codex, — якщо ви хочете зберегти можливість одночасної підтримки, ця логіка — актив, а не зобов'язання.

Те, що треба перепідтвердити в обох напрямках: семантика квоти (відмінність 6) і продуктивність із довгою історією (відмінність 7). Ці дві речі менш безпосередньо пов'язані з рушієм, але саме їх найлегше забути перетестувати після зміни рушія.

Одна порада: якщо ваша система вже в продакшені й має наявні дані сесій, перед міграцією спершу проженіть нову логіку на наявних даних для порівняння, не перемикайтеся напряму. Саме так ми отримали урок із тих 691 помилково видалених записів: сама логіка виглядала нормально, але коли ми прогнали історичні дані, виявилося, що вона поглинає вміст. Правильність нової логіки ≠ безпека для наявних даних.

Наш підхід: не обираємо, під'єднуємо обидва

Оскільки потрібно було підтримувати обидва рушії одночасно, наш фінальний висновок — поглинути відмінності в проміжному шарі: догори він відкриває уніфіковану модель повідомлень і сесій, донизу адаптується під кожен рушій. Ціна: щоразу, коли додається новий рушій, доводиться заново вирівнювати всі сім типів поведінки. Вигода: користувач може вільно перемикати рушії в одному інтерфейсі, а досвід роботи із сесіями, історією та затвердженням залишається однаковим.

Контрольний список для під'єднання нового рушія

Якщо ви теж плануєте цим шляхом, раджу перевіряти в такому порядку: перші чотири пункти визначають, чи взагалі працює, останні три — чи не станеться інцидентів у продакшені:

Ідентифікатор повідомлень — чи мають повідомлення асистента стабільний id? Якщо ні, то який ваш якір дедуплікації?
Живість сесії — інтерфейс перевірки живості приймає один запис чи пакет? Якщо надіслати неправильну структуру, буде помилка чи мовчазна неправильна відповідь?
Порядок відтворення історії — чи збігається порядок відтворених фреймів із реальною хронологією? Особливо коли є підпотоки.
Структура виклику інструментів — чи повне поле команди, коли ви його отримуєте? Чи може воно бути розрізаним?
Поверхня підписки на події — які події мають мати єдиного виконавця? Що станеться, якщо виконувати двічі?
Семантика квоти — лічильники окремі за рушіями чи об'єднані? Чи узгоджені фронтенд і бекенд?
Продуктивність із довгою історією — коли кількість повідомлень зростає вдесятеро, час обробки зростає лінійно чи швидше?

Для кожного пункту раджу спершу перевірити на малому обсязі даних, а потім — на великій історії — пункти 3 і 7 виявляються лише тоді, коли обсяг даних зростає.

Зворотний пошук за симптомом: на яку саме відмінність ви натрапили

Якщо ви вже наступили на граблі, зворотне виведення від симптому зазвичай швидше, ніж читання всієї документації:

Що ви бачите (симптом)	Ймовірно, це	Метод визначення за один крок
Після виходу й повторного входу відповідей асистента стає більше	Відмінність 1 (ідентифікатор повідомлень)	Подивіться, скільки записів у кеші на сервері, — одразу зрозуміло, це рівень даних чи рендерингу
Сесія працює, але показується як офлайн	Відмінність 2 (перевірка живості)	Перевірте, чи запит живості надсилає один запис чи пакетну структуру
Стан субагента застряг у «виконується», оновлення не повертає назад	Відмінність 3 (порядок відтворення)	«Оновлення не повертає назад» — це і є критерій: проблема у відтворенні, а не в доставці в реальному часі
Команда в картці інструмента розірвана / картки інструментів висять після завершення відповіді	Відмінність 4 (структура команди)	Дивіться на структуру поля команди в оригінальних фреймах, а не на результат рендерингу
Два користувачі викидають одне одного	Відмінність 5 (поверхня підписки)	Перевірте, чи два виконавці одночасно обробляють події перемикання
Фронтенд показує, що квота ще є, а бекенд уже перевищено	Відмінність 6 (семантика квоти)	Переконайтеся, чи фронтенд і бекенд лічать окремо за рушіями чи разом
Мобільний застосунок зависає під час відкриття довгої сесії	Відмінність 7 (довга історія)	Порівняйте час обробки на сесіях із подвоєною кількістю повідомлень і подивіться, чи залежність нелінійна

Універсальний критерій: якщо симптом стабільно відтворюється після кожного оновлення, проблема, найімовірніше, у відтворенні історії або на рівні даних; якщо він виникає лише зрідка під час інтерактивної взаємодії в реальному часі — тоді шукайте в ланцюгу доставки. Цей критерій не раз економив нам час: відмінності 1 і 3 спочатку помилково вважали клієнтськими проблемами.

Поширені запитання (FAQ)

Codex CLI і OpenAI Codex — це те саме?

Codex, про який йдеться в цій статті, — це інструмент командного рядка для кодування від OpenAI. На ринку є й інші продукти з назвою Codex (зокрема програмне забезпечення у сфері права та комплаєнсу), тож під час пошуку легко заплутатися; набагато точніше буде додати обмежувач «CLI» або «OpenAI».

Чи змінюються ці відмінності з версіями?

Так. Кожна з наведених відмінностей — це поведінка, на яку ми натрапили в конкретний момент часу, і обидва рушії швидко розвиваються. Тож важливішим є той контрольний список: конкретні відмінності можуть змінюватися, а виміри, які треба перевіряти, — майже ні.

Чи можна під'єднати обидва рушії одночасно?

Можна — саме так ми й зробили. Ключове — поглинути відмінності в проміжному шарі, а не дати їм просочитися в UI-шар, інакше з кожним новим рушієм логіка інтерфейсу розгалужуватиметься щоразу заново.

Подальші плани

Ми плануємо додати контрольне тестування завдань (той самий набір завдань, фіксовані версії, публічна методологія та оригінальні вихідні дані) і оновити цю статтю результатами. До того часу ця стаття не міститиме жодних цифр продуктивності чи рівня успішності — те, що ми не тестували, ми не подаватимемо як протестоване.

Ця стаття заснована на нашому практичному інженерному досвіді під'єднання Claude Code та OpenAI Codex до однієї системи віддаленого доступу. Востаннє оновлено 2026-08-26. Обидва рушії постійно оновлюються; за конкретною поведінкою звертайтеся до їхньої офіційної документації.