Agentes de IA con OpenAI: cuándo elegir Agents API o Agents SDK

OpenAI lanzó Agents API como servicio gestionado el 10 de septiembre de 2026. Al construir agentes de IA, conviene elegirla cuando mantener el estado de las sesiones, la compactación y la recuperación concentra el costo operativo; Agents SDK encaja mejor cuando la aplicación debe controlar el entorno de ejecución, el despliegue y la ruta de los datos. La decisión entre OpenAI Agents API y Agents SDK depende, por tanto, del equilibrio entre control y operaciones, ya que el servicio gestionado no añade una tarifa específica por el harness.

¿Qué opción conviene elegir?

OpenAI Agents API suele ser el mejor punto de partida para un equipo de plataforma pequeño que prepara agentes capaces de trabajar durante periodos prolongados. OpenAI opera el harness de Codex, conserva la sesión y el trabajo guardado, compacta el contexto, coordina subagentes y permite recuperarse entre turnos asíncronos. Así desaparece una categoría de infraestructura que rara vez diferencia al producto. OpenAI publicó la beta abierta el 10 de septiembre de 2026 y afirma que está disponible para todos los desarrolladores.

Para el fundador de una startup financiada, con un equipo de backend reducido y un agente que revisa documentos y puede esperar horas una aprobación, la sesión gestionada aporta más valor que controlar el bucle. El escaso tiempo del equipo de producto rinde mejor en políticas, herramientas, evaluaciones y experiencia de usuario.

OpenAI Agents SDK es preferible cuando controlar el entorno de ejecución es un requisito, no una simple preferencia. Se ejecuta dentro de la aplicación, que pasa a ser responsable del despliegue, el almacenamiento, la lógica de aprobación, la implementación de herramientas y la estrategia de estado. Hoy, el CTO de una empresa mediana con una política obligatoria de Zero Data Retention debería seguir este camino porque la beta abierta de Agents API no admite ZDR.

Si un desarrollador sénior ya dispone de una flota de workers, telemetría personalizada y un mecanismo de recuperación probado, migrar solo para dejar de mantener un bucle modesto ofrece poco valor. El SDK conserva ese control y, a la vez, proporciona agentes, herramientas, transferencias, guardrails, sesiones, revisión humana y trazabilidad.

Agentes de IA con OpenAI: Agents API vs Agents SDK

La diferencia oficial está en dónde se ejecuta la orquestación y quién conserva el estado entre tareas. Ambas opciones pueden invocar modelos y herramientas de OpenAI; ninguna elimina el costo de los tokens del modelo.

La consecuencia práctica es sencilla. Si el agente resuelve una petición breve dentro de un servicio que ya existe, la carga de propiedad del SDK puede ser mínima. Si edita archivos, se detiene para solicitar aprobación, sobrevive a desconexiones, delega trabajo y continúa al día siguiente, la API gestionada elimina más componentes con cada nuevo estado del ciclo de vida.

El harness y el sandbox son decisiones distintas

Agents API administra el bucle de razonamiento, pero no obliga a ejecutar todas las herramientas en la infraestructura de OpenAI. OpenAI denomina harness de Codex a ese bucle gestionado: coordina las llamadas al modelo, el uso de herramientas, el contexto, las sesiones y los subagentes. El entorno de ejecución es un recurso aparte, donde se ejecutan los comandos y se almacenan los archivos.

Ese entorno puede no existir, estar alojado por OpenAI o ser autogestionado. Sin un entorno, el harness aún puede llamar a servidores MCP remotos y enviar llamadas de funciones a la aplicación, pero carece de Bash, de la herramienta apply-patch y de archivos de espacio de trabajo integrados. En un sandbox alojado, OpenAI aprovisiona el espacio de trabajo Linux. En uno autogestionado, el ejecutor propio realiza comandos y operaciones con archivos a petición del harness gestionado. La guía de arquitectura deja clara esta separación.

Entender esta diferencia evita dos errores costosos. El primero es elegir Agents SDK únicamente porque el código debe ejecutarse en la VPC propia: Agents API puede conectarse a un entorno autogestionado. El segundo es elegir Agents API suponiendo que OpenAI se encargará de todo: los manejadores de funciones de la aplicación siguen ejecutándose en su código, y un ejecutor propio deja en sus manos el aprovisionamiento, la reconexión, el apagado y la persistencia de archivos.

En un flujo privado de análisis de datos, el harness gestionado podría enviar llamadas de funciones SQL a un servicio de la aplicación sin obtener acceso a un shell de propósito general. Para un agente de programación, podría usar un sandbox alojado por OpenAI. Para un sistema de compilación propietario, podría conectarse a un worker aislado propio. Son tres patrones de ejecución bajo una misma capa de orquestación gestionada.

