Todo agente que escribe código necesita algún lugar donde ejecutarlo. Ese "algún lugar" ya es una categoría de producto con al menos una docena de proveedores, cuatro modelos de facturación incompatibles entre sí y páginas de marketing que citan tiempos de arranque en frío medidos bajo condiciones que nadie publica.

Esta comparación normaliza las unidades. Cubre las cinco plataformas que la mayoría de los equipos pone en su lista corta, E2B, Daytona, Modal Sandboxes, Cloudflare Sandbox SDK y Vercel Sandbox, junto con Runloop, Fly.io Sprites y Northflank allí donde cambian la respuesta.

Las cuatro preguntas que realmente deciden

Las matrices de características de esta categoría son en su mayoría ruido. Cuatro propiedades cambian la arquitectura, y todo lo demás es preferencia:

  • Arranque en frío bajo concurrencia: un ciclo de agente que crea un sandbox por cada llamada a herramienta paga ese impuesto miles de veces al día.
  • Persistencia del sistema de archivos entre turnos: ¿el turno 2 ve el pip install del turno 1, o el agente reconstruye su mundo desde cero?
  • Política de salida a internet: ¿puede el sandbox alcanzar internet, se puede desactivar eso, y se puede cambiar de opinión a mitad de sesión?
  • Facturación en reposo: los agentes pasan la mayor parte de su tiempo de reloj esperando al modelo. Alguien está pagando esos segundos.

¿Qué dicen de verdad los números de arranque en frío?

Las cifras de los proveedores no son comparables entre sí. La página de precios de Daytona promociona creación de sandbox bajo los 90 milisegundos. A E2B se lo suele citar en torno a los 150 milisegundos. Modal publicita arranques en frío bajo el segundo para contenedores precacheados. Ninguna de estas cifras indica concurrencia, región, tamaño de imagen, ni si el reloj se detiene cuando la API acusa recibo o cuando se ejecuta el primer comando.

El conjunto de datos público más útil es la tabla de posiciones de sandboxes de ComputeSDK, que es de código abierto y corre de forma programada. Mide el tiempo hasta interactivo (TTI): el lapso entre create() y el primer comando exitoso dentro del sandbox, con 100 iteraciones por proveedor, lanzadas de forma concurrente en una sola ráfaga, desde un equipo de 4 vCPU en el norte de Virginia.

De la corrida del 21 de agosto de 2026 salen tres lecturas que importan más que el ranking:

  • Una ráfaga no es la misma prueba que una secuencia: la mediana más rápida publicada por Daytona es real, y en una corrida anterior de su página de proveedor creó sandboxes con una mediana de 0,10 segundos cuando se lanzaban de a uno. En la corrida en ráfaga de agosto anotó la mediana más rápida del grupo y completó 37 de 100 intentos. Una mediana que solo se alcanza en un tercio de las llamadas no es una cifra de latencia, es una cifra de capacidad. La lógica de reintento no es opcional en ninguna de estas plataformas.
  • La latencia de cola es el número contra el cual diseñar: la mediana de Runloop y la de Modal están separadas por 10 milisegundos. El percentil 95 de Runloop es 3,3 veces el de Modal. Si el presupuesto de experiencia de usuario del agente es un segundo, la mediana no dice casi nada.
  • Cloudflare está midiendo otro producto: Sandbox SDK se apoya en Cloudflare Containers, que agenda una instancia de contenedor y arranca una imagen. Eso es arquitectónicamente una operación más pesada que reanudar una máquina virtual Firecracker precalentada, y las medianas de 5 segundos lo reflejan. El propio anuncio de disponibilidad general de Cloudflare es franco sobre la forma del problema: arrancar un sandbox, clonar un repositorio y correr npm install toma unos 30 segundos, mientras que restaurar el mismo entorno desde un respaldo toma cerca de dos.

Cómo reproducir esto por cuenta propia

La tarea que vale la pena medir es la que corre el agente, no un echo hello. Un banco de pruebas útil ejecuta la misma unidad de trabajo en todas partes: instalar pandas, leer un CSV, graficarlo y devolver un PNG. Hay que cronometrar cuatro puntos de control por separado.

Código
# checkpoints: t_create -> t_ready -> t_deps -> t_result
# 100 iteraciones secuenciales, luego 100 concurrentes, reportar mediana/P95/P99
import time, statistics

