Claude Code vs Codex: siete diferencias de protocolo con las que nos topamos al conectar ambos motores al mismo sistema remoto

Declaración de intereses: desarrollamos PandaNpc, un sistema que permite que agentes de codificación como Claude Code y Codex sean accesibles de forma remota y compartidos por múltiples usuarios. Como teníamos que soportar estos motores a la vez en las mismas páginas y en el mismo flujo de mensajes, tuvimos que alinear sus comportamientos de protocolo uno por uno. Este artículo trata sobre las diferencias con las que realmente nos topamos en ese proceso; no es una comparación de rendimiento — no hemos realizado pruebas comparativas controladas, así que no aparecerán cifras de velocidad ni de tasas de éxito. Al final se indican los planes a seguir.

Nota: en este artículo, Codex se refiere a la herramienta de línea de comandos de OpenAI Codex, no a otros productos con el mismo nombre.

Conclusión en una frase: usándolos localmente en la terminal, la diferencia de experiencia entre ambos es mucho menor de lo que esperas; pero en cuanto quieres integrarlos en tu propio sistema (control remoto, sincronización entre dispositivos, recuperación de sesiones, aprobación de herramientas), las diferencias se concentran casi todas en la capa de protocolo — y ninguna de esas diferencias pudimos anticiparla desde la documentación; todas las descubrimos a base de tropezarnos con ellas.

Si estás buscando Codex vs Claude Code para saber «cuál elegir», puede que este artículo no sea la comparativa que buscas — no compara quién escribe mejor código, sino que responde a otra pregunta más concreta: qué te vas a encontrar cuando quieras tratarlos como un backend programable.

¿Para quién es este artículo?

• Desarrolladores que quieren soportar ambos motores a la vez, o migrar de uno al otro
• Personas que quieren construir herramientas periféricas como control remoto, sincronización entre dispositivos o uso compartido de sesiones
• Personas que quieren saber «en qué se diferencian realmente los modelos de sesión de estos dos CLI»

Si solo quieres escribir código en tu propia computadora y no planeas hacer integraciones, el valor de este artículo es limitado; te irá más rápido consultar directamente la documentación oficial de cada uno.

Primero, lo que tienen en común: por qué «parecen iguales»

Antes de hablar de las diferencias, hay que dejar claro: el modelo mental de estas dos herramientas es muy parecido — ambas corren en la terminal, ambas trabajan por sesiones, ambas pueden invocar herramientas para modificar archivos y ejecutar comandos, ambas requieren que el usuario confirme las operaciones peligrosas, y ambas pueden procesar varias rondas de tareas dentro de una misma sesión. Por eso, al hacer la integración es muy fácil llegar a la conclusión de que «con escribir una capa de adaptación basta», y así fue como empezamos nosotros.

La diferencia no está en la capa de capacidades, sino en la capa de protocolo. Es decir, el comportamiento que ves en la terminal puede ser casi idéntico, pero los frames que emiten, el orden de esos frames y la organización de los campos son diferentes en cada uno. Esa es la razón por la que estas diferencias son tan difíciles de detectar de antemano: usándolos en tu propia computadora, nunca te topas con ellas.

Tabla rápida de las siete diferencias

#	Dimensión	Comportamiento de Claude Code	Comportamiento de Codex	A quién le muerde si no se maneja
1	Identificador de mensajes de asistente	Tiene id estable	Puede no tenerlo	A quienes hacen persistencia de mensajes / sincronización entre dispositivos
2	Verificación de vida de la sesión	Formato por lotes, un grupo a la vez	Espera un id de sesión individual	A quienes muestran el estado en línea
3	Orden de reproducción del historial	Coincide con la cronología real	Los frames de actividad de los sub-hilos se añaden en bloque al final	A quienes hacen vistas de sub-agentes / multi-hilo
4	Estructura de comandos de las llamadas a herramientas	Completa	Puede estar fragmentada	A quienes hacen la UI de aprobación de herramientas
5	Suscripción a eventos de canal	Asume el rol de ejecutor del cambio de sesión	No puede ejecutar el cambio a la vez	A quienes hacen relay multicanal
6	Cuota de conexiones en línea	Comparte el mismo pool de conteo con Codex	Igual que a la izquierda	A quienes hacen límites de cuota
7	Rendimiento con historial largo	Lineal	Puede degenerar en no lineal si se maneja mal	A quienes hacen apps móviles