Propiedad de la sesión: Agents API gana en tareas largas

Agents API se impone cuando la tarea dura más que una sola petición de la aplicación. Una sesión conserva la configuración del agente, la conversación y el trabajo guardado. Las entradas nuevas inician un turno asíncrono si la sesión está inactiva o reorientan el turno actual mientras sigue en marcha. La aplicación puede seguir un flujo de eventos o recibir cambios de estado mediante webhooks.

OpenAI también gestiona la compactación del contexto a medida que la sesión se acerca a su límite. Compactar consiste en sustituir detalles antiguos por una representación conservada más pequeña, de modo que el agente pueda seguir trabajando a lo largo de varias ventanas de contexto. Explicarlo es fácil; operarlo bien, no tanto: el resumen debe retener decisiones, resultados de herramientas y tareas pendientes sin arrastrar para siempre todos los tokens anteriores.

La recuperación es una ventaja menos visible. Los flujos de eventos no reproducen los eventos perdidos. Tras una desconexión, la aplicación recupera la sesión y sus elementos guardados, y continúa a partir del registro persistente en vez de reconstruir el turno desde la memoria del proceso. La guía de sesiones distingue entre un turno completado, uno fallido, una cancelación y una sesión que simplemente está inactiva.

Pensemos en un agente de revisión de contratos para el fundador de una startup financiada. Lee un documento, pide a un subagente especializado que compare cláusulas, espera la aprobación del equipo legal, recibe una corrección más tarde y genera un artefacto. El valor del producto está en la revisión. La reproducción de sesiones, la compactación, los flujos interrumpidos y la recuperación de turnos son costos operativos. Ese es el tipo de trabajo que la API gestionada busca absorber.

La limitación más sincera está en la precisión contable. Los agentes pueden hacer varias llamadas al modelo, y tanto los agentes raíz y los subagentes como los reintentos, las herramientas y los sandboxes suman costos. OpenAI señala que los campos de uso de Agents API son estimaciones, pueden ser nulos o cambiar más adelante y no constituyen una factura definitiva. Los tokens de razonamiento cuentan como tokens de salida, mientras que la entrada almacenada en caché sigue siendo facturable. La guía de uso sirve para depurar; los controles financieros deben conciliar esos datos con la facturación.

El panel también delimita la observabilidad disponible. La API pública de la beta no permite recuperar trazas detalladas ni usar exportadores de trazas externos. Si la canalización de telemetría necesita exportar cada traza por programación, esa carencia pesa más que un panel gestionado bien presentado.

Control del entorno y el despliegue: Agents SDK gana

Agents SDK es la mejor opción cuando la aplicación debe definir con exactitud cómo comienza, se pausa, se reanuda y falla una ejecución, además de cómo almacena el estado y distribuye las herramientas. Su runner se encarga del bucle del agente y las transferencias, pero el bucle vive dentro del servicio. Así, el código del producto puede envolver cada transición con sus propias transacciones, colas, límites de frecuencia, registros de aprobación y telemetría.

El SDK está disponible para TypeScript y Python, y el repositorio de Python usa la licencia MIT. Por ello, el paquete no tiene un cargo por usuario. Las llamadas a modelos de OpenAI, las herramientas alojadas, los proveedores de sandbox y el cómputo donde se ejecuta la aplicación siguen siendo costos independientes. La guía del SDK lo orienta a aplicaciones code-first que controlan el despliegue, el almacenamiento, las aprobaciones y la integración con el entorno de ejecución.

El estado es flexible, no automático. Una aplicación con el SDK puede reproducir result.history, persistir una sesión del SDK en su propio almacenamiento, asociar un ID de OpenAI Conversations o encadenar el ID de una respuesta anterior de Responses API. Todas son opciones útiles, pero la guía para ejecutar agentes advierte que mezclar la reproducción local con estado gestionado en el servidor puede duplicar el contexto si las capas no se concilian de forma deliberada.

Esa flexibilidad compensa en un servicio interno regulado. Una aprobación y la continuación del agente pueden formar parte de la misma transacción de base de datos; el estado puede residir en una región autorizada; las herramientas pueden funcionar tras controles de red privados; y la ejecución del agente puede integrarse en un sistema de trabajos existente. La capa de modelos del SDK también permite integrar otros modelos o proveedores sin convertir el harness gestionado de Codex en el límite permanente de la orquestación.

