SynaBun se construyó conversando con Claude. Eso salta a la vista. Los hooks, los workflows, las historias de batalla de este blog, toda la forma que ha tomado el producto hasta ahora. Claude ha sido la IA sentada con nosotros en la sala mientras se construía la mayor parte de este sistema.

Pero SynaBun nunca debió pertenecer a un solo modelo.

La razón de ser de SynaBun es que tu IA tenga infraestructura: memoria que perdura, un navegador que mantiene la sesión iniciada, un whiteboard donde dibujar, un workspace que puede compartir y un registro de lo que pasó antes. Esa idea es más grande que cualquier CLI.

Por eso estamos incorporando Codex al ecosistema de SynaBun.

Por qué Codex encaja aquí

Un workspace de IA se vuelve más útil cuando deja de suponer que solo hay un cerebro válido conectado a él.

Cada modelo es bueno en cosas distintas. Uno razona mejor sobre arquitectura. Otro implementa más rápido. Uno te da la respuesta que querías. Otro te da la que de verdad necesitabas. Si tu workspace solo funciona bien con uno de ellos, el cuello de botella es el workspace.

SynaBun debe ser lo contrario. Debe ser la capa que hace que las buenas herramientas de IA resulten más aprovechables con el tiempo, no la que te obliga a elegir un favorito para siempre.

Codex encaja en esa dirección de forma natural. Es otro agente de programación serio, con su propio workflow, sus propias fortalezas y su propia manera de trabajar en una base de código real. No queremos que Codex se quede fuera del circuito de SynaBun. Lo queremos dentro del mismo sistema de memoria, la misma interfaz de proyecto y el mismo entorno colaborativo.

No se trata de reemplazar a Claude

Claude no se va a ninguna parte. Este no es un artículo sobre una migración. Es un artículo sobre una ampliación.

El objetivo no es “pasar de Claude a Codex”. El objetivo es “dejar de tratar las sesiones de IA como islas aisladas”.

Hoy, la mayoría de los workflows de IA siguen atrapados en silos de herramientas. Empiezas en un asistente, acumulas contexto, tomas decisiones, tocas archivos, quizá guardas algunas notas, y si luego quieres que participe otro modelo, básicamente vuelves a empezar. Aunque los archivos se compartan, la sesión no. La cadena de razonamiento tampoco. El impulso tampoco.

Ese es el verdadero problema.

El problema: archivos compartidos, sesiones fragmentadas

Un repositorio compartido no es lo mismo que una sesión de trabajo compartida.

Puedes tener a Claude y a Codex apuntando a la misma base de código y aun así perder una cantidad absurda de tiempo explicándolo todo otra vez:

  • cuál es realmente la tarea
  • qué se intentó ya
  • qué archivos importan
  • qué decisiones son provisionales
  • qué decisiones están cerradas
  • cuál es el bloqueo actual
  • si el último agente estaba planificando, depurando o a mitad de una corrección

Eso es fricción. Y se acumula.

SynaBun ya resuelve parte de esto con memoria persistente, workspaces compartidos y sesiones de terminal vinculadas. Pero el paso grande es que la sesión misma sea lo bastante portátil para que una IA le pase el trabajo a otra sin que todo termine en un resumen hecho a mano.

El objetivo no es que Codex se comporte como Claude ni que Claude se comporte como Codex. El objetivo es que ambos participen en el mismo hilo de trabajo de larga duración.

Qué significa de verdad que las sesiones sean compatibles

No fingimos que Claude y Codex usan el mismo protocolo nativo. No es así. Sus herramientas, sus formatos y la semántica de sus sesiones son diferentes.

Así que compatibilidad no significa uniformidad fingida. Significa construir por encima de ellos una capa de traspaso compartida.

En la práctica, eso significa que una sesión de SynaBun debe poder llevar de un modelo a otro las partes del trabajo que realmente importan:

  • el proyecto y los archivos activos
  • el conjunto de memorias relevantes
  • el resumen de la tarea y el objetivo actual
  • las decisiones recientes y las preguntas abiertas
  • los resultados importantes de las herramientas
  • el estado del workspace que el siguiente agente necesita para continuar

Empieza en Claude. Pásale el trabajo a Codex. Continúa en el mismo workspace sin reescribir toda la historia desde cero. O hazlo al revés: usa Codex para empujar la implementación y luego trae de vuelta a Claude para revisar, planificar o pulir.

El mismo proyecto. La misma memoria. El mismo hilo de trabajo. Otra IA.

Por qué importa

Cuando las sesiones son portátiles, elegir modelo pasa a ser una decisión táctica y no permanente.

Eso cambia la forma del desarrollo con IA.

Puedes usar el modelo que mejor se ajusta a la fase en la que estás, en lugar del modelo con el que casualmente empezaste. Los equipos pueden conservar su agente preferido sin romper la colaboración. Los workspaces compartidos pasan a ser multiagente de verdad, no solo multiterminal.

Esto también hace de SynaBun un producto más honesto. Ya creemos que la capa de infraestructura importa más que la caja de chat. La memoria, el estado del navegador, la visibilidad del workspace y la continuidad en el tiempo son las partes que perduran. Si esa convicción es real, el sistema debe funcionar con más de un agente de programación serio.

Codex es la siguiente prueba evidente de ese principio.

Qué vamos a construir primero

Vamos a hacerlo por fases.

Primero: Codex pasa a ser un participante de pleno derecho en el workspace de SynaBun.

Luego: flujos de traspaso explícitos entre Claude y Codex, en los que una sesión empaqueta el estado actual del trabajo para la otra.

Después: una compatibilidad de reanudación más profunda, en la que el traspaso no es solo un resumen, sino una capa de continuación estructurada, construida a partir de la memoria, los artefactos, el estado de los archivos y el rastro de la sesión.

Esa es la dirección. No una IA que domine el workspace. Un workspace capaz de coordinar varias IA sin borrar el contexto cada vez que cambias.

SynaBun nació para que la IA dejara de olvidar. El siguiente paso es que las sesiones dejen de quedar atrapadas en el modelo que las creó.

Codex se suma al ecosistema. Claude se queda. Lo interesante es lo que pasa cuando ambos pueden trabajar en el mismo hilo sin empezar de cero.