A continuación lo desarrollamos punto por punto, cada uno con el formato «síntoma → cómo diagnosticarlo → cómo solucionarlo».

1. ¿Los mensajes del asistente tienen id estable? — Determina tu estrategia de deduplicación

Síntoma: abres una sesión de Codex, todo va bien justo después de chatear; sales y vuelves a entrar, y la misma respuesta del asistente aparece 2 veces, 3 veces, y cuantas más veces entras, más aparecen. Los mensajes del usuario no se ven afectados; solo se multiplican las respuestas del asistente. En las sesiones de Claude Code no ocurre.

Cómo diagnosticarlo: este síntoma es muy fácil de confundir con un problema de renderizado del cliente o con una carga duplicada del historial, y luego te lanzas a revisar el frontend. El primer paso correcto es mirar directamente cuántos registros hay guardados en la caché del servidor — si en la caché realmente hay N registros, el problema está en la capa de datos, no en el renderizado. Nosotros logramos sacar la investigación del lado del cliente precisamente gracias a ese paso.

Causa raíz: los mensajes de asistente de Claude Code llevan un identificador estable, así que tanto en la reproducción como en la llegada del push en tiempo real se pueden deduplicar directamente por id. En el lado de Codex, los mensajes de asistente no garantizan traer ese identificador, así que al reutilizar la misma lógica de «deduplicar por id», la misma respuesta se acaba guardando como dos mensajes distintos.

Cómo solucionarlo: para los mensajes sin id estable, usa un plegado de «ancla de ronda + contenido» — el ancla es el hash del mensaje de usuario más reciente anterior a esa respuesta.

⚠️ Aquí hay una trampa que merece mención aparte: nuestra primera versión hacía un plegado por texto plano; tras publicarla, al revisar los datos históricos descubrimos que había eliminado por error 691 respuestas repetidas entre rondas. La razón es que las respuestas cortas de Codex tienen una tasa de repetición altísima (cosas como «Bien.» o «Completado.»), y el conjunto de deduplicación es a nivel de sesión — una vez que se registra el hash de una frase, cualquier repetición de esa misma frase en cualquier ronda posterior de la sesión se traga. Eso es pérdida de contenido, que es más grave que la duplicación. La capa del ancla no se puede omitir.

2. Verificación de vida: uno pide un elemento individual, el otro un lote

Síntoma: la sesión está claramente en ejecución, pero la interfaz la muestra como desconectada.

Cómo diagnosticarlo: esta diferencia parece muy generalizable — los nombres de los campos son parecidos en ambos lados, así que al escribir es fácil pensar que un mismo código puede servir para los dos. El método es simple: envía la estructura por lotes y mira si la respuesta tiene la forma que esperabas.

Causa raíz: para saber «¿esta sesión sigue viva?», las interfaces de ambos lados tienen formas distintas. En el lado de Claude Code usamos el formato por lotes, que acepta un grupo de ids de sesión de una vez; en el lado de Codex espera un único id de sesión.

Cómo solucionarlo: separa las dos rutas de llamada, no intentes compartirlas. Esta diferencia no es difícil de manejar en sí; lo molesto es que no da error — si envías la estructura equivocada no lanza ninguna excepción, solo obtienes una respuesta que semánticamente no es la correcta.

3. El orden de los frames en la reproducción del historial es diferente — el estado del sub-agente se queda atascado

Este es el punto con la ruta de diagnóstico más enrevesada.