El límite es la responsabilidad operativa. Si el proceso falla, reanudarlo pasa a ser un problema de la aplicación. Una entrega duplicada en la cola exige su propia idempotencia. El crecimiento del historial, la política de compactación, los reintentos de herramientas, las migraciones de estado y la reversión de despliegues también quedan en sus manos. El SDK ofrece control sobre todo ello, y ese control solo aporta valor si la aplicación lo utiliza.

Comparativa de costos: no hay una tarifa adicional por el harness

La factura de tokens y herramientas alojadas es la misma si ambos entornos usan el mismo modelo de OpenAI, la misma combinación de tokens y las mismas llamadas a herramientas. Los precios se verificaron en las páginas públicas de OpenAI el 11 de septiembre de 2026. La tarifa estándar de contexto corto de GPT-6 Astra es de $10.00 por 1 millón de tokens de entrada y $50.00 por 1 millón de tokens de salida. La búsqueda web cuesta $10.00 por 1,000 llamadas, más los tokens del contenido recuperado a la tarifa del modelo elegido. Agents API gestionada no suma ninguna tarifa propia.

Este es un escenario normalizado. Son supuestos, no datos observados en producción:

• 1,000 trabajos de agente al mes.
• Cada trabajo consume en total 10,000 tokens de entrada sin caché y 2,000 tokens de salida con GPT-6 Astra. El contenido devuelto por la búsqueda está incluido en la asignación de entrada.
• Cada trabajo realiza una llamada de búsqueda web.
• El caso de Agents API alojada abre por trabajo una sesión nueva de contenedor de 1 GB, facturada a la tarifa publicada de $0.03. Reutilizar un sandbox reduciría esta partida.
• El caso del SDK utiliza un worker compartido que, según el supuesto, cuesta $40 al mes y tiene capacidad suficiente. Se excluyen el almacenamiento, la red y el trabajo humano.

La parte correspondiente al modelo es $0.10 de entrada más $0.10 de salida, es decir, $0.20 por trabajo. Para la combinación supuesta de 12,000 tokens, equivale a $0.0167 por cada 1,000 tokens combinados del modelo. Una llamada de búsqueda web añade $0.01, por lo que el gasto común en OpenAI alcanza $0.21 por trabajo.

Con 1,000 trabajos, Agents API y un contenedor alojado nuevo de 1 GB por trabajo cuestan $240: $210 corresponden al uso común del modelo y la búsqueda, y $30 a los contenedores. El caso del SDK cuesta $250: los mismos $210 de uso de OpenAI, más los $40 supuestos del worker. Con este volumen bajo, los contenedores alojados ganan en gasto directo.

Con 10,000 trabajos, el caso gestionado y alojado llega a $2,400: $2,100 de gasto común más $300 en contenedores. El caso del SDK alcanza $2,140 con el worker compartido supuesto. El punto de cruce del cómputo directo está en 1,334 sesiones nuevas de contenedor al mes: es la primera cantidad entera para la que $0.03 por sesión supera los $40.

La fila más importante es la de Agents API autogestionada. Si Agents API utiliza el mismo worker supuesto de $40, su total para 10,000 trabajos también es de $2,140. El harness de Codex sigue siendo gestionado, pero el costo de ejecución coincide con el escenario del SDK porque OpenAI no cobra una tarifa por el harness.

La factura monetaria aún omite la variable principal: el tiempo de ingeniería. Por encima del punto de cruce, ahorrar $260 al mes en cómputo no importa si el SDK consume varias horas de trabajo de plataforma. Por debajo, mantener un sistema maduro basado en el SDK puede costar casi nada.

Para aplicar límites presupuestarios estrictos a cualquiera de las dos arquitecturas, combine las estimaciones de carga con las protecciones por proyecto descritas en Controles de presupuesto para API de agentes de IA en 2026. Una estimación sirve para planificar, no para imponer el límite.

Migrar a Agents API: el costo de dejar el SDK

Pasar de Agents SDK a Agents API es una migración del entorno de ejecución, no un simple cambio de nombre de paquete. Las definiciones de agentes y los esquemas de herramientas pueden resultar familiares, pero los ID de sesión, las sesiones del SDK, las conversaciones de Responses, las sesiones de Agents API y los sandboxes son recursos diferentes. El estado debe tratarse como datos que cruzan un límite, no como un identificador que puede trasladarse intacto.

1. 1

   Fijar el contrato de comportamiento

   Documente las instrucciones actuales del agente, los esquemas de herramientas, los puntos de aprobación, el formato de salida, el presupuesto de tokens y la política ante fallos. Mantenga sin cambios el modelo y las herramientas durante la comparación para no confundir una variación de calidad con una mejora del entorno de ejecución.

