Sessions Live, Sandboxes Die: How Perplexity Cut Agent Sandbox Creation From 185ms to 60ms

Perplexity replaced the sandbox layer behind Perplexity Computer and median sandbox creation fell from 185 milliseconds to 60. The 90th percentile fell further, from 447 milliseconds to 89 — a 5x cut at the tail against 3.1x at the median. Over launch week the new platform, SPACE, handled millions of sandbox creations and tens of millions of reconnects, and today 100% of Computer sessions run on it.

The speedup is real, but the number is not the story. The story is the architectural split that produced it: SPACE made the session the durable unit and the sandbox disposable. A session can be paused indefinitely, resumed on any node, or branched into multiple sandboxes; the microVM running it is destroyed the moment a task finishes. Everything else in the design — the snapshot tiers, the copy-on-write filesystem, the warm template pools — is downstream of that one decision.

Agent sessions are not jobs​

Most sandbox infrastructure was built for short-lived, stateless work: run a snippet, return the output, tear everything down. Agent sessions break every assumption in that model. An agent accumulates hours of context, a working filesystem, and running processes that cannot be thrown away and reconstructed from scratch. A session blocked on human input might sit idle for days and then need to resume exactly where it left off. And the workload inside must be treated as hostile by default, because the agent writing the code is itself the untrusted party.

Perplexity's engineering post frames this as a three-way tension between security, functionality, and efficiency, and the examples are worth quoting because they generalize. Granting broader access lets an agent accomplish more but exposes more of the system to a workload you do not trust. Sharing more between sandboxes makes creation faster but widens the attack surface. Snapshotting more frequently improves recovery and enables rollback, but costs time and storage. Every sandbox platform picks its point in this triangle. SPACE's pick is what is interesting: refuse to compromise on any vertex, and push the cost into mechanism design instead.

That framing matters for self-hosters because the triangle does not go away on hardware you own. It gets sharper — there is no cloud provider absorbing the snapshot storage bill or the idle-memory cost.

The split: a durable session over disposable sandboxes​

The sandbox itself is a virtual machine with its own guest kernel — Firecracker-class microVM isolation, named as Firecracker in launch coverage — paired with an in-guest daemon that brokers all host interaction over a private channel, keeping the sandbox's own network purely for workload traffic. Above that substrate, SPACE models the full lifecycle as an explicit state machine: create, pause, resume, suspend, and restore, plus fork-and-branch, rollback, and crash recovery. The state machine is the mechanism that makes "session survives, sandbox doesn't" operational rather than aspirational.

Two snapshot tiers sit underneath it. Disk snapshots — point-in-time copies of the filesystem — are captured frequently. Full snapshots — checkpoints of the entire paused VM, memory and device state included — are captured less often. Retention decays by tier, so recent history is dense and old history is cheap. In-session recovery falls out naturally: roll the filesystem back to undo a destructive command, or resume a crashed sandbox from a recent checkpoint instead of a cold disk.

Suspend and restore are where the session/sandbox split becomes a distributed-systems protocol. Suspending pauses the VM, takes a full snapshot, and uploads the artifacts to object storage — and a database row tracks the snapshot, becoming restorable only once every artifact has landed, so a partially uploaded snapshot can never resume into a corrupt state. Restore is the inverse: any node can pick up the snapshot, download the artifacts, reapply the filesystem delta on top of the template, and resume the VM from its captured state. The sandbox is fungible across the fleet precisely because the session is durable outside of it. Branching is the same primitive pointed sideways: one session fanning out into multiple sandboxes, each an isolated copy of the same state.

Durable sessions raise an obvious objection: if a session lives for months, do its secrets live for months too? SPACE's answer is that longevity applies to state, not to credentials. Secrets never enter the sandbox at all — they are injected at the network layer or auto-filled by a browser agent, resolved from a pluggable vault backend with hierarchical scoping, rate limits, and audit logging. Combined with per-sandbox VMs behind a dual VM-plus-host isolation boundary and a network gateway that forces all egress through policy, a months-long session carries no lingering credential to steal. That is the half of the design most sandbox comparisons skip, and the half that decides whether pause/resume is safe to offer tenants.

Where the milliseconds went: median vs. tail​