def one_run(provider):
    t0 = time.perf_counter()
    sbx = provider.create()              # API acusa recibo
    t1 = time.perf_counter()
    sbx.exec("python -c 'print(1)'")     # primer comando responde: TTI
    t2 = time.perf_counter()
    sbx.exec("pip install pandas matplotlib")
    t3 = time.perf_counter()
    sbx.exec("python /work/plot.py")     # escribe /work/out.png
    png = sbx.read_file("/work/out.png")
    t4 = time.perf_counter()
    sbx.kill()
    return dict(create=t1-t0, tti=t2-t0, deps=t3-t2, task=t4-t3, bytes=len(png))

Hay que reportar tti y task por separado. Los proveedores optimizan el primero y a los lectores les importa el segundo. Fijar la región, fijar la imagen y publicar tanto la serie secuencial como la concurrente, porque responden preguntas distintas.

Precio por segundo, normalizado

Al convertir a una unidad común las tarifas publicadas al 27 de agosto de 2026 aparecen dos notas al pie que la gente suele malinterpretar. Modal cobra por núcleo físico, que define como 2 vCPU, así que el equivalente por vCPU es el que corresponde comparar.

  • El nivel de sandbox de Modal cuesta aproximadamente tres veces su tarifa estándar de Function (0,00003942 frente a 0,0000131 dólares por segundo de núcleo), y la selección de región agrega entre 1,5 y 1,75 veces por encima de eso. El precio de sandbox no es el precio de cómputo que Modal muestra en portada.
  • Las tarifas de GPU de Daytona se reproducen por todas partes como 3,95 dólares por hora para una H100. Su página de precios en vivo lista la H100 bajo demanda a 2,27 dólares por hora y la H200 a 2,61 dólares. Las tablas comparativas de terceros en esta categoría quedan obsoletas en menos de un trimestre.

Costo por cada mil ejecuciones

Las tarifas no son costos. El modelo de cálculo fija la carga de trabajo y la hace pasar por cada lista de precios. Los supuestos: sandbox de 2 vCPU y 4 GiB, mil ejecuciones, sin piso de plan, sin tráfico de salida y región por defecto (Vercel iad1, Cloudflare standard-3 a 2 vCPU, 8 GiB y 16 GB de disco, ya que los tamaños de instancia son fijos).

El escenario A es una ráfaga corta: 90 segundos de vida con 50% de uso promedio de CPU. El escenario B es el que pesa en reposo: 10 minutos de vida con 5% de uso promedio de CPU. Así se ve un ciclo de agente real. El sandbox está abierto, el modelo está pensando, no se está ejecutando nada.

En ese segundo escenario Vercel pasa del cuarto al tercer lugar entre los más baratos, y su línea de CPU cae de 3,20 a 2,13 dólares mientras la de todos los demás escala de forma lineal. La línea de CPU activa de Cloudflare baja a 1,20 dólares. Ese es el argumento completo a favor de la facturación por CPU activa, y vale aproximadamente el doble en esta carga de trabajo.

Las plataformas que pierden el escenario B pueden recuperarlo si la orquestación suspende entre turnos en vez de mantener la caja abierta. Con la misma carga y 30 segundos despierto por ejecución, la cifra de E2B incluye unos 17 segundos de sobrecarga de pausa y reanudación para un sandbox de 4 GiB. Esa sobrecarga es la variable decisiva: pausar solo resulta económico cuando el intervalo entre turnos es bastante mayor que la pausa misma.

El detector de inactividad de Fly es específico sobre qué cuenta como actividad: una petición HTTP o de API en curso, salida hacia la consola de una sesión, una conexión TCP abierta o una tarea activa (sprites.dev). Un agente que mantiene una conexión abierta mientras espera es un agente al que se le está facturando. Redirigir la salida a un archivo no cuenta, y esa es una palanca real.

Persistencia del sistema de archivos entre turnos