2. 2

   Trasladar la configuración de agentes y herramientas

   Pase el modelo, las instrucciones, las conexiones MCP y las definiciones de funciones a la configuración de Agents API. Los manejadores de funciones de la aplicación aún necesitan un servicio que reciba llamadas y devuelva resultados; la orquestación gestionada no los convierte automáticamente en funciones alojadas.

3. 3

   Trazar el límite del estado

   Inicie las conversaciones nuevas como sesiones de Agents API y guarde sus ID junto a los registros de conversación de la aplicación. Mantenga accesibles los historiales anteriores del SDK durante la transición. Si es necesario continuar con contexto antiguo, transforme únicamente el estado de negocio imprescindible en una entrada explícita, sin fingir que una sesión del SDK es una sesión de Agents API.

4. 4

   Sustituir la infraestructura del ciclo de vida

   Cambie el punto de entrada del runner dentro del proceso por la creación de sesiones, eventos, elementos guardados, acciones requeridas, webhooks, cancelación y eliminación. Añada idempotencia a cada webhook y resultado de función, porque el estado gestionado no elimina el riesgo de entregas duplicadas en el borde de la aplicación.

5. 5

   Ejecutar en paralelo y validar regresiones

   Use el mismo conjunto de evaluaciones en ambos caminos. Compare el éxito de las tareas, el total de tokens de entrada y salida, las llamadas a herramientas, el tiempo transcurrido, la recuperación y la intervención humana. Traslade tráfico solo cuando el camino nuevo cumpla el contrato anterior.

Un presupuesto ilustrativo permite concretar la decisión. Supongamos que un flujo existente tiene tres herramientas de función, sesiones persistentes y aprobación humana. Se asignan 24 horas de ingeniería a $150 por hora: 6 horas para configuración y correspondencia de herramientas, 8 para sesiones y ciclo de vida, 6 para webhooks, recuperación e idempotencia, y 4 para regresiones y comprobaciones de costos. El costo único de la migración sería de $3,600.

Si la compactación, la recuperación, las sesiones y la orquestación gestionadas ahorran las 6 horas de ingeniería mensuales supuestas, el ahorro laboral es de $900 al mes y la inversión se recupera en cuatro meses. Si el camino actual con el SDK solo exige atención ocasional, quizá nunca se recupere. Los supuestos son lo importante: la migración se justifica por las operaciones que elimina, no por tokens más baratos.

¿Quién no debería migrar a Agents API?

No conviene migrar si los controles de datos de la beta abierta no superan el proceso de compras. La descripción de Agents API vigente indica que la residencia de datos se limita a Estados Unidos y que Zero Data Retention no está disponible. Un sandbox autogestionado no cambia esta política, porque el harness y la sesión siguen en el servicio gestionado.

Conviene permanecer en Agents SDK si se cumple alguna de estas condiciones:

• El entorno de ejecución debe funcionar bajo un planificador, un límite transaccional o unos requisitos de latencia personalizados que la aplicación controle directamente.
• Las políticas de almacenamiento, exportación de trazas o residencia de datos no encajan en la beta abierta gestionada.
• El agente necesita flexibilidad de proveedores o una abstracción de modelos que no deba depender del harness de Codex.
• El sistema basado en el SDK ya ofrece compactación, recuperación, observabilidad y despliegue fiables, con poco mantenimiento continuo.
• La mayoría de las tareas son breves y sin estado, por lo que una sesión gestionada persistente elimina poca infraestructura.

La fase de beta abierta también influye en la decisión. OpenAI afirma que realizará iteraciones rápidas antes de la disponibilidad general. Un equipo con un calendario rígido de control de cambios puede preferir evaluar ahora y migrar cuando el contrato se estabilice.

El SDK tiene su propio caso de descarte. Una startup pequeña no debería elegirlo solo para evitar un bloqueo de proveedor hipotético mientras reconstruye en silencio las sesiones, la recuperación, el ciclo de vida del sandbox y la orquestación. El control que el producto nunca aprovecha acaba convertido en deuda de mantenimiento.

En el caso de agentes que ejecutan código, el entorno debe compararse por separado mediante Los mejores sandboxes de código para agentes de IA en 2026. Elegir un sandbox no responde quién debe controlar el estado de orquestación.

Los resultados de clientes son orientativos, no transferibles

Las primeras cifras favorecen al camino gestionado, pero son testimonios de clientes publicados en el anuncio de OpenAI del 10 de septiembre, no un benchmark independiente y controlado. SafetyKit informó de una reducción del 60% en el costo por caso. Hypha reportó una caída del 86% en las respuestas fallidas del agente después de separar el harness gestionado de su sandbox. Ciridae comunicó que su puntuación de evaluación subió de 0.71 a 0.85 y que la latencia se redujo 4x.

