Agente de código nocturno: configuración y cálculo de costes

Tienes un cambio multiarchivo que te llevaría una tarde si te sentaras a hacerlo. La tentación es pasárselo a un agente de larga ejecución y revisar el resultado por la mañana. El problema es la factura: la propia Agents API no añade una tarifa separada, pero pagas por los tokens y las herramientas que usa el agente. La jugada nocturna solo funciona si la tarea está acotada, el entorno está elegido y el coste está estimado antes de que empiece la ejecución. Probablemente tienes unas horas antes de irte a dormir, no un sprint completo. El agente es útil cuando convierte una larga espera en una revisión breve.

OpenAI ha lanzado la Agents API en beta pública. Soporta agentes en la nube que pueden ejecutarse durante horas, ejecutar código y trabajar con archivos. Utiliza el arnés de código abierto Codex como base y añade MCP, funciones personalizadas y funciones integradas como la búsqueda web. Para quien construye fines de semana, el valor está en la posibilidad de dejar una tarea acotada en ejecución. La configuración es un pre-vuelo.

Deja solo una tarea con revisión matutina

Empieza con un cambio que tenga una línea de meta clara. Un refactor en varios archivos, una suite de pruebas fallida o una pequeña migración son el tipo de trabajo que se puede describir en un prompt breve y revisar por la mañana. Un build en verde, una prueba que pasa o un diff que puedes leer es terminado. «Mejorar la app» no es una línea de meta.

El prompt debe nombrar los archivos, el comportamiento y el comando que demuestra el éxito. Si no puedes escribir ese comando, la tarea no está lista. Una línea de meta clara también acelera la revisión matutina, porque estás comprobando un resultado en lugar de adivinar si el agente hizo algo coherente.

La Agents API gestiona el contexto automáticamente, ejecuta herramientas en paralelo y puede delegar trabajo en subagentes. Eso ayuda, pero no elimina la necesidad de una tarea clara. Si el agente puede ramificarse en investigación, refactor y cambios de dependencias, la ejecución se vuelve más difícil de revisar por la mañana.

Calcula el coste de la ejecución antes de que el agente empiece

Las cargas de trabajo pueden ejecutarse en sandboxes alojados por OpenAI o en entornos de partners como Cloudflare, Vercel y Oracle. La elección importa porque el sandbox es donde trabaja el agente, y la factura sigue al trabajo. Los sandboxes alojados por OpenAI se facturan a tarifas estándar de contenedor, mientras que las llamadas al modelo se facturan por separado según la tarifa de API del modelo seleccionado.

Escribe la estimación en un archivo de texto. Si la estimación se siente demasiado alta, reduce la tarea antes de empezar. En una ejecución sin supervisión, la elección del modelo a menudo sorprende, así que elígelo con el mismo cuidado con el que elegirías a un compañero de equipo.

El error habitual es tratar una ejecución nocturna como un experimento gratuito. Si la tarea es vaga, el agente puede seguir trabajando de formas que no habías planificado. Un límite de tiempo y una regla de parada son lo que impiden que el fin de semana se convierta en una sorpresa.

Ejecuta primero la lista de verificación pre-vuelo

• Define la tarea multiarchivo. Escribe el objetivo, los archivos implicados y la prueba de aceptación. El prompt debe indicar qué cambiar y qué debe pasar.
• Establece un límite de tiempo. Elige un tiempo máximo de ejecución para la corrida nocturna. Necesitas un paro duro que puedas configurar o aplicar, no la esperanza de que el agente termine antes.
• Elige el sandbox. Selecciona el entorno que se ajuste a la tarea, los archivos y las herramientas. El paso está completo cuando tienes un sandbox con nombre, no un lugar vago en la nube.
• Estima tokens, horas de contenedor y llamadas a herramientas. Escribe un presupuesto aproximado para la línea del modelo, la línea del sandbox y la línea de herramientas. El número debe ser uno que estés dispuesto a perder en un experimento de fin de semana.
• Define condiciones de parada. Indica cuándo debe detenerse el agente: tarea completada, pruebas fallando, presupuesto alcanzado o límite de tiempo superado. La regla debe impedir que un trabajo terminado se convierta en una factura más larga.

Si la ejecución se detiene antes de tiempo, es un buen resultado. Si se detiene porque la línea de presupuesto está cerca, también es un resultado útil. El pre-vuelo hace fácil la decisión matutina: mantener el diff, descartar la ejecución o reducir la siguiente tarea.