Perplexity's SPACE Runs Secure Long-Running Agents 5x Faster

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.

Three layers, each doing one job well

At a high level, SPACE is organized into three layers: the control plane (the brain of the system, deciding what should exist and where), node-local services (the local machinery required to execute the control plane's plan), and the sandbox itself (the isolated execution environment).

The security model is layered by design:

1. Control Plane -- The control plane is stateless by design, with all durable information offloaded to a shared database. Operations are idempotent, so the control plane can recover automatically after any crash, restart, or partial failure.
2. Node-level Services -- Safety gates guard what a sandbox can reach: the credential manager governs credential injection under per-service authorization, and the network gateway enforces each sandbox's egress policy.
3. In-sandbox (Firecracker microVM) -- The sandbox itself is a virtual machine with its own guest kernel, running the user's workload behind a hardware isolation boundary. Because each sandbox has its own kernel, a compromised workload cannot fall back on a shared host kernel as a single point of failure.

The space daemon running inside each VM is the only sanctioned communication channel between the guest and the platform. The space daemon does not talk to clients directly but rather communicates with the host over a private in-VM channel. This keeps all guest interaction on a controlled path and reserves the sandbox's own network purely for the workload's outbound traffic.

Credentials stay outside the sandbox, always

This is where SPACE diverges most sharply from typical approaches. Credentials never live where an agent can steal them. The credential store sits outside the sandbox boundary and is responsible for the credential lifecycle. When needed, credentials are injected at the network layer or auto-filled by a browser agent, instead of entering the sandbox directly.

With SPACE, credentials never pass into the sandbox. Instead, they're passed in from outside the sandbox only at the precise moment they're needed. When an agent needs temporary access to connect to a Google Account, SPACE can handle the sign-in flow without exposing credentials inside the sandbox. A compromised agent session simply has no path to your API keys.

For enterprise deployments, SPACE supports BYOK (Bring Your Own Key) to protect externally stored data. Encryption keys come from the customer's key management service and never enter the sandbox. If the enterprise revokes the key, their data becomes unreadable.

How snapshots make long-running sessions practical

SPACE supports the full sandbox lifecycle as an explicit state machine, which is what makes operations like create, pause, resume, suspend, and restore possible. The mechanism underneath all of this is snapshotting.

A scheduler ticks on regular intervals and captures two types of snapshots: disk snapshots (point-in-time copies of the filesystem) and full snapshots (checkpoints of the entire paused VM). Disk snapshots are captured frequently, while full checkpoints are less frequent. The result is a built-in time machine: Anyone can walk away mid-task, come back a week later, and the agent picks up exactly where it paused.

Snapshots also enable session forking -- branching a running agent into two parallel paths from the same state, which is useful for exploring multiple strategies without restarting from scratch.

The performance numbers

The efficiency gains are where SPACE makes its most concrete case. Median create latency fell from 185 milliseconds to 60 milliseconds (3.1x improvement), and the 90th-percentile latency fell from 447 milliseconds to 89 milliseconds (5.0x improvement).

The key to this is btrfs (B-tree filesystem), used as the on-node filesystem for sandbox storage. Btrfs combines a copy-on-write filesystem with integrated logical volume management. Reflink copies are fast since you share the underlying extents, so only metadata needs to be copied. Snapshots are atomic and fast, since you just make a new root.

Instead of creating a sandbox from scratch each time, SPACE keeps a warm pool of pods that already have common templates materialized on disk, and satisfies a request by binding it to a pod whose template already matches. Giving that sandbox its own writable root filesystem is then a copy-on-write clone rather than a full copy.

Where this fits in the broader landscape

This is precisely why Manus, Perplexity, and others choose microVMs over containers -- different threat models lead to different acceptable trade-offs in isolation cost. The industry has been converging on this approach: standard multi-tenant containers can't safely contain AI agents executing arbitrary code. When an agent can write its own scripts, install packages, and manipulate file descriptors, a shared kernel is a liability.

Snapshot and restore capabilities are becoming the differentiator for long-running agentic workloads. Most existing platforms -- E2B, Modal, Northflank -- solve for fast ephemeral execution. SPACE is explicitly designed for the opposite end of the spectrum: sessions that run for hours or days, need to pause and resume, and must keep credentials safe throughout.

What makes SPACE's release significant beyond Perplexity's own product is the technical writeup itself. SPACE provides the substrate on which long-running, stateful agents can securely tackle work of arbitrary complexity or duration, without sacrificing either performance or security. Perplexity has signaled intent to expand SPACE beyond Computer -- from Linux microVMs to Windows guests to a user's own local machine -- which would make it a general-purpose agentic runtime rather than an internal infrastructure component. An early test on NVIDIA Vera CPU showed actual Computer-style workflows ran roughly 1.5x faster than the current production reference, and started concurrent sandboxes up to 1.9x faster.

For teams building their own agent infrastructure, the architectural patterns here -- session/sandbox separation, credential injection at the network layer, btrfs-backed copy-on-write clones, and a stateless idempotent control plane -- are worth studying regardless of whether SPACE ever becomes externally available.