Síntoma: el punto de estado del sub-agente en la barra lateral sigue en naranja, «en ejecución», con su animación de respiración, cuando en realidad ya terminó o fue interrumpido. Ni siquiera refrescando la página se recupera — cada vez que refrescas, se vuelve a reproducir el error. Solo ocurre en sesiones de Codex.

Cómo diagnosticarlo: «ni refrescando se recupera» es el criterio clave. Indica que el problema no está en el push en tiempo real, sino en la propia reproducción del historial — cada reproducción vuelve a escribir mal el estado una vez más.

Causa raíz: al reproducir, primero se despliegan todas las entradas del hilo padre (incluidos los frames de notificación que indican «el sub-agente ya terminó»), y luego se añaden en bloque al final los frames de actividad de cada sub-hilo. Entonces el orden que recibe el cliente es: primero ve la notificación de «interrumpido», y después ve los frames de actividad que cronológicamente son anteriores. Y la lógica que escribe el estado no compara marcas de tiempo: el último lote de frames, que es más antiguo, sobrescribe incondicionalmente el estado final y lo devuelve a «en ejecución».

Cómo solucionarlo: añade una guardia de estado final a la rama que escribe estado — si ya está en estado final (completado/fallido/detenido), solo un frame más reciente puede sobrescribirlo. Ojo: el criterio debe compartir el mismo mapeo de estados que se usa en el resto; no escribas otro aparte, o los dos sitios acabarán divergiendo sobre «qué cuenta como estado final».

La característica común de este tipo de problemas es: cualquier frame, visto de forma aislada, es legítimo; lo que está mal es su orden relativo. Por eso, mirar solo los logs de un frame individual nunca revelará el problema.

4. La estructura de los comandos de llamada a herramientas: se fragmenta

Síntoma: en las tarjetas de herramientas de las sesiones de Codex, el comando se muestra como fragmentos del tipo 1,220p o /pid=…/ {print}, a veces un script entero aparece partido, e incluso después de que termina la respuesta quedan tarjetas de herramientas sin cerrar colgando.

Cómo diagnosticarlo: mira la estructura real del campo de comando en el frame original, no el resultado renderizado. Si sigues la misma ruta de campos que usas en Claude Code para obtener «qué comando ejecutó el usuario», lo que obtienes son los fragmentos troceados.

Cómo solucionarlo: escribe una capa separada de recomposición de comandos para Codex, que reconstruya los fragmentos en el comando completo antes de pasarlo a la UI.

Esta diferencia es especialmente crítica para quienes hacen aprobación de herramientas: el usuario tiene que tocar «permitir / rechazar» en el móvil, y el comando que se muestra en la tarjeta está fragmentado — es como pedirle que firme a ciegas. Que una función de seguridad pierda su sentido es mucho más grave que una interfaz que se ve mal.

5. La superficie de suscripción a eventos de canal es distinta

Síntoma: dos usuarios se expulsan mutuamente de la sesión.

Causa raíz**: si dos rutas de relay están suscritas y ejecutan los eventos de «c de sesión», cada lado expulsa a una víctima distinta, formando una doble expulsión. La acción de cambio debe tener un único ejecutor.

Cómo solucionarlo: nuestra solución fue hacer que la ruta de Codex solo se suscriba a eventos de expulsión e invalidación de caché, y nunca a eventos de cambio, dejando fijado el derecho a ejecutar el cambio en la otra ruta.

Este tipo de decisiones de «deliberadamente no hacer algo» normalmente solo deja un comentario de una línea en el código, pero se añadió después de pisar el problema una vez — y si más adelante alguien «completa» esa restricción de paso, el accidente se reproduce. Por eso en el comentario hay que escribir por qué no se hace, no solo que no se hace.

6. La cuota y el conteo de conexiones están combinados

Síntoma: el usuario cree que aún le queda cuota, pero en realidad ya la ha superado.

