Claude Code vs 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 — сразу после разговора всё в порядке; выходите и заходите снова — один и тот же ответ ассистента превращается в 2, затем 3 сообщения, и чем чаще заходите, тем больше. Сообщения пользователя не затрагиваются: размножаются только ответы ассистента. В сессиях Claude Code такого не бывает.

Как диагностировать: этот симптом очень легко ошибочно принять за проблему рендеринга на клиенте или за дублирование при загрузке истории, после чего с головой уйти в отладку фронтенда. Правильный первый шаг — просто посмотреть, сколько записей на самом деле лежит в серверном кэше — если в кэше действительно N записей, то проблема на уровне данных, а не рендеринга. Именно благодаря этому шагу мы тогда и переключили направление поиска с клиента на сервер.

Корневая причина: сообщения ассистента в Claude Code имеют стабильный идентификатор, поэтому и при воспроизведении истории, и при push-доставке в реальном времени их можно дедуплицировать по id. Сообщения ассистента на стороне Codex не гарантируют наличия такого идентификатора: когда мы применили ту же логику «дедупликации по id», один и тот же ответ записался как два разных сообщения.

Как исправить: для сообщений без стабильного id перейти на свёртку «якорь раунда + содержимое» — в качестве якоря берётся хэш последнего пользовательского сообщения перед данным ответом.

⚠️ Здесь есть ловушка, о которой стоит рассказать отдельно: в первой версии мы делали свёртку по чистому тексту, и после запуска, просканировав исторические данные, обнаружили, что она ошибочно удалила 691 одинаковый ответ в разных раундах. Причина: в Codex очень высокая частота повторения коротких ответов (вроде «Хорошо.» «Готово.»), а множество для дедупликации было на уровне сессии — как только хэш фразы запоминался, эта же фраза в любом последующем раунде той же сессии поглощалась. А это потеря контента — гораздо хуже дублирования. Слой якорей пропускать нельзя.

2. Проверка живости: один ждёт один id, другой — пакет

Симптом: сессия на самом деле работает, а в интерфейсе отображается «офлайн».

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

Корневая причина: для ответа на вопрос «жива ли сессия» у сторон разный формат вызова. Со стороны Claude Code мы используем пакетную форму — за один вызов передаётся группа id сессий; со стороны Codex ожидается один id сессии.

Как исправить: сделайте два отдельных пути вызова и не пытайтесь использовать общий. Само различие обработать несложно; проблема в том, что оно не вызывает ошибок — при неправильной структуре не будет исключения, просто придёт семантически неверный ответ.

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

Это самое запутанное место во всём расследовании.

Симптом: индикатор состояния субагента на боковой панели остаётся оранжевым — «выполняется» и всё ещё пульсирует, хотя на деле субагент давно завершился или был прерван. Обновление страницы не помогает — обновляешь, и проблема воспроизводится заново. Возникает только в сессиях Codex.

Как диагностировать: «обновление не помогает» — ключевой критерий. Он говорит о том, что проблема не в push-доставке в реальном времени, а в самом воспроизведении истории — при каждом воспроизведении состояние заново записывается неверно.

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

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

Общая черта таких проблем: любой отдельно взятый фрейм выглядит корректно, ошибка — в их относительном порядке. Поэтому, глядя только на логи отдельных фреймов, проблему никогда не увидишь.

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? Если нет — что будет вашим якорем дедупликации?
Живость сессии — интерфейс проверки живости принимает один id или пакет? При неправильной структуре будет ошибка или тихо придёт неверный ответ?
Порядок воспроизведения истории — совпадает ли порядок фреймов при воспроизведении с реальной хронологией? Особенно при наличии подпотоков.
Структура вызова инструментов — поле команды извлекается полностью? Не бывает ли оно разрезанным?
Область подписки на события — для каких событий обязателен единственный исполнитель? Что будет при повторном выполнении?
Подход к квотам — подсчёт раздельный по движкам или общий? Совпадает ли на фронтенде и бэкенде?
Производительность длинной истории — при десятикратном росте числа сообщений время обработки растёт линейно или быстрее?

По каждому пункту рекомендую сначала проверить на малом объёме данных, а затем на длинной истории — пункты 3 и 7 проявляются только когда объём данных вырастает.

Обратный поиск по симптому: на какое различие вы наткнулись

Если вы уже наступили на грабли, обратный вывод от симптома обычно быстрее, чем чтение документации целиком:

Что вы наблюдаете	Скорее всего	Способ быстрой проверки
После выхода и повторного входа ответов ассистента становится больше	Различие 1 (идентификатор сообщений)	Посмотрите, сколько записей хранится в серверном кэше, — сразу станет ясно, дело в слое данных или в рендеринге
Сессия работает, но отображается офлайн	Различие 2 (проверка живости)	Проверьте, отправляется одиночный или пакетный запрос живости
Состояние субагента зависло на «выполняется», обновление не помогает	Различие 3 (порядок воспроизведения)	«Обновление не помогает» и есть критерий: проблема в воспроизведении, а не в push
В карточке инструмента команда фрагментирована / карточки висят после ответа	Различие 4 (структура команды)	Смотрите на структуру поля команды в исходном фрейме, а не на результат рендеринга
Два пользователя выкидывают друг друга	Различие 5 (область подписки)	Проверьте, не обрабатывают ли событие переключения одновременно два исполнителя
На фронтенде квота ещё есть, на бэкенде уже превышена	Различие 6 (подход к квотам)	Убедитесь, считают ли фронтенд и бэкенд раздельно по движкам или вместе
Мобильный клиент зависает при открытии длинной сессии	Различие 7 (длинная история)	Сравните время на сессиях с удвоенным числом сообщений — не нелинейно ли оно растёт

Универсальный критерий: если симптом стабильно воспроизводится при каждом обновлении страницы, проблема, скорее всего, в воспроизведении истории или слое данных; если он возникает лишь изредка при живом взаимодействии — тогда идите проверять push-канал. Этот критерий сэкономил нам немало времени: и различие 1, и различие 3 изначально ошибочно приняли за проблемы клиента.

FAQ (Часто задаваемые вопросы)

Codex CLI и OpenAI Codex — это одно и то же?

Codex в этой статье — это инструмент командной строки OpenAI для написания кода. На рынке есть и другие продукты с названием Codex (включая некоторое ПО для юридической сферы и комплаенса), так что при поиске легко запутаться; уточнение «CLI» или «OpenAI» делает результаты гораздо точнее.

Меняются ли эти различия от версии к версии?

Да. Каждый пункт выше — это поведение, на которое мы наткнулись в конкретный момент времени, а оба движка быстро развиваются. Поэтому важнее именно тот чек-лист проверки — конкретные различия могут меняться, а вот перечень аспектов, которые нужно проверять, вряд ли изменитсяМожно ли подключить оба движка одновременно?

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

Дальнейшие планы

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

Эта статья основана на нашем реальном инженерном опыте подключения Claude Code и OpenAI Codex к одной и той же системе удалённого доступа. Последнее обновление: 2026-08-26. Оба движка постоянно обновляются; за актуальным поведением обращайтесь к официальной документации каждого из них.