Esos resultados demuestran que el límite del entorno de ejecución puede influir. No permiten calcular cuánto ahorrará otra migración, porque el anuncio no normaliza la arquitectura anterior de cada cliente, la combinación de modelos, el volumen de tokens, la dificultad de las tareas ni el trabajo de ingeniería. Sirven para justificar una evaluación en paralelo, no para hacer un pronóstico.

Preguntas frecuentes sobre OpenAI Agents API y Agents SDK

¿Por qué usar OpenAI Agents SDK?

OpenAI Agents SDK conviene cuando la aplicación necesita controlar directamente el despliegue, el almacenamiento, las decisiones de aprobación, la implementación de herramientas y el bucle de ejecución. Ofrece los componentes de agentes de OpenAI sin trasladar la orquestación a Agents API gestionada.

¿Cuál me conviene más, OpenAI Agents SDK o PydanticAI?

Esa es otra comparación entre frameworks. Primero hay que decidir si OpenAI gestionará el harness de Codex mediante Agents API o si la aplicación controlará un entorno basado en SDK; después pueden compararse los frameworks dentro del segundo camino.

¿Cuál es el mejor SDK para agentes de IA?

Ningún SDK es el mejor para todas las arquitecturas. OpenAI Agents SDK encaja bien cuando su bucle para TypeScript o Python, sus herramientas, transferencias, guardrails, sesiones e integraciones con OpenAI responden a las necesidades de la aplicación y se desea controlar el despliegue.

¿OpenAI Agents SDK es gratis?

Agents SDK para Python tiene licencia MIT, así que el paquete no cobra una licencia. Aun así, hay que pagar las llamadas a modelos, las herramientas de pago, los servicios de sandbox y la infraestructura donde se ejecuta la aplicación.

¿Cómo se usa OpenAI Agents SDK?

Instale el paquete oficial para TypeScript o Python, defina un agente con instrucciones y herramientas, elija una sola estrategia de estado y ejecútelo dentro de la aplicación. Añada aprobaciones, persistencia, trazabilidad y sandboxing únicamente donde el flujo los requiera.

¿Cuánto cuesta un agente de OpenAI?

Sume la entrada del modelo, la entrada en caché, la salida, las llamadas a herramientas, el sandbox o el cómputo de la aplicación, los servicios de terceros y el trabajo operativo. Agents API no añade una tarifa por el harness; con los supuestos de este artículo, el costo directo del entorno cambia de ganador en 1,334 sesiones nuevas de contenedor de 1 GB al mes frente a un worker compartido de $40.

¿La API de OpenAI es gratis o de pago?

El uso de modelos y herramientas de pago de la API de OpenAI se factura conforme a los precios de la API. Un plan de ChatGPT es un producto con un contrato independiente y no cubre el consumo de API de una aplicación creada con Agents API o Agents SDK.

¿Por qué pagar $20 por ChatGPT?

Esa es una decisión sobre la suscripción a ChatGPT, no sobre Agents API frente a Agents SDK. La suscripción da acceso al producto ChatGPT según las condiciones del plan; el uso de la API de OpenAI se factura por separado.

¿OpenAI Agent Builder es gratis o de pago?

Agent Builder estaba incluido en el precio estándar de los modelos de la API, pero no es ninguno de los dos entornos comparados aquí. OpenAI afirma que está retirando Agent Builder y que su cierre está programado para el 30 de noviembre de 2026.

La acción para el lunes

La próxima semana, elija un flujo de trabajo prolongado y ejecute una comparación en paralelo. Mantenga constantes el modelo, las instrucciones, el presupuesto de tokens, las herramientas y el conjunto de evaluaciones. Envíe las conversaciones de prueba nuevas a Agents API, conserve los historiales actuales de usuarios en el camino del SDK y utilice el mismo entorno de ejecución en ambos lados si quiere aislar el valor del harness gestionado.

Registre el éxito de las tareas, los tokens totales, las llamadas a herramientas de pago, las sesiones facturadas de sandbox, los incidentes de recuperación, la intervención humana y el tiempo de ingeniería. Elija Agents API si el trabajo eliminado en sesiones y recuperación compensa el control cedido. Mantenga Agents SDK si el servicio gestionado incumple un requisito de datos o ahorra demasiado poco tiempo operativo para recuperar el costo de migración.

Antes de cambiar el entorno de sus agentes, consulte la lista de control para auditar flujos de negocio con IA.