Acá es donde más divergen las plataformas, y donde la elección equivocada aparece como un node_modules reconstruido en cada turno. Tres detalles que conviene interiorizar:

  • El comportamiento por defecto de E2B destruye el trabajo: onTimeout es kill salvo que se configure lifecycle: { onTimeout: 'pause' } al momento de la creación. El estado destruido es terminal, y la documentación no describe ninguna señal de apagado previa a la terminación. Hay que tratar el trabajo no guardado como perdido.
  • El disco de Cloudflare es efímero al dormir: la documentación de Containers señala sin rodeos que una instancia dormida reinicia con un disco nuevo desde su imagen. Respaldar y restaurar hacia R2 funciona hoy, mientras que la instantánea automática de disco persistAcrossSessions anunciada en la disponibilidad general aún estaba desplegándose al momento de escribir.
  • Daytona separa la persistencia por clase de sandbox: los sandboxes de contenedor preservan el sistema de archivos entre detención y arranque, pero no admiten pausa, así que la memoria se limpia cada vez. Los sandboxes de máquina virtual Linux admiten ambas. Los sandboxes con GPU son efímeros y se eliminan al detenerse, por lo que los resultados hay que escribirlos en un volumen.

¿Basta con bloquear la salida a internet?

Todas las plataformas de esta comparación pueden ya correr un sandbox sin acceso a internet. Las diferencias están en la precedencia, la granularidad y si la política puede cambiar sin reiniciar.

La trampa de la precedencia. E2B y Vercel resuelven los conflictos en direcciones opuestas. En E2B, las reglas de permiso tienen precedencia sobre las de bloqueo: una dirección IP que está en ambas listas queda permitida. En Vercel Sandbox, los rangos bloqueados anulan a los permitidos. Una política portada de una plataforma a la otra sin reescribirla no significa lo mismo.

La trampa del modo de falla. E2B documenta que las conexiones TCP bloqueadas pueden parecer exitosas desde dentro del sandbox. El cortafuegos acepta la conexión antes de decidir si el destino está permitido, así que se abre un socket y no llega ningún paquete. Hay que verificar la salida con una respuesta de nivel de aplicación, un código HTTP o un saludo TLS, no con un connect() exitoso. Cualquier batería de pruebas que afirme que "la red está bloqueada" comprobando que hubo error de conexión va a pasar contra un sandbox sin bloquear.

La inyección de credenciales es el diferenciador real. Bloquear la salida es lo mínimo. Permitir que un sandbox haga una llamada autenticada sin sostener jamás la credencial, no lo es.

Cloudflare corre los manejadores de salida en el entorno de ejecución de Workers, fuera del sandbox, con acceso a los enlaces de Workers. El sandbox emite una petición común, el manejador adjunta el secreto, y ctx.containerId acota las credenciales por instancia (documentación). Vercel intermedia las credenciales en la salida con coincidencias acotadas por ruta, método, cadena de consulta o cabeceras, y declara que el cortafuegos corre en el anfitrión, fuera de la microVM, donde el código del sandbox no puede desactivarlo (Vercel). E2B ofrece en beta pública transformaciones de petición por host que inyectan cabeceras en el proxy de salida, incluidos tokens de identidad de carga de trabajo que el sandbox nunca ve. Runloop ofrece una pasarela de credenciales con inyección de tokens opacos.

Para agentes que procesan entradas no confiables, este diseño importa más que el arranque en frío. Un agente con inyección de instrucciones maliciosas que tiene un token de GitHub en su entorno es un incidente distinto de uno que solo puede llegar a GitHub a través de un proxy que sostiene el token.

¿Cómo elegir?

  • Elegir Vercel Sandbox si el agente espera al modelo más de lo que computa, y se busca el arranque en frío en ráfaga más barato medido en este grupo. La facturación por CPU activa vale aproximadamente el doble en ciclos con mucho reposo, el cortafuegos de salida con intermediación de credenciales está disponible en todos los planes, y la mediana de 0,67 segundos con percentil 99 de 1,12 segundos fue la distribución más estrecha de la corrida de agosto.
  • Elegir E2B si se necesita aislamiento de kernel por sesión para código adversario, persistencia del estado de memoria entre turnos, o una vía de autoalojamiento. Hay que configurar onTimeout: 'pause' desde el primer día, y presupuestar el piso de 150 dólares mensuales del plan Pro apenas se superen los 20 sandboxes concurrentes o las sesiones de una hora.
  • Elegir Daytona si la persistencia es el producto y se puede absorber la variabilidad de capacidad. El ciclo de vida de detener, archivar, pausar y bifurcar es el más desarrollado de la categoría, bifurcar una máquina virtual viva con la memoria intacta no tiene equivalente limpio en otra parte, y la tarifa de cómputo iguala a la de E2B sin piso de suscripción.