Perplexity's SPACE Runs Secure Long-Running Agents 5x Faster
Perplexity's new SPACE platform runs agent sessions in disposable Firecracker microVMs with rolling snapshots, cutting sandbox creation latency 3-5x
- Perplexity launched SPACE, a sandbox platform built for long-running agent sessions, now powering 100% of Perplexity Computer traffic.
- Each task runs in a disposable Firecracker microVM destroyed after completion; sessions persist via rolling snapshots that capture live memory and files.
- Sandbox creation latency dropped from 185ms (median) to 60ms, and P90 fell from 447ms to 89ms -- a 3-5x improvement over the previous solution.
- Credentials never enter the sandbox; they are injected at the network layer at the exact moment needed, eliminating credential theft by compromised agents.
- SPACE supports pause/resume, session forking, rollback, and BYOK encryption -- features absent from most existing sandbox platforms focused on short-lived execution.
- Perplexity plans to expand SPACE to Windows guests and local machines, potentially making it a general-purpose agentic runtime beyond their own products.
Perplexity just pulled back the curtain on SPACE (Sandboxed Platform for Agentic Code Execution), the infrastructure layer powering Perplexity Computer. Built in 10 weeks, it's already handling 100% of Computer's production traffic. The announcement is notable not just for what SPACE does, but for what it reveals about the hard infrastructure problems that nobody talks about when shipping long-running agents.
The problem with existing sandboxes
Traditional container-based sandbox approaches aren't designed for agentic tasks. They typically assume short-lived, stateless jobs and treat the kernel as a single point of failure. That works fine for running a quick script, but agents are a different beast entirely.
Agent sessions are long-lived and stateful: an agent accumulates hours of context, a working filesystem, and running processes that can't simply be thrown away and reconstructed from scratch. Moreover, the workload inside should be untrusted by default, necessitating stronger security measures.
The tension at the core of sandbox engineering comes down to three competing goals that usually trade off against each other:
- Granting broader access lets an agent accomplish more but exposes more of the system to a workload you don't trust.
- Sharing more between sandboxes makes creation faster but widens the attack surface.
- Snapshotting more frequently improves recovery and enables features like rollback but requires time and storage space.
SPACE's claim is that it doesn't force you to pick two out of three.
Session vs. sandbox: the key architectural insight
The most important design decision in SPACE is conceptual: separating the session from the sandbox running it. SPACE spins up ephemeral sandboxes which only live as long as they're needed for running code, interacting with files, or other tasks. When the task finishes, the sandbox, and everything inside it, is destroyed.
For long-horizon work that needs to survive restarts, SPACE wraps each sandbox in a session that can be paused, resumed, or branched into multiple sandboxes. SPACE's rolling snapshot technology allows context to travel with the work, even though no individual sandbox does. Think of it as the difference between a browser tab and your browsing history -- the tab can close, but the state lives on.