Resumen:
Ayer OpenAI jugó cuatro cartas importantes de una sola vez. API de agentes, API GPT-Live-1, agente de datos, ChatGPT para servicios financieros, en un día abarca cuatro líneas de productos de agente, voz, datos y finanzas, cada una de las cuales merece ser analizada por separado. Pero entre estas cuatro tarjetas, la más destacada puede ser la API de Agentes.

Porque esta vez, OpenAI "desarmó y vendió" el Codex.
El conjunto de capacidades originalmente ocultas detrás del Codex y responsables de permitir que el Agente continúe trabajando, invocando herramientas, administrando el contexto y coordinando múltiples Agentes se extrajeron y empaquetaron en una API en la nube para que todos los desarrolladores la llamaran.
¿Codex como servicio?
De hecho, OpenAI lleva mucho tiempo desmantelando el Codex.
Ya en abril de 2025, cuando OpenAI lanzó por primera vez o3 y o4-mini, abrió la CLI del Codex. Es un poco como la versión OpenAI de Claude Code, instalada directamente en la terminal local. Cómo ejecutar el Agente y cómo llamar a las herramientas están claramente publicados en GitHub. Si está dispuesto a esforzarse, puede retirarlo, modificarlo y ejecutarlo usted mismo.
Pero en ese momento, las cosas simplemente se repartían. Si puedes usarlos y cómo quieres usarlos sigue siendo asunto tuyo.
Un mes después, se lanzó oficialmente la versión en la nube de Codex, el producto que conocemos hoy. Los usuarios pueden entregarle el almacén de códigos y cada tarea corresponde a una zona de pruebas en la nube independiente. Codex puede modificar el código, ejecutar pruebas, corregir errores y manejar múltiples tareas al mismo tiempo.
Unos meses más tarde, en octubre de 2025, OpenAI lanzó el SDK del Codex.
En pocas palabras, el SDK es un conjunto de herramientas para desarrolladores, por lo que Codex no sólo puede usarse como un producto independiente, sino que también puede integrarse en las aplicaciones de otras personas. El SDK permite a los desarrolladores utilizar unas pocas líneas de código TypeScript para iniciar el mismo Agente que controla la CLI del Codex, obtener resultados estructurados, conservar el estado de la tarea y continuar ejecutándose después de una pausa.
Sin embargo, el SDK es principalmente adecuado para llamar a Codex en programas y aún no ha abierto todas las capacidades de interacción de Codex. Es muy adecuado para flujos de trabajo en segundo plano, scripts automatizados y programas del lado del servidor. Pero si desea crear un cliente completo como Codex IDE, todavía es un poco difícil.
Entonces, en febrero de 2026, OpenAI lanzó oficialmente el servidor de aplicaciones Codex y, por primera vez, explicó sistemáticamente y con claridad el arnés en el Codex.
OpenAI explicó claramente que Codex Web, CLI, extensiones IDE y la aplicación Mac parecen ser productos diferentes, pero en realidad ejecutan el mismo Codex Harness debajo, que es la capa responsable del Agent Loop, Thread, ejecución de herramientas, autenticación y estado de administración.
App Server agrega una interfaz JSON-RPC bidireccional a este conjunto completo de Harness. JetBrains, Xcode u otros clientes no necesitan volver a crear un Agent Loop. Pueden iniciar directamente el servidor de aplicaciones para controlar el Codex completo.
Con App Server, se pueden conectar otros productos directamente al Codex Harness completo.
Pero llegados a este punto, queda un último problema que queda por resolver.
El SDK controla el agente Codex local y el servidor de aplicaciones en sí también es un proceso residente que los desarrolladores deben iniciar y mantener. Aunque el problema de la integración de Codex en el producto se ha resuelto, todavía es un poco difícil ejecutarlo de manera estable en un servicio en línea.
Para dar un ejemplo más específico, si usa App Server para crear su propio sitio web de Coding Agent, la interfaz se ha conectado a Codex, pero cuando el usuario hace clic en "Reparar este almacén", aún necesitará encontrar una manera de resolver una gran cantidad de problemas de infraestructura y operación posteriores.
Entonces llegó el 19 de agosto. En este día, OpenAI unificó la CLI, el SDK y el servidor de aplicaciones que se habían abierto el año pasado en la narrativa de la plataforma "Open Codex Harness" y claramente actualizó el Codex de un producto a una plataforma.

Luego, el 10 de septiembre (hora de EE. UU.), que fue ayer, la API de agentes se abrió oficialmente para pruebas públicas.
Esta vez, los desarrolladores solo necesitan decirle a la API cuatro cosas (tareas, modelos, herramientas y entornos de ejecución) para crear directamente un Agente. Codex Harness, que es responsable de la compresión del contexto de sesiones largas, la programación de herramientas y la colaboración de subagentes, está alojado y mantenido por el propio OpenAI.
Incluso puedes elegir la máquina en la que realmente funciona el Agente. Puede elegir si desea utilizar la zona de pruebas de OpenAI, su propia infraestructura o entornos de terceros como Cloudflare, E2B y Modal. OpenAI proporciona el arnés y el entorno de ejecución lo determina el desarrollador.