Causa raíz: si, como nosotros, pones un límite al número de conexiones en línea, ten en cuenta que las conexiones de los dos motores caen en el mismo pool de conteo. Cuando un usuario tiene sesiones de Claude Code y Codex abiertas a la vez, están consumiendo la misma cuota.

Esto no es un defecto, es una decisión de diseño — desde el punto de vista del usuario, «cuántas sesiones puedo tener abiertas a la vez en total» es más fácil de entender que «cuántas puedo abrir de cada motor». Pero si tu implementación cuenta por separado por motor, el saldo que muestra el frontend no cuadrará con el que realmente descuenta el backend.

Cómo solucionarlo: primero decide qué criterio quieres usar y luego asegúrate de que frontend y backend usen el mismo. Mezclar los dos criterios es peor que elegir el criterio equivocado.

7. El rendimiento se comporta distinto cuando crece el historial

Síntoma: la app móvil se congela al abrir sesiones con historial largo.

Causa raíz: en iOS nos encontramos una vez con un congelamiento evidente. La causa fue una operación en el procesamiento del historial que crece de forma cuadrática con el número de mensajes. Hay que aclarar: no es un problema del motor en sí, sino que su estructura de historial no coincidía con nuestra forma original de procesarlo — el mismo método de procesamiento no se manifestó en el otro motor.

Cómo solucionarlo: sustituye el escaneo repetido que crece con el número de mensajes por un índice que se construye en una sola pasada. Y más importante aún: diseña con antelación — el historial largo hay que tenerlo en cuenta desde el principio, no esper a que los usuarios acumulen miles de mensajes para descubrirlo.

Entonces, ¿cuál elegir?

Primero, una aclaración: lo siguiente son recomendaciones desde una perspectiva de integración, no una evaluación de la capacidad de escritura de código. No hemos hecho pruebas comparativas controladas; ninguna afirmación del tipo «tal cosa es X veces más rápida» va a salir de este artículo.

Casos en los que conviene más elegir Codex

1. Tu equipo ya está en el ecosistema de OpenAI — cuentas, cuotas y facturación están en un solo sitio; te ahorras una gestión adicional de facturación y credenciales. Ese ahorro de molestias no debería subestimarse.
2. Tus flujos de trabajo ya están construidos alrededor de su modelo de sesiones y tareas — normalmente no compensa refactorizar las herramientas periféricas solo por migrar; las siete diferencias anteriores, vistas al revés, son el coste de la migración.

Casos en los que conviene más elegir Claude Code

1. Quieres construir tus propias herramientas periféricas — por nuestra experiencia de integración, que los mensajes tengan un identificador estable hace que la persistencia y la sincronización entre dispositivos sean mucho más sencillas; las diferencias 1, 3 y 4 son más fáciles de manejar en este lado.
2. Quieres hacer interacciones como la aprobación de herramientas — la estructura de comandos es completa, no necesitas reconstruir nada al hacer la UI de aprobación, y por tanto no existe el riesgo de «firmar a ciegas».

Casos en los que no elegir ninguno

Si tu necesidad es solo «cambiar de modelo para ejecutar la misma interacción», entonces cambiar de motor no es mejor que cambiar el backend del modelo. Parte de la razón por la que hicimos PandaCode es justamente esa: mantener la capa de interacción sin cambios y cambiar el modelo.

Si vas a migrar: el volumen de cambios correspondiente a las siete diferencias

Mucha gente busca estos dos nombres porque en realidad está evaluando «ya uso uno, ¿cuánto me cuesta cambiarme al otro?». A continuación convertimos las siete diferencias en costes de migración.

Aclaración necesaria: esta sección es el volumen de cambios derivado de las siete diferencias anteriores, no el registro de una migración completa que hayamos hecho — nuestro camino fue «integrar ambos a la vez», no «cambiar de uno al otro». Así que tómala como una lista de verificación, no como una estimación de horas.

Migrar de Claude Code a Codex: los cambios se concentran en estos puntos:

