OpenAI confirma cobros de más por contenedores en Agents API

Un usuario de Reddit reportó el 18 de septiembre de 2026 una factura de 1600 dólares en Agents API tras dejar sesiones alojadas inactivas. OpenAI reconoció ese día que había cobrado de más por los contenedores y dio el incidente por resuelto el 19 de septiembre. Mi conclusión es investigar los cobros inesperados antes de asumir que responden a las tarifas normales, sin dejar por ello de definir cómo liberar los recursos de cada sesión. [1] [2]

¿Qué pasó con la factura de 1600 dólares?

La publicación recibió una actualización importante: su autor dijo que OpenAI había reconocido un problema de facturación y añadió un enlace al incidente oficial. Eso cambia mi lectura de la advertencia original. Da motivos para investigar un cobro incorrecto, pero no sirve como ejemplo fiable del coste habitual de las sesiones inactivas. [1] [2]

El usuario describió tareas recurrentes que tardaban unos cinco minutos y costaban alrededor de 0,20 dólares por el uso del modelo tras cambiar a Luna. Había creado 138 sesiones y las conservaba como registro del trabajo anterior. Según su publicación, el consumo mostrado superó después los 200 dólares y luego los 1600. Esas cantidades, los plazos y los detalles de la carga de trabajo siguen siendo el relato del autor. [2]

La página de estado de OpenAI confirma de forma independiente el incidente general. El 18 de septiembre, la empresa anunció que investigaba cobros inesperadamente altos por contenedores alojados y que preparaba reembolsos. El 19 de septiembre informó de una medida que protegía las sesiones nuevas y después dio el incidente por resuelto. El aviso no confirma la factura exacta de este usuario ni que ya se hubiera efectuado su reembolso. [1]

Para quien evalúa de qué se encarga Agents API, esa distinción importa. Una factura incorrecta puede hacer que un servicio parezca demasiado caro aunque el precio previsto sea otro. Yo conservaría los identificadores de las sesiones y los registros de facturación antes de decidir si hay que rediseñar la carga de trabajo.

¿Cuánto cuesta normalmente un sandbox alojado?

OpenAI documenta dos cobros separados: los tokens que usa el modelo y las tarifas del contenedor que aloja el sandbox. Por tanto, consultar solo el contador de tokens deja fuera parte del coste de la tarea. La guía de entornos alojados remite expresamente a las tarifas estándar de contenedores. [3]

El 22 de septiembre de 2026 comprobé que la tabla de tarifas mostraba los siguientes importes. La segunda columna conserva su unidad de 20 minutos; la última es el resultado de dividir entre 20, no una afirmación de que todas las sesiones se facturen por minuto. [4]

La nota al pie dice que las sesiones de contenedor que cumplan los requisitos se facturan por minuto, con un mínimo de cinco minutos. La página de precios no define esos requisitos ni detalla cómo se mide cada periodo de inactividad. Yo confirmaría esos puntos para la carga de trabajo concreta antes de usar la tarifa equivalente en una previsión. La tabla de precios por sí sola no permite reconstruir la factura de Reddit. [4]

Este problema es distinto del de los límites de uso de cinco horas en las suscripciones a Codex. La cuota de una suscripción controla el uso incluido; una aplicación que usa una API debe llevar la cuenta de los recursos que crea. Mezclar ambas cuestiones dificulta entenderlas.

¿El sandbox se libera cuando termina la tarea?

Terminar una tarea y limpiar su sandbox son pasos separados. OpenAI dice que los sandboxes conectados reciben señales entre turnos para mantenerse activos, llamadas keep-alives, y que pueden caducar tras una hora sin actividad ni esas señales. Por tanto, esa hora no garantiza que el sandbox de cada tarea terminada desaparezca exactamente 60 minutos después. [3]

La acción de limpieza documentada es eliminar la sesión cuando ya no se necesite. Una respuesta 409 puede significar que la preparación o la ejecución aún está terminando; OpenAI aconseja esperar y volver a intentarlo con un número limitado de intentos. Eliminar la sesión retira el recurso de la API, aunque la limpieza física puede continuar de forma asíncrona. [3] [5]

Cancelar tiene otra finalidad. Detiene un turno activo y conserva la conversación y el trabajo anterior. La guía de sesiones también advierte que una sesión inactiva no demuestra que el resultado sea correcto: las aplicaciones deben examinar el estado final del turno y su salida. Yo registraría por separado si se aceptó el trabajo y si se liberaron sus recursos. [7]

Al conservar contexto útil para los agentes de programación, también hay que gestionar los recursos: el conocimiento guardado y un espacio de trabajo activo cumplen funciones diferentes. Para una tarea recurrente, guardaría expresamente el resultado aceptado y el historial necesario, y después decidiría si otro turno necesita realmente el mismo entorno.

Qué cambiaría en una aplicación con agentes

Haría que la aplicación siguiera cada sesión desde su creación hasta su limpieza, incluidas las tareas fallidas. Cada sesión tendría un responsable y una fecha límite de conservación. Tras guardar las salidas necesarias, un proceso de limpieza solicitaría la eliminación, registraría la respuesta y reintentaría los fallos temporales hasta un límite. Una comprobación periódica independiente detectaría las sesiones que el proceso habitual de finalización hubiera pasado por alto.

Este es el diseño que yo propongo para una aplicación. OpenAI no ha dicho que sus clientes debieran tomar estas medidas para evitar el incidente de facturación. Su utilidad es poder examinar el uso de recursos. Si un cobro parece incorrecto, quiero saber qué sesiones existían, qué se ejecutó en ellas y cuándo se solicitó su limpieza.

También compararía los registros de la aplicación con los datos de facturación. OpenAI describe los recuentos de tokens por sesión y turno como provisionales: pueden faltar o cambiar a medida que llegan los datos contables, y no constituyen una factura final. Su guía indica que se debe incluir el trabajo delegado, los reintentos y los cobros aplicables por herramientas o cómputo al estimar el coste de la tarea completa. [6]

Por último, comprobaría si la tarea necesita un sandbox. La opción documentada environment.type: "none" puede servir para trabajos realizados mediante herramientas externas, aunque elimina Bash integrado, la aplicación de parches y los archivos del espacio de trabajo. La elegiría para tareas cuyas herramientas necesarias siguieran disponibles sin ese entorno. [8]

En la próxima tarea recurrente, revisaría juntos el resultado guardado y el registro de limpieza. Ambos forman parte de una ejecución terminada.