
Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Un job nocturno que escanea las excepciones de facturación de ayer, agrupa duplicados y escribe una nota de triaje. Solo necesita existir alrededor de una hora al día. Dos entradas de cron levantan un contenedor de agente nuevo a las 02:59 y lo derriban a las 04:01. Las otras 23 horas, no está ejecutándose, ni en caliente, ni facturado.
Un agente. Una hora por noche. Inactivo las otras veintitrés. La factura del servidor de tarifa plana no cambia de ninguna forma.
No hay pool en caliente, ni servicio scheduler, ni demonio de pegamento haciendo polling de trabajo. Una entrada hoody-cron hace POST a la URL de spawn de hoody-agent a las 02:59. El agente hace su run y sale. Un segundo cron a las 04:01 llama DELETE para asegurarse de que el contenedor desapareció. Esa es toda la máquina.
Dos filas de cron en una base de datos. Una imagen de agente. El contenedor solo existe para el trabajo, luego deja de existir. Sin pool en caliente, sin primitiva de tarea programada, sin demonio de ciclo de vida que tengas que operar tú mismo.
Cinco momentos. El agente está vivo durante los tres del medio. Fuera de esa hora, la fila en la tabla de contenedores no está.
La entrada de cron billing-reconcile-wake dispara. Hace POST a api.hoody.com con ai: true y hoody_kit: true. Un contenedor nuevo levanta con un sistema de archivos limpio y el prompt del agente cargado.
El agente lee la tabla billing-exceptions de ayer sobre Hoody SQLite y le pide a un LLM que agrupe las filas por código de razón — ya sea a través del Gateway IA de Hoody (costo del proveedor + 5%, sacado de tu Saldo de IA) o tu propia clave directo a Anthropic / OpenAI / tu proveedor. Sin file-share montados. Solo URLs.
Escribe una sola nota de triaje por cluster de vuelta a la misma URL de SQLite, luego envía una notificación con el resumen diario. Tiempo de pared total hasta ahora: unos treinta minutos.
El proceso del agente devuelve 0 y el contenedor sale por sí solo. Hoody-containers lo marca como detenido. Desde este segundo en adelante, nada del agente está corriendo, en caliente o facturado.
Una segunda entrada de cron dispara DELETE sobre el id del contenedor. Si el agente ya salió, esto es un no-op 200 OK. Si se colgó, el contenedor se derriba igual. Idempotente y sin supervisión.
Cinco timestamps, dos filas de cron, un contenedor que vive sesenta y dos minutos. La noche corre sola, y te enteras de que corrió leyendo la nota de triaje por la mañana.
Un worker siempre encendido es la forma equivocada para un job que corre una vez al día. En Hoody el sustrato es de tarifa plana — la ventaja no es facturación por segundo, es sin pool en caliente, sin servicio scheduler, sin demonio de pegadura que operar.
No hay pool en caliente sentado en memoria. Ni servicio de 'tarea programada' guardando estado. La fila en la tabla de contenedores no está durante veintitrés horas del día. El servidor de tarifa plana que ya alquilas ejecuta el trabajo; las horas inactivas no generan una línea de factura aparte.
Hoody factura la caja, no el tiempo de ejecución. Un agente nocturno de 60 minutos y un worker siempre encendido 24/7 caen en la misma factura de servidor de tarifa plana. La ventaja no es 'paga solo por lo que usas' — es no pagar dos veces el overhead de pool en caliente que no necesitas.
No escribes una Lambda de despertar, un worker de 'levanta el contenedor' o un watchdog que lo retire. Hoody-cron hace POST. Hoody-containers lanza el spawn. El agente sale. Un segundo cron hace POST DELETE. Esa es toda la superficie.
La mayoría de plataformas de agentes mantienen al worker en caliente veinticuatro horas al día para que esté listo en menos de un segundo. Para un job batch de las 3 AM ese es justo el tradeoff equivocado. Un cold-spawn en unos segundos está bien cuando el horario es tuyo.
Un contenedor de agente siempre encendido, o un asiento en pool caliente reservado para un agente que corre una vez al día, está vivo 720 horas al mes. 719 de esas horas, no hace nada.
Inactivo es la línea del recibo en plataformas por-segundoUn contenedor de vida corta lanzado por una entrada de cron existe una hora por noche. Treinta horas al mes, en total. El proceso del agente devuelve 0 y la fila en la tabla de contenedores se ha ido.
Hoody factura el servidor, no el tiempo de ejecución. La columna 'vivo' muestra cuándo el agente existió cada noche — el mismo servidor de tarifa plana se ejecuta esté o no esté. Los precios comienzan en $29/mes y varían según especificación, región y duración del alquiler.
Un agente que existe solo cuando hay trabajo para él.
Los patrones que pagan por que un agente exista las 24 horas. En Hoody, el agente corre dentro del servidor de tarifa plana que ya alquilas — sin pool en caliente, sin servicio scheduler, sin medidor por segundo.
Un agente que existe solo cuando hay trabajo para él.