Read the headline numbers carefully, because they describe two different victories. Median creation latency fell 185ms to 60ms — 3.1x. The p90 fell 447ms to 89ms — 5.0x. Perplexity reports "3–5x faster throughout the distribution" and "up to 5 times faster," both accurate; compressing that into a flat "5x faster" would credit the median with the tail's achievement.

The mechanisms divide along the same line. The median win comes off the create path itself: instead of materializing a full machine image per sandbox, SPACE keeps a warm pool with common templates already materialized on disk and hands each new sandbox a copy-on-write clone of its template root — a metadata operation, not a copy. The storage layer is btrfs, chosen for exactly three properties: reflink copies that share extents, atomic snapshots that just mint a new root, and delta storage that keeps only what changed. That is the session/sandbox split paying directly: creation stops meaning "boot a machine" and starts meaning "clone a template and bind it to a session."

The tail win is about everything that used to go wrong at scale. Bursts of identical sandbox requests collapse into a single template download instead of N duplicate fetches. Rolling disk snapshots are fast and space-efficient enough to take without pausing the sandbox, so snapshot pressure never stalls the create path. And restore-from-snapshot replaces boot-from-scratch anywhere a warm start is possible — the same "restore, don't boot" mechanism E2B and Modal rely on for millisecond starts. Treat this paragraph as analysis rather than Perplexity's own attribution: the company published end-to-end create-latency distributions, not per-mechanism flame graphs. But the mapping from mechanism to distribution shape — clones move the median, burst-collapsing and pauseless snapshots cut the tail — is the correct way to read any sandbox benchmark, including your own.

The 60ms number needs context​

Sixty milliseconds median is fast, but "fast" is a comparison, and the honest one uses documented figures from the same era:

Two readings fall out. First, SPACE's median beats E2B's typical cold start by roughly 3x and lands in Daytona/Modal territory while carrying full-VM checkpoints the FS-only snapshotters do not offer — that combination, not the raw 60ms, is the actual advance. Second, E2B's model already concedes the core point: billing stops the moment a sandbox pauses, which is the single-lifetime model bending toward session durability without fully arriving there. (Vercel's Sandbox bills on active CPU rather than wall-clock provisioning — a different answer to the same idle-capacity question, worth one line and no more here.)

The axis that matters is lifecycle richness per millisecond, not milliseconds alone. A 60ms sandbox you cannot branch is a faster version of the old thing. A branchable session that restores on any node in the fleet is the new thing.

What this means for bex​

This lands close to home. bex's own sandbox design doc, ADR014, made the same call as its zeroth decision — "sandboxes are sessions, not services" — carving sandboxes out of the declarative App-CR architecture precisely because an interactive, ephemeral session is the opposite of desired-state infrastructure. The compatibility play mirrors the App API strategy: speak E2B's control-plane shapes so existing agent tooling transfers instead of restarting from zero, with wake-on-connect idle hibernation ("sleep = free") as the milestone the mechanism serves.

SPACE validates that bet and sharpens the roadmap in three places. An explicit lifecycle state machine with branch and rollback as first-class transitions, not just pause/resume. Suspend-to-object-storage with an all-artifacts-landed durability rule, so a session can resume on any node in the fleet rather than being pinned to the host that paused it. And credentials-out-of-guest as a precondition for long-lived sessions, not a hardening afterthought.

The honest gap runs the other direction. bex's current sandbox substrate pauses rootfs-only — filesystem state without the memory-and-process checkpoint that makes SPACE's resume exact — and full-VM checkpoint/restore is the bar SPACE just set publicly. Closing it on owned Hetzner hardware, where snapshot storage and idle memory come out of your own capacity planning rather than a cloud bill, is genuinely harder than closing it on someone else's fleet. That is the work, and SPACE is useful mostly as a precise specification of what "done" looks like: median create in the tens of milliseconds, p90 under a hundred, sessions that outlive every sandbox that ever ran them.

Perplexity's post closes by saying SPACE will expand from Linux microVMs to Windows guests and local machines — sandboxing as a unified layer for wherever agents work. Whether or not that expansion lands, the durable-session/disposable-sandbox split is now the design to beat. Every agent sandbox roadmap, self-hosted or not, gets measured against 60ms and a branch button.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.