La declaración oficial es muy clara: no hay ningún cargo adicional por la API de agentes en sí. En otras palabras, el hosting de Harness, la gestión de sesiones largas y otras capacidades no cobran una capa separada de tarifas de plataforma de agente.
Los desarrolladores pagan según los tokens modelo y las herramientas realmente utilizadas; Si se utiliza el entorno limitado de alojamiento propio de OpenAI, los recursos informáticos se calculan por separado.
Durante más de un año, OpenAI ha estado haciendo lo mismo: dividir el Codex de un producto específico en capacidades reutilizables capa por capa, al tiempo que permite a los desarrolladores preocuparse cada vez menos por sí mismos.
Si hay que darle un nombre a esta línea de productos, en realidad es muy similar a SaaS en aquel entonces, excepto que esta vez no se trata de software al que se le presta servicio, sino de Codex.
Códex como servicio.
El arnés también ha comenzado a bifurcarse
Por supuesto, OpenAI no es el único que está mirando a Harness.
Cuando se lanzó DeepSeek Harness (en lo sucesivo, DSH), se proporcionó una ecuación muy ruidosa:
Agente = Modelo + Arnés.
Desde el punto de vista de DeepSeek, el modelo es solo la mitad del Agente, y la otra mitad es el Arnés que es responsable de permitirle comprender el entorno, llamar a herramientas, administrar el estado y continuar ejecutando tareas. Sólo cuando los dos se coordinan entre sí podrá el Agente realmente realizar sus tareas.
DSH ha convertido a Harness en un marco abierto altamente modular: se pueden reemplazar modelos, herramientas, habilidades, sesiones, entornos aislados, almacenamiento, bucle de agente, programación e incluso interfaz de usuario.
El lema "Todo es un complemento" no es sólo una broma. Lo mejor para todos es escribir complementos y adaptarse a DSH. Al final, independientemente de si DeepSeek u otros modelos se ejecutan encima, se puede utilizar el mismo conjunto de arnés debajo.

Este es un contraste interesante con la dirección que está tomando OpenAI ahora.
Aunque OpenAI también ha abierto el código fuente del arnés Codex, la API de Agentes obviamente va en la otra dirección: puedes usar tu propio arnés, o puedes tomar el de código abierto, pero si te resulta problemático, puedes simplemente ignorarlo y dejar que yo lo arregle por ti.
Por eso lo consideramos más bien un "servicio". OpenAI es responsable de alojar y mantener continuamente Harness. Los desarrolladores sólo necesitan decidir qué quieren que haga el Agente, qué herramientas usar y dónde ejecutarlo. Incluso si el modelo se actualiza en el futuro, si Harness cambia en consecuencia, OpenAI también se preparará para empaquetarlo.
En cierto sentido, hay dos rutas vagas a nivel del arnés:
La ruta representada por DeepSeek se parece más a la construcción de un ecosistema abierto, convirtiendo cada pieza en un complemento para que los desarrolladores lo monten ellos mismos; mientras que el partido representado por OpenAI es como apostar por los servicios en la nube, poner dinero y demanda, y yo te ayudaré a resolver el resto.
Incluso podemos pensar que uno quiere hacer que Harness se parezca cada vez más a Linux, y el otro quiere que Harness se parezca cada vez más a AWS.
Por supuesto, esto es sólo una metáfora. OpenAI también tiene Codex Harness de código abierto y no es imposible que DeepSeek proporcione más servicios de alojamiento en el futuro. Pero al menos en esta etapa, el enfoque de los dos productos es obviamente diferente.
Curiosamente, Anthropic está en realidad un paso por delante de OpenAI al convertir Harness en un servicio.
Ya en septiembre de 2025, Anthropic lanzó Claude Agent SDK, abriendo las herramientas, la gestión de contexto, el sistema de permisos y las capacidades de subagente detrás de Claude Code a los desarrolladores, para que otros puedan usar este conjunto de cosas como agentes.
En abril de este año, lanzó Claude Managed Agents incluso antes que OpenAI. La sesión, el arnés y la zona de pruebas se dividen en tres capas independientes: Anthropic es responsable de alojar el arnés y las tareas largas. La zona de pruebas puede ser proporcionada por Anthropic o puede conectarse a otros entornos de ejecución. En realidad, esta idea se acerca bastante a la API de agentes actual. La propia Anthropic lo define como "un servicio de hosting para tareas de Agente a largo plazo".

