El 19 de agosto, OpenAI publicó en su blog para desarrolladores un artículo titulado "Codex as a platform", con el que cambió la forma de describir Codex: de "asistente de programación que corre en la terminal" a "capa de ejecución de código abierto sobre la que otros pueden construir directamente".
El artículo arranca señalando un detalle que suele pasarse por alto: la mayoría conoce Codex a través de la app de escritorio, la línea de comandos o un plugin de IDE, pero esas tres puertas de entrada comparten el mismo sistema subyacente, que ya estaba publicado en GitHub (repositorio openai/codex, licencia Apache 2.0, con 109.000 estrellas actualmente). Lo que hace OpenAI ahora es un reposicionamiento: pasar de "detalle interno de implementación de nuestro producto" a "la base sobre la que ustedes construyen".
La capa que rodea al modelo
El texto original en inglés usa el término harness, que el sector técnico suele traducir como marco de ejecución o andamiaje de control. La definición de OpenAI es sencilla:
"That surrounding execution system is the harness."
Ese sistema de ejecución que rodea al modelo es el harness.
Desglosado, es responsable de recopilar contexto, dividir la tarea en pasos ejecutables, mantener el estado de la sesión a lo largo de varias rondas, invocar herramientas, ejecutarse dentro de los límites configurados de sandbox y permisos, detenerse en el momento adecuado para esperar la aprobación humana y, por último, devolver el resultado al sistema de negocio. Nada de esto tiene que ver con los pesos del modelo, pero hacerlo bien o mal afecta directamente a las puntuaciones. OpenAI vuelve a citar sus propios datos de ARC-AGI-3 de finales de julio: con solo activar, en la capa de harness, la retención de razonamiento y la compresión de contexto, la puntuación de GPT-5.6 Sol en el conjunto público pasó de 13,3% a 38,3%, mientras el número de tokens de salida cayó a cerca de una sexta parte. El modelo no cambió; lo que cambió fue la capa que lo rodea.
Tres niveles de integración, según su grado de intrusión
OpenAI dividió claramente las formas de integración en tres capas, para que los desarrolladores elijan según el escenario en lugar de forzarlo todo dentro de una ventana de chat.
codex exec está pensado para scripts, tareas de CI y trabajos puntuales en segundo plano: ejecuta un flujo de agente con límites bien definidos y entrega un resultado estructurado antes de terminar. El Codex SDK está pensado para aplicaciones que necesitan iniciar, retomar y leer en streaming tareas de Codex directamente desde el código. El Codex app-server es el nivel más invasivo: la aplicación se conecta a un proceso local de Codex, mantiene la sesión abierta de forma permanente, recibe un flujo de eventos, puede interrumpir en cualquier momento, expone sus propias herramientas al agente y se hace cargo de gestionar las solicitudes de aprobación.
Para mostrar cómo se usa app-server, OpenAI construyó de paso una aplicación de ejemplo llamada Relay, un panel ficticio para gestionar excepciones de transporte de carga. El usuario no escribe prompts: primero selecciona un envío y luego pulsa un botón como "Compare recovery"; la aplicación entrega el contexto relevante, Codex usa una herramienta MCP conectada por la propia aplicación para obtener datos actualizados y explicar las opciones disponibles; para hacer un cambio real es obligatoria la aprobación humana, y solo después de registrar la operación en la base de datos la aplicación actualiza su propia vista de negocio.
El artículo justifica esta decisión de diseño sin rodeos: no hay que sustituir paneles de despacho, líneas de tiempo, mapas y pantallas de tickets por una ventana de chat genérica; esas interfaces existen precisamente para que las personas entiendan la situación, tomen decisiones y mantengan la sensación de control.
Quién ya lo ha puesto en producción
OpenAI enumeró tres grupos de casos públicos. GitHub y JetBrains integraron Codex en sus respectivos flujos de trabajo de IDE; Cisco usó el Codex SDK en el App Builder de Cloud Control; Thrive Holdings y Crete incorporaron Codex a su proceso de preparación de declaraciones de impuestos, procesando 7.000 declaraciones en la fase piloto, con una reducción de aproximadamente un tercio en el tiempo de preparación.
Esta última cifra es la más sólida de todas. La preparación de declaraciones de impuestos es un caso típico de alta repetición, baja tolerancia al error y fuertes exigencias de cumplimiento normativo; presentar una escala de piloto junto con un indicador de eficiencia comparable resulta mucho más útil que afirmaciones vagas como "aumento notable de productividad". OpenAI también aprovechó para subrayar que este modelo no solo sirve a equipos de ingeniería: la clasificación de soporte al cliente, la coordinación operativa, la priorización de incidentes de seguridad y la verificación previa en ventas comparten la misma forma: la aplicación aporta contexto, herramientas y pasos de aprobación, y Codex se encarga del ciclo entre medias.
Hasta dónde llega el código abierto
Hay una frase subrayada en el artículo: lo abierto es el harness y las superficies de integración; el acceso al modelo y los servicios alojados se siguen cobrando aparte.
Al poner esta frase junto a los tres niveles de integración, la estrategia de OpenAI queda clara. La capa de ejecución se entrega gratis, auditable y personalizable, y cualquiera puede incorporarla a su propio producto; pero cada vez que se ejecuta un ciclo de agente, los tokens siguen pasando por la API de OpenAI. Cuanto más útil sea la parte abierta y más productos la integren, mayor será el volumen de llamadas del lado del modelo. Es la misma jugada que hizo Anthropic al convertir MCP en el estándar de facto para la integración de herramientas, solo que esta vez OpenAI está cediendo algo mucho más pesado: todo el runtime.
Para los equipos que construyen productos de agentes, el beneficio inmediato es ahorrarse un trabajo repetido. Estado de sesión, flujo de eventos, llamadas a herramientas, interrupciones para aprobación: la mayoría de los equipos ya ha escrito esto al menos una vez, y después ha tenido que seguir ajustándolo. Ahora existe una implementación validada a gran escala, legible línea por línea, como referencia. Haciendo cuentas: si solo el cambio en la capa de harness ya reduce los tokens de salida a una sexta parte, con el mismo presupuesto se pueden ejecutar cinco ciclos más; eso por sí solo ya justifica que muchos equipos lean el código fuente con atención.
El costo también está a la vista: cuanto más profunda la integración, más atada queda al modelo de cobro de OpenAI. Esto se nota especialmente en el nivel app-server, que va más allá de una simple relación de llamadas a la API y prácticamente introduce el proceso del otro directamente en el propio producto.
Fuentes: blog para desarrolladores de OpenAI "Codex as a platform", CocoLoop, repositorio de GitHub openai/codex; licencia, número de estrellas y los tres niveles de integración verificados en el repositorio y la documentación oficial, puntuación de ARC-AGI-3 y reducción de tokens según cifras reportadas por la propia OpenAI.