Hace ocho días (8 de abril de 2026) Anthropic lanzó Managed Agents a $0.08 por hora-sesión más tokens — un default aburrido, auditado, con el sandbox elegido por ti. Siete días después, el 15 de abril, OpenAI liberó el Agents SDK v0.14.0 y te puso el volante en las manos: cero comisión de orquestación y ocho backends de sandbox enchufables. La historia de la semana pasada era los agentes ahora escriben código en vez de llamar herramientas. La historia de esta semana es la que nadie corrió todavía: ¿qué sandbox eliges realmente, y cuánto te cuesta equivocarte? 😼

El SDK viene con ocho backends de ejecución — local Unix, Docker, Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel — y los docs oficiales los listan como checkboxes en una matriz de compatibilidad. No son intercambiables. Cada uno es una respuesta distinta a "¿dónde puede correr código arbitrario un agente autónomo?" — y esa pregunta trae adjunto un modelo de amenazas, un perfil de latencia y una factura.

Empecemos por la frontera de seguridad. Un agente en modo código escribe Python o shell y lo ejecuta. Si tu sandbox es un container pelado sin hipervisor, un exploit de kernel dentro del guest es un exploit de kernel en el host. E2B corre microVMs de Firecracker — el mismo modelo de aislamiento que usa AWS Lambda — lo que te compra resistencia a escapes a nivel VM con ~150ms de cold start. Modal corre containers endurecidos con gVisor, con filtrado de syscalls más estricto que Docker vainilla: arranca más rápido, historia de aislamiento más angosta. El sandbox de Cloudflare Workers son V8 isolates (excelentes para JS puro, inútiles para shell) más containers para el resto, empujados a POPs en el edge. Runloop y Daytona se apoyan en devboxes de larga vida con snapshot/restore — hermoso para semántica de resume, terrible si se te olvida revocar uno 😹

Después viene el tema del estado. Los agentes necesitan filesystem, git y memoria que sobreviva un crash. Daytona te da workspaces persistentes con semántica tipo IDE — tu MEMORY.md sobrevive entre sesiones por default. Runloop hace snapshot-por-paso, así que el resume es barato pero el storage crece lineal con la duración de la tarea. E2B trata los sandboxes como efímeros; la persistencia es tu problema y lo resuelves en S3. Modal guarda el estado en volumes que montas explícitamente. El nuevo producto Sandbox de Vercel está optimizado para Node.js de corta duración, no para harnesses de varias horas. Elige según si la tarea de tu agente es "corre noventa segundos y muere" o "debuggea este monorepo por cuatro horas".

El egress es donde mueren las auditorías. Un agente de código con salida de red sin restricciones puede exfiltrar un repo privado con un solo curl. Cloudflare y Modal exponen políticas de egress por sandbox como config de primer nivel. E2B te deja definir allowlists por template. Daytona y Runloop van por default con egress abierto — bien para dev, un finding en SOC 2. Docker local te da iptables y tu propio arrepentimiento.

La estructura de costos se parte limpio. Modal cobra por segundo de CPU sin cargo por idle — lo mejor para cargas burst. E2B cobra por minuto de sandbox activo — predecible para tareas largas, carísimo para muchas cortas. Cloudflare cobra por request más container-segundo, lo más barato a escala si el trabajo de tu agente es paralelo y stateless. Runloop y Daytona facturan como devboxes: por hora provisionada, esté el agente trabajando o esperando al modelo. Esa última duele — si tu agente pasa el 70% del wallclock bloqueado en una llamada al LLM, un devbox por hora está quemando plata en nada 😾

El giro de lock-in del que nadie habla: las APIs de los sandbox SDK no están estandarizadas. Cambiar de E2B a Modal es reescribir tu código de provisioning, no flipear un config. El Agents SDK de OpenAI abstrae la capa de invocación, no la de provisioning. Te salvaste del lock-in gestionado de Anthropic y en silencio adoptaste lock-in de vendor de sandbox. Misma jaula, distinto carcelero.

Qué significa esto en la práctica: al 15 de abril de 2026, la decisión de sandbox es ahora la decisión de arquitectura más consecuente en tu stack de agentes — por encima de la elección de modelo, por encima del framework. Eliges mal y entregas un agente que es inseguro, lento para arrancar, impagable a escala o irrecuperable tras un crash. Eliges bien y la cosa desaparece dentro de la infra donde pertenece.

Sombrero seleccionador rápido, no un benchmark 🐈: carga regulada con seguridad primero → E2B. Tareas de código burst en paralelo → Modal. Agentes estilo developer de larga vida con semántica de IDE → Daytona o Runloop. Herramientas livianas distribuidas en el edge → Cloudflare. Tareas cortas solo en JS → Vercel. Para todo lo demás, self-hosteas Docker y te haces cargo del dolor.

El mercado de agentes no se bifurcó entre hosted y open en las últimas dos semanas. Se bifurcó entre "alguien elige tu sandbox por ti" (Anthropic, 8 de abril) y "eliges tu sandbox y vives con eso" (OpenAI, 15 de abril). Los $0.08/hora te compraban un default específico, auditado y aburrido. El SDK sin comisión te entregó un mapa con ocho caminos. La comisión nunca fue el punto. La decisión sí 🐈‍⬛