Entonces, en cierto sentido, OpenAI continúa avanzando por el camino que Anthropic ha tomado esta vez. La diferencia es que OpenAI tiene un Codex más "productizado".
Sin embargo, debido a que Codex y Claude Code han dado impresiones diferentes sobre los productos durante mucho tiempo, incluso si cuentan la misma historia, provocan sentimientos muy diferentes. Claude Code se siente más como permitir que los desarrolladores se sienten en la terminal y escriban código junto con el Agente, mientras que la aplicación Codex enfatiza la interfaz de "supervisar simultáneamente múltiples agentes a largo plazo" desde el principio.
Por cierto, Google ya se ha sumado a esta ruta. En la conferencia I/O de mayo de este año, Gemini API lanzó Managed Agents, que también convirtió Antigravity Harness y sandbox en servicios administrados. Pero las cartas de Google no terminan ahí, de lo que hablaremos más adelante.
Pero dicho esto, no parece ser tan importante quién viene primero... Al final, por supuesto, quien convierta su Arnés en la capa predeterminada para los desarrolladores podrá comerse el pastel más grande.
¿Quién es el gran ganador?
Después de todo, ¿por qué las empresas de modelos están empezando a adquirir Harness?
Al igual que la ecuación dada por DSH, Agente = Modelo + Arnés, el modelo puede decirle al Agente qué hacer a continuación, pero para ejecutar realmente una tarea de principio a fin, todavía tiene que saber dónde está el archivo, qué herramienta debe llamarse, cómo recuperarse cuando ocurre un error y dónde se escriben finalmente los resultados.
En otras palabras, el modelo determina el límite superior de la capacidad del Agente, y Harness determina cada vez más si puede completar el trabajo.
Una vez que la dimensión de la competencia pasa de la "inteligencia" a la "ejecución", las que tienen la mayor ventaja pueden no ser las empresas de IA con los mejores modelos.
Porque una vez que el Agente comienza a trabajar, las cosas que necesita (correos electrónicos, documentos, reuniones, comunicaciones, permisos de cuentas, etc.) suelen estar en manos de empresas de plataformas tradicionales.
La recientemente acalorada “Guerra de agentes de oficina” en China es en realidad un ejemplo muy típico: las cosas que las grandes empresas acumularon en la era de las plataformas de Internet solían ser más que solo una parte de las funciones en sus respectivos ecosistemas, pero en la era de los agentes, estas cosas resultan ser las herramientas que los agentes necesitan utilizar cuando realmente trabajan.
Hoy en día, todo el mundo trabaja como agente de oficina. En la superficie, son más inteligentes y más capaces que los empleados de IA de cualquier otra persona. Detrás de escena, en realidad están reutilizando las ventajas de la plataforma que han acumulado en el pasado. A quien tenga más datos, documentos, herramientas y permisos empresariales le resultará más fácil dejar que el Agente haga las cosas.
Las empresas modelo necesitan acceder a portales que no tienen, y aquellas empresas que llevan más de diez años fabricando software ofimático y plataformas de Internet ya cuentan con estos portales.
En otras palabras,
las empresas de IA quieren volver a conectarse con el mundo real y las empresas de plataformas ya tienen un montón de claves en sus manos.
Si seguimos este camino, si tenemos que encontrar el reproductor "familiar" con mayores ventajas, Google es probablemente el más exagerado.
Desde TPU, infraestructura en la nube, Gemini hasta Search, Workspace, Chrome y Android, Google cubre casi todos los aspectos clave de la IA, desde la tecnología subyacente hasta los usuarios finales. La Búsqueda, Gmail, Calendario, Drive, YouTube, Maps y otros productos forman naturalmente un entorno digital al que los Agentes pueden acceder. Estos activos eran portales independientes en la generación anterior de Internet, pero en la era del Agente, se pueden reorganizar en la misma tarea.
De hecho, Google ha comenzado a integrar las capacidades del Agente dispersas en varios productos en el mismo sistema de ejecución en la parte inferior. Gemini Spark, los agentes administrados en la API de Gemini e incluso algunas experiencias de agentes en la búsqueda comparten gradualmente el mismo arnés antigravedad detrás de ellos.
Pero por parte del usuario, las cosas todavía están un poco complicadas.
Hoy en día, Google también tiene agentes Gemini Spark, Workspace Studio, Antigravity, Gemini Enterprise e Information en la Búsqueda. Se enfrentan a diferentes usuarios y escenarios, pero la gente común, cuando quiere entregar un asunto complejo a Google, todavía no sabe a quién recurrir.
Para Google, ya tiene la mayoría de las condiciones necesarias para lograr todo esto. Lo que falta es una respuesta de producto bastante simple.
Y si Google realmente comprende este asunto, ya sea creando un banco de trabajo de agentes unificado o permitiendo que el mismo sistema de ejecución de agentes penetre en todo el ecosistema de Google, de modo que los usuarios se acostumbren a "encontrar Google cuando tengan problemas", el panorama competitivo del mercado global de agentes probablemente cambiará nuevamente.
Dicho esto, incluso si Google realmente pone este "grupo familiar" en un Agente, lo más probable es que los usuarios domésticos solo puedan verlo primero.
Primero echemos un vistazo a la guerra de agentes nacionales y veamos cómo se librará a continuación.
Comentarios