# Perplexity SPACE Explained: Open-Source Agent Sandboxes, API and E2B Compatibility

Perplexity has released the execution platform behind Computer, giving developers more control over agent workspaces and more infrastructure to operate.

By Paras Madan | 2026-10-16


Perplexity open-sourced SPACE on October 15, 2026, releasing the sandbox platform behind Computer. Developers can use it to run agent-generated code in isolated virtual machines, preserve work between sessions and control the environment around an agent. The useful question is what that infrastructure lets a product safely hand over.

In its [launch announcement](https://www.perplexity.ai/hub/blog/open-sourcing-space), Perplexity says SPACE has powered all Computer sessions since July and handles millions of sandbox creations daily. It reports sandbox creation three to five times faster than its previous provider on the same production traffic. Those are company-reported results, not an independent performance comparison.

## What is Perplexity SPACE?

SPACE stands for Sandboxed Platform for Agentic Code Execution. The [Apache 2.0 repository](https://github.com/perplexityai/SPACE) provides a platform built around Firecracker microVMs: small virtual machines that give each workspace its own operating system and writable filesystem.

An application uses an HTTP API to create a Linux environment from a template, execute commands and collect their output. Multiple commands can share the same sandbox. SPACE is implemented in Rust, but an application does not need to embed a Rust library to use it.

That separation is useful for a spreadsheet agent, for example. The agent can install tools, inspect files and run calculations in a dedicated workspace. The product still has to decide which files belong there, what external services are allowed and which outputs should reach the user.

## How the SPACE API handles long-running work

SPACE separates a sandbox's lifetime from a command's output connection. A disconnected client does not have to mean throwing away the entire workspace. Lifecycle requests are asynchronous, so an accepted API request also does not mean an environment is ready to execute code.

The [architecture guide](https://space.docs.perplexity.ai/guide/architecture.html) makes another important distinction: **pause and suspend preserve state differently**. Pause keeps memory resident on the worker. Suspend saves the virtual machine's memory, runtime state and root filesystem, then releases active VM resources.

For an agent waiting on a human decision, that distinction affects resource consumption and recovery planning. A resident pause is not a durable backup. The documentation also warns that an acknowledged file write alone does not guarantee survival through a crash or host failure.

A team evaluating SPACE should test the whole interruption path: stop a task, disconnect its client, restore its environment and inspect the resulting files. A successful command in a clean demo does not answer those operational questions.

## Is SPACE compatible with E2B?

SPACE includes an [E2B Compatibility Wrapper](https://space.docs.perplexity.ai/guide/ecw.html) for existing clients. Its documented test baseline covers Python packages `e2b==2.21.1` and `e2b-code-interpreter==2.6.2`. Other versions and the JavaScript SDK are not covered by the repository's current compatibility tests.

Supported flows include creating, inspecting, deleting and reconnecting to sandboxes, alongside tested command and filesystem operations. There are limits: sandbox-create options such as `mcp`, `volumeMounts` and `iam` are rejected.

Lifecycle terminology also changes at the wrapper boundary. An E2B-style pause maps to SPACE's persistent suspend, rather than its resident-memory pause. That is worth checking before carrying assumptions from an existing integration into a migration.

For a new integration, the documentation recommends the native SPACE API. Compatibility is useful for evaluating a move, but each application's actual calls still need testing.

## What does running SPACE require?

The [local installation guide](https://space.docs.perplexity.ai/guide/installation.html) targets an apt-based x86-64 Linux host with KVM and the required host devices. It uses a local Kind Kubernetes cluster and privileged containers. This is not a direct macOS installation guide.

The development setup also includes development credentials and signing keys. Its instructions say to keep it private and avoid production credentials. Teams should not mistake a working local cluster for a deployment ready to handle customer data.

Apache 2.0 makes the source available without buying a software licence. Compute, storage, maintenance and security operations still have costs. **Self-hosting moves those responsibilities into the team running it.** For a small product, that operational burden may outweigh the benefits of controlling the runtime.

## What SPACE changes for agent builders

The release gives teams a concrete implementation to inspect when deciding how much execution infrastructure to own. Perplexity describes isolation, recovery, network controls and credential handling as parts of the system. Those design claims are useful starting points for evaluation, not proof that a particular deployment is secure.

The strongest reason to evaluate SPACE is a product requirement that needs control over persistent agent workspaces. The next useful test is whether a team can recover a real task after interruption while keeping its permissions intact. That is where an agent execution platform starts earning its place in a product.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn launches and engineering updates into clear stories that developers and founders want to read and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).