La facturación por segundo, explicada: por qué una sandbox de 20 segundos cuesta $0.00055

«Facturado por segundo» es una de esas frases que suenan completas y no lo son. Detrás hay varias decisiones que cambian lo que pagas: qué se mide, cuándo arranca y se detiene el reloj, si hay un mínimo, cómo se tratan las fracciones de céntimo y cuándo sale realmente el dinero de tu saldo.

Este artículo deja por escrito nuestras respuestas, con la aritmética, para las sandboxes de código. El objetivo es que puedas prever una factura al céntimo antes de ejecutar nada, y reconocer el punto en el que pagar por segundo es el modelo equivocado para tu carga.

La unidad: vCPU y RAM reservadas

El precio de una sandbox es el precio de los recursos que reserva su tarifa:

• $0.040 por vCPU-hora
• $0.013 por GiB de RAM y hora

La tarifa small (0.5 vCPU, 1 GB) cuesta por tanto 0.5 × 0.040 + 1 × 0.013 = $0.033 por hora, unos $0.0000092 por segundo. La más grande, max (8 vCPU, 16 GB), cuesta $0.528 por hora.

Medimos la reserva, no el consumo. Una sandbox que espera su siguiente comando cuesta por segundo lo mismo que una que compila un proyecto. Medir la CPU real parecería más justo sobre el papel, pero haría imposible conocer el precio por adelantado, y la capacidad se te reserva igualmente. El tráfico saliente no se factura.

El reloj: de la creación a la eliminación

Una sandbox efímera se factura desde que se crea hasta que se elimina. Eso incluye el tiempo inactivo antes de que el tiempo de espera por inactividad la elimine, 300 segundos por defecto.

De ahí salen la mayoría de las sorpresas. Un script de dos minutos, en una sandbox que nadie elimina, se factura por siete: dos de trabajo y cinco esperando el tiempo límite. La solución es aburrida: elimina la sandbox cuando termines (el bloque with del SDK lo hace por ti) o reduce el tiempo de espera por inactividad.

El mínimo: 60 segundos por sandbox

Cada sandbox efímera se factura por al menos 60 segundos de vida. Arrancar una microVM, conectar su disco y su red y desmontarlo todo después cuesta lo mismo tanto si el código de dentro corre un segundo como cincuenta.

El mínimo se aplica una sola vez, al terminar la sandbox, y solo si su vida total fue inferior a 60 segundos. No hay un mínimo adicional por hora ni por comando.

Acumulación y cargo: microdólares y céntimos enteros

Esta es la parte que «por segundo» no suele contar. El host de sandboxes registra el uso en tramos horarios, uno por sandbox. Una vez por minuto, la tarea de facturación recoge los tramos cerrados, los valora y carga el saldo.

La valoración se hace en millonésimas de dólar. El cargo, en céntimos enteros. Lo que queda por debajo del céntimo permanece en tu cuenta y se suma al siguiente cargo; no se redondea hacia arriba ni por sandbox ni por hora.

A pequeña escala, importa. Cien sandboxes de 20 segundos acumulan 100 × $0.00055 = $0.055. Se te cargan cinco céntimos y medio céntimo espera al siguiente lote. Si cada sandbox se redondeara a un céntimo, el mismo trabajo costaría un dólar.

Hay otras dos propiedades que conviene conocer:

• Cada tramo se cobra exactamente una vez. El registro de uso y el cargo se escriben en una misma transacción de base de datos, con la sandbox y la hora como clave. Un reintento o una confirmación perdida no pueden cobrar dos veces.
• Las caídas retrasan los cargos, no los pierden ni los duplican. Si la facturación no puede contactar con el host de sandboxes, no se confirma nada, los tramos esperan y se cargan cuando vuelve la conexión.

La consecuencia es que el panel puede ir hasta una hora por detrás de la cifra en vivo. Para la cifra en vivo, GET /sandboxes/{id}/usage devuelve billed_usd y un estimated_total_usd de la sandbox hasta ahora.

Sandboxes persistentes: por hora iniciada, con tope

Las sandboxes persistentes conservan su disco entre sesiones, hasta 30 días. Se facturan por hora iniciada: 61 minutos son dos horas. A cambio, un mes natural (UTC) nunca cuesta más de 730 horas menos un 25 %.

Para la tarifa standard, ese tope es de $36.14 al mes en lugar de $48.18. Mientras una sandbox persistente está en pausa, no se factura en absoluto.

Cuando se acaba el saldo

El saldo nunca baja de cero. Las sandboxes nuevas se rechazan con 402 insufficient_balance. Las efímeras que ya están en marcha terminan con su tiempo de inactividad o su TTL. Las persistentes se pausan tras 24 horas sin recarga y se reanudan solas cuando añades fondos. Las instantáneas en pausa se guardan 14 días. Después la sandbox se borra y su id responde 410 sandbox_deleted.

Si un agente de IA crea sandboxes por ti, fija un límite diario y mensual. Al alcanzarlo se devuelve 429 budget_exceeded con la hora en que se reinicia, algo sobre lo que un programa puede actuar.

Dónde pierde la facturación por segundo

Pagar por segundo es excelente para trabajo que se mide en segundos y minutos. Empeora cuanto más dura el trabajo.

El punto de cruce está aproximadamente donde una carga funciona más de unas pocas horas al día. A partir de ahí pagas por una flexibilidad que no usas, y un servidor alquilado por meses es bastante más barato por hora. La forma honesta de ver la facturación por segundo es como el precio de no tener que planificar capacidad, no como un descuento.

Una estimación rápida

Precio por hora de la tarifa × segundos que existirá la sandbox ÷ 3600, con 60 segundos como mínimo. Suma el tiempo de inactividad si no vas a eliminarla tú. Para las persistentes, redondea cada sesión a horas enteras y detente en el tope mensual.

Todas las reglas, cuotas y la API de presupuesto están en límites y facturación de las sandboxes; las llamadas usadas arriba, en la referencia del SDK. Si te preguntas qué estás alquilando exactamente por segundo, las microVM de Firecracker explicadas lo cuentan, y lo que los agentes de IA necesitan de verdad de la infraestructura explica por qué el modelo de facturación importa tanto cuando son programas, y no personas, quienes crean las máquinas.