Puntos clave
- Perplexity SPACE es un sandbox de ejecución de código para agentes de IA, liberado como código abierto bajo licencia Apache 2.0 por Ethan Walkrman y el equipo de Perplexity.
- Está construido sobre microVMs de Firecracker y se usa en producción para gestionar millones de sesiones diarias del producto de agentes Computer.
- Incluye un wrapper compatible con la API de E2B, lo que facilita migrar desde ese proveedor comercial sin reescribir la integración.
- Todavía no hay build público, descarga ni página oficial; por ahora solo se ha mostrado en un vídeo de presentación breve.
Datos rápidos
| Tipo | Sandbox de ejecución de código para agentes de IA |
|---|---|
| Dispositivos | Servidores y entornos cloud; se gestiona desde tu infraestructura |
| Precio | Código abierto (Apache 2.0); coste de infraestructura aparte |
| Idiomas | Documentación y código en inglés; consulta el sitio oficial |
| Lo destacado | MicroVMs Firecracker, API compatible con E2B, sin secretos dentro de la VM |
| Dificultad | Alta: requiere conocimientos de infraestructura y contenedores |
| Categoría | Herramientas dev |
| Creador | Ethan Walkrman |
| Popularidad | 🔥 25,8K Popularidad |
| Última actualización |
Qué es Perplexity SPACE y por qué se ha vuelto tendencia
Perplexity SPACE es el sandbox de ejecución de código que Perplexity utiliza internamente para su producto de agentes Computer. Un sandbox es un entorno aislado donde un agente de IA puede ejecutar comandos, instalar paquetes y correr código sin tocar la máquina anfitriona. SPACE es, por tanto, la capa de seguridad que separa las acciones del agente del sistema real. La compañía lo ha liberado como código abierto bajo licencia Apache 2.0, y afirma que el mismo sistema gestiona millones de sesiones diarias en producción.
El anuncio lo firmó Ethan Walkrman y llegó el 16 de octubre de 2026. La discusión se disparó por dos motivos: la comparativa de costes frente a proveedores comerciales como E2B y la inclusión de un wrapper de API compatible con E2B, que permite migrar sin reescribir la integración. Además, Perplexity señala que abandonó un proveedor comercial de sandboxes en julio y que, desde entonces, vio creaciones de sandbox entre tres y cinco veces más rápidas. No se ha confirmado públicamente qué proveedor era, aunque ambas soluciones comparten Rust y microVMs de Firecracker.
SPACE está pensado para equipos que construyen agentes de IA capaces de ejecutar código no confiable a escala: agentes de programación, de análisis de datos o cualquier flujo que levante muchos entornos efímeros. La idea central de su arquitectura es tratar el sandbox como si ya estuviera comprometido, es decir, asumir que el código que corre dentro puede ser hostil y diseñar el aislamiento en consecuencia. Esa premisa explica tanto su enfoque de seguridad como su modelo de gestión de credenciales.
- Aislamiento con microVMs
SPACE se apoya en microVMs de Firecracker, la misma tecnología que usan otros sandboxes modernos. Cada sesión corre en su propia máquina virtual ligera, lo que limita el impacto si el código ejecutado intenta escapar.
- Credenciales fuera de la VM
En lugar de inyectar secretos como variables de entorno dentro del sandbox, SPACE gestiona las claves de API en el lado del host. Así, el código del agente no puede leerlas directamente.
- Compatibilidad con E2B
El wrapper de API compatible con E2B es la vía de migración más directa para equipos que ya usan ese proveedor. Puedes cambiar el backend sin rehacer toda la lógica de tu agente.
Cómo funciona por dentro: microVMs, costes y seguridad
Arquitectónicamente, SPACE se construye sobre Rust y microVMs de Firecracker. Las microVMs arrancan mucho más rápido que una máquina virtual tradicional y ofrecen un aislamiento más fuerte que un contenedor convencional, algo clave cuando ejecutas código generado por un modelo. Perplexity afirma que, tras dejar su proveedor comercial en julio, las creaciones de sandbox se aceleraron entre tres y cinco veces. Ese dato, junto con el uso de Firecracker, es lo que llevó a muchos a señalar a E2B como el proveedor sustituido, aunque la compañía no lo ha confirmado.
El desglose de costes fue el punto que más discusión generó. Para una configuración equivalente de 2 vCPU y 2 GB, E2B factura por segundo de reloj, aproximadamente 0,13 dólares por hora, y pagas mientras el sandbox está inactivo esperando tokens del modelo. La API de agentes de Perplexity cobra una tarifa plana de 0,03 dólares por sesión activa de 20 minutos, unos 0,09 dólares por hora. Y SPACE autoalojado en nubes como Akamai, CoreWeave o Crusoe se sitúa en torno a 0,03–0,05 dólares por hora, entre un 60 % y un 75 % más barato bajo carga completa. Verifica estas cifras en el sitio oficial, porque pueden cambiar.
En seguridad, Perplexity menciona que nueve modelos frontera se sometieron a unas 118 pruebas de escape sin lograr romper el aislamiento del host. Es una cifra que conviene tratar con cautela: no se han publicado detalles del protocolo ni del conjunto exacto de pruebas. Lo que sí está documentado es el enfoque de credenciales: las claves de API se gestionan en el host y no dentro de la VM, de modo que un agente comprometido no puede exfiltrarlas leyendo variables de entorno. Esa decisión de diseño es tan importante como el aislamiento de la propia máquina.
- Arranque rápido
Las microVMs de Firecracker reducen el tiempo de creación de cada entorno, algo crítico cuando un agente levanta decenas de sandboxes por minuto.
- Coste bajo carga
El modelo de precios favorece a quien mantiene los sandboxes ocupados. Si tu agente pasa mucho tiempo esperando al modelo, la ventaja frente a un cobro por segundo de reloj se reduce.
- Nubes asociadas
Akamai, CoreWeave y Crusoe ofrecerán SPACE en sus plataformas, una opción útil para equipos que quieren el stack sin montar su propio hosting.
Cómo empezar a usar SPACE y qué necesitas
Antes de nada, ten claro el estado actual: no hay build público, descarga ni página oficial publicada. Hasta ahora, el creador solo lo ha mostrado en un vídeo de presentación breve. Eso significa que no puedes instalarlo ni probarlo hoy mismo. Lo que sí puedes hacer es preparar tu entorno y seguir las indicaciones que Perplexity publique en su sitio oficial cuando el repositorio esté disponible. Cualquier enlace o instrucción que veas fuera de canales oficiales debe tratarse con escepticismo.
Cuando el código esté accesible, el flujo típico será el de un sandbox autoalojado. Necesitarás una máquina anfitriona con soporte de virtualización, ya que Firecracker requiere KVM en Linux. También necesitarás Rust para compilar el proyecto y una nube o servidor propio donde desplegarlo. Si vienes de E2B, el wrapper compatible te permitirá apuntar tu cliente existente al nuevo endpoint con cambios mínimos. Si empiezas de cero, tendrás que integrar la API de SPACE en tu agente y definir cómo se aprovisionan y destruyen las sesiones.
El modelo de uso encaja con agentes que ejecutan tareas cortas y muchas veces: analizar un CSV, instalar una dependencia, correr un test o generar un gráfico. En esos casos, el coste por sesión activa y la velocidad de arranque marcan la diferencia. En cambio, si tu carga es muy irregular o pasas mucho tiempo esperando respuestas del modelo, conviene calcular bien el ahorro antes de migrar. La recomendación práctica es medir tu patrón real de uso y compararlo con las tarifas publicadas.
- Requisitos de host
Firecracker necesita virtualización por hardware, normalmente KVM en Linux. Sin eso, no podrás ejecutar microVMs en tu propio servidor.
- Migración desde E2B
El wrapper compatible es la ruta más sencilla si ya tienes una integración funcionando. Prueba primero en un entorno de staging antes de mover producción.
- Gestión de secretos
Aprovecha que las credenciales viven en el host. Revisa tu código para no inyectar claves dentro del sandbox por costumbre.
SPACE frente a E2B y otros sandboxes: límites y para quién es
La comparación más directa es con E2B, porque ambos usan Rust y microVMs de Firecracker y porque SPACE incluye un wrapper compatible con su API. La diferencia principal está en el modelo de precios y en el control: E2B es un servicio gestionado que factura por segundo de reloj, mientras que SPACE es código abierto que puedes autoalojar en Akamai, CoreWeave o Crusoe. Si tu equipo tiene capacidad de infraestructura y una carga alta y sostenida, el ahorro puede ser notable. Si prefieres no operar nada, un servicio gestionado sigue siendo más cómodo.
Frente a soluciones basadas solo en contenedores, SPACE apuesta por microVMs, lo que ofrece un aislamiento más fuerte a costa de algo más de complejidad operativa. Frente a plataformas propietarias de sandbox, su ventaja es la licencia Apache 2.0: puedes auditar el código, adaptarlo y desplegarlo donde quieras. La contrapartida es que asumes tú la operación, el escalado y la seguridad del host. No hay una opción universalmente mejor; depende de cuánto control quieras y de cuánto tráfico manejes.
¿Para quién es entonces? Principalmente para equipos que construyen agentes de IA que ejecutan código no confiable a escala: agentes de programación, de análisis de datos o pipelines que crean y destruyen entornos constantemente. Si estás en esa situación y ya usas E2B, eres el candidato ideal para evaluar la migración. Si solo haces pruebas puntuales o no quieres gestionar infraestructura, probablemente te convenga esperar a que haya más documentación o a que alguna nube ofrezca SPACE como servicio gestionado.
- Control frente a comodidad
Autoalojar SPACE te da control total y potencial de ahorro, pero te obliga a operar la infraestructura. Un servicio gestionado te quita ese trabajo a cambio de un precio mayor.
- Aislamiento más fuerte
Las microVMs ofrecen una separación más robusta que los contenedores tradicionales, algo relevante cuando el código lo genera un modelo y no un humano.
- Datos aún sin confirmar
Las cifras de rendimiento y de seguridad provienen del anuncio, no de una auditoría independiente. Trátalas como promesas iniciales hasta que haya más evidencia pública.
Guía paso a paso
Confirma el estado de publicación
Antes de nada, comprueba si Perplexity ya ha publicado el repositorio y la documentación en su sitio oficial. Hasta la fecha del anuncio solo existía un vídeo de presentación, sin build ni descarga pública. No instales nada que provenga de fuentes no oficiales.
Prepara tu entorno de host
Necesitarás un servidor Linux con virtualización por hardware habilitada, ya que Firecracker depende de KVM. Instala también Rust y las herramientas de compilación habituales. Si vas a desplegar en la nube, revisa que el proveedor permita virtualización anidada.
Compila y despliega SPACE
Cuando el código esté disponible, clona el repositorio oficial y sigue las instrucciones de compilación. Despliega primero en un entorno de pruebas para validar que las microVMs arrancan correctamente. No lo lleves a producción hasta haber probado el ciclo completo de creación y destrucción de sesiones.
Integra la API en tu agente
Conecta tu agente al endpoint de SPACE usando el wrapper compatible con E2B si vienes de ese proveedor. Define cómo se solicitan las sesiones, cuánto duran y qué ocurre cuando terminan. Revisa que ninguna credencial se inyecte dentro de la VM.
Mide, compara y ajusta
Registra el tiempo de arranque, el coste por sesión y la tasa de errores durante unas semanas. Compara esos números con lo que pagabas antes en tu proveedor comercial. Ajusta el tamaño de las microVMs y la política de reutilización según lo que veas.
Preguntas frecuentes
¿Cuánto cuesta Perplexity SPACE?
El código es de código abierto bajo licencia Apache 2.0, así que no pagas por la licencia en sí. Lo que sí pagas es la infraestructura donde lo ejecutes. Según el anuncio, autoalojado en nubes como Akamai, CoreWeave o Crusoe costaría entre 0,03 y 0,05 dólares por hora para una configuración equivalente de 2 vCPU y 2 GB, frente a unos 0,13 dólares por hora de E2B. Confirma las cifras actuales en el sitio oficial.
¿Puedo probarlo ya o descargarlo?
Todavía no. En el momento del anuncio no se había publicado ningún build, descarga ni página oficial, solo un vídeo de presentación breve. Eso significa que no puedes instalarlo ni ejecutarlo hoy. Lo que puedes hacer mientras tanto es preparar tu entorno Linux con KVM y Rust, y seguir las novedades en el sitio oficial de Perplexity para saber cuándo esté disponible.
¿En qué se diferencia de E2B?
Ambos usan Rust y microVMs de Firecracker, y SPACE incluye un wrapper de API compatible con E2B, lo que facilita migrar. La diferencia clave está en el modelo: E2B es un servicio gestionado que factura por segundo de reloj, mientras que SPACE es código abierto que puedes autoalojar y controlar por completo. Si tienes equipo de infraestructura y carga alta, SPACE puede salir más barato; si prefieres no operar nada, E2B sigue siendo más cómodo.
¿Es seguro ejecutar código de un agente dentro de SPACE?
Perplexity afirma que nueve modelos frontera se sometieron a unas 118 pruebas de escape sin romper el aislamiento del host, aunque no se han publicado los detalles del protocolo. Además, las claves de API se gestionan en el host y no dentro de la VM, lo que reduce el riesgo de exfiltración. Aun así, ningún sandbox es infalible: trata estos datos como promesas iniciales y aplica tus propias capas de seguridad.
¿Necesito saber Rust o Firecracker para usarlo?
Para consumir la API desde tu agente, no necesitas conocer Rust ni Firecracker: basta con integrar el endpoint y gestionar las sesiones. Otra cosa es autoalojarlo, porque ahí sí tendrás que compilar el proyecto en Rust y asegurarte de que tu host soporta virtualización por hardware para las microVMs. Si no quieres esa complejidad, espera a que alguna nube lo ofrezca como servicio gestionado.