• La lógica de deduplicación hay que reescribirla (punto 1) — es la parte más fácil de subestimar. El código original que deduplicaba por id no se puede usar directamente, y si falla, no da error: solo duplica mensajes en silencio o pierde mensajes en silencio. Si tienes persistencia de mensajes, antes de migrar tienes que decidir bien qué ancla vas a usar.
• La verificación de estado en línea hay que cambiarle la forma de llamada (punto 2) — el trabajo es poco, pero si se te olvida, provoca «en ejecución pero mostrando desconectado», y sin lanzar ninguna excepción.
• Todo lo que dependa de la cronología del historial hay que re-verificarlo (punto 3) — la vista de sub-agentes, las barras de progreso y cualquier lógica de «inferir el estado actual a partir del historial» entran en esta categoría.
• La UI de aprobación de herramientas necesita una capa de recomposición de comandos (punto 4) — si tu producto tiene función de aprobación, esta parte no se puede omitir; si la omites, es como hacer que el usuario firme a ciegas.

La dirección inversa (de Codex a Claude Code) normalmente es más sencilla: la deduplicación se puede simplificar de nuevo a «por id», y la estructura de comandos no necesita capa de recomposición. Pero ojo: no elimines directamente la capa de compatibilidad que escribiste para Codex — si quieres conservar la capacidad de soportar ambos a la vez, esa lógica es un activo, no un pasivo.

Lo que hay que re-confirmar en ambas direcciones: el criterio de cuota (punto 6) y el rendimiento con historial largo (punto 7). Estas dos no tienen una relación tan directa con el motor, pero son las partes que más fácilmente se olvida volver a probar después de cambiar de motor.

Una sugerencia: si tu sistema ya está en producción y tienes datos de sesiones existentes, antes de migrar ejecuta la nueva lógica sobre los datos existentes para comparar; no hagas el cambio directamente. La lección de esos 691 mensajes eliminados por error salió exactamente de ahí — la lógica en sí parecía no tener problema, y solo al escanear el historial descubrimos que se tragaba contenido. Que la lógica nueva sea correcta ≠ que sea segura para los datos existentes.

Nuestra forma de hacerlo: no elegir, conectar ambos

Como teníamos que soportar ambos, nuestra conclusión final fue absorber las diferencias en la capa intermedia — hacia arriba exponemos un modelo unificado de mensajes y sesiones; hacia abajo, adaptamos según el motor. El coste es que cada motor nuevo que añadimos requiere volver a alinear estas siete categorías de comportamiento; el beneficio es que el usuario puede cambiar de motor libremente en la misma interfaz, y la experiencia de sesión, historial y aprobación es consistente.

Lista de verificación para integrar un motor nuevo

Si también vas a seguir este camino, te sugiero verificar en este orden: los cuatro primeros puntos determinan si se puede usar; los tres últimos determinan si habrá problemas en producción:

1. Identificador de mensajes — ¿los mensajes del asistente tienen id estable? Si no, ¿cuál es tu ancla de deduplicación?
2. Vida de la sesión — ¿la API de verificación de vida acepta un elemento individual o un lote? Si envías la estructura equivocada, ¿da error o responde en silencio con una respuesta incorrecta?
3. Orden de reproducción del historial — ¿el orden de los frames reproducidos coincide con la cronología real? Sobre todo cuando hay sub-hilos.
4. Estructura de la llamada a herramientas — ¿el campo de comando se obtiene completo? ¿Puede quedar fragmentado?
5. Superficie de suscripción a eventos — ¿qué eventos deben tener un único ejecutor? ¿Qué pasa si se ejecutan dos veces?
6. Criterio de cuota — ¿el conteo se separa por motor o se combina? ¿Frontend y backend coinciden?
7. Rendimiento con historial largo — cuando el número de mensajes se multiplica por diez, ¿el tiempo de procesamiento crece de forma lineal o más rápido?

En cada punto se recomienda verificar primero con un volumen de datos pequeño y luego con un historial grande — los puntos 3 y 7 solo se destapan cuando el volumen de datos aumenta.

Búsqueda inversa por síntoma: con cuál de los puntos estás chocando

Si ya has pisado el problema, deducir hacia atrás desde el síntoma suele ser más rápido que leer toda la documentación:

Síntoma que ves	Muy probablemente es	Método de diagnóstico en un paso
Al salir y volver a entrar, las respuestas del asistente se multiplican	Punto 1 (identificador de mensajes)	Mira directamente cuántos registros hay en la caché del servidor — con eso sabrás de un vistazo si es la capa de datos o la de renderizado
La sesión está en ejecución pero muestra desconectada	Punto 2 (verificación de vida)	Comprueba si la solicitud de vida envía una estructura individual o por lotes
El estado del sub-agente se queda en «en ejecución» y ni refrescando se recupera	Punto 3 (orden de reproducción)	«Ni refrescando se recupera» es el criterio: el problema está en la reproducción, no en el push en tiempo real
Los comandos en la tarjeta de herramientas están fragmentados / al terminar la respuesta quedan tarjetas de herramientas colgando	Punto 4 (estructura de comandos)	Mira la estructura del campo de comando en el frame original, no el resultado renderizado
Dos usuarios se expulsan mutuamente	Punto 5 (superficie de suscripción)	Comprueba si hay dos ejecutores manejando el evento de cambio a la vez
El frontend muestra que aún hay cuota y el backend ya la ha superado	Punto 6 (criterio de cuota)	Confirma si el frontend y el backend cuentan por separado por motor o de forma combinada
La app móvil se congela al abrir una sesión larga	Punto 7 (historial largo)	Compara el tiempo de procesamiento entre sesiones con el doble de mensajes y mira si es no lineal

Un criterio general: si el síntoma se reproduce de forma estable cada vez que refrescas, lo más probable es que el problema esté en la reproducción del historial o en la capa de datos; si solo ocurre de forma esporádica durante la interacción en tiempo real, entonces ve a revisar la cadena de push. Este criterio nos ahorró bastante tiempo — los puntos 1 y 3 fueron mal diagnosticados al principio como problemas del cliente.

FAQ

¿Codex CLI y OpenAI Codex son lo mismo? El Codex del que habla este artículo se refiere a la herramienta de codificación de línea de comandos de OpenAI. En el mercado hay otros productos que también se llaman Codex (incluido software del ámbito legal y de cumplimiento normativo), así que es fácil confundirse al buscar. Añadir el calificador "CLI" u "OpenAI" hace las búsquedas mucho más precisas.

¿Estas diferencias cambian con las versiones? Sí. Cada una de las anteriores es un comportamiento con el que nos topamos en un momento concreto; los dos motores están iterando rápido. Por eso la lista de verificación es lo más importante — las diferencias concretas cambiarán, pero las dimensiones que hay que verificar no cambian tanto.

¿Se pueden integrar los dos motores a la vez? Sí, así es como lo hacemos nosotros. La clave es absorber las diferencias en la capa intermedia y no dejar que se filtren a la capa de UI — de lo contrario, cada motor nuevo que añadas hará que la lógica de la interfaz se bifurque una vez más.

Próximos pasos

Tenemos previsto añadir un conjunto de pruebas de tareas comparativas (mismas tareas, versiones fijadas, metodología pública y salidas originales), y actualizaremos este artículo con los resultados cuando estén listas. Hasta entonces, este artículo no contiene cifras de rendimiento ni de tasas de éxito — lo que no hemos medido, no lo vamos a escribir como medido.

---

Este artículo se basa en nuestra experiencia real de ingeniería al integrar Claude Code y OpenAI Codex en el mismo sistema de acceso remoto. Última actualización: 2026-08-26. Ambos motores se actualizan continuamente; para el comportamiento concreto, consulta la documentación oficial de cada uno.