Perplexity publishes SPACE source code for running AI agents in isolated workspaces
The Apache-licensed platform separates code execution from the application directing it. Getting started requires deploying the sandbox infrastructure, not just connecting an SDK.
Perplexity released SPACE under Apache 2.0, making its agent-code execution platform available for teams to inspect and adapt. SPACE runs workloads in Firecracker microVMs and lets applications manage reusable Linux workspaces independently from the commands running inside them. The practical tradeoff is an explicit support boundary: documentation marks some API fields incubating, and initial setup assumes a local Kind cluster even though the architecture guide describes running without Kubernetes.
01
A sandbox starts from a template and can host multiple commands, so applications need not create a fresh environment for every execution.
02
Clients control the Rust service through HTTP and server-sent events rather than embedding a Rust library.
03
Lifecycle operations return an identifier to poll, while command output uses a separate attachment token scoped to the session.
Perplexity has published the source code for SPACE on GitHub under Apache 2.0. The platform runs agent and user code in isolated environments, with each workspace getting its own virtual machine and writable filesystem. Applications choose what to run and which results to retain; SPACE manages the sandbox, processes and output connection.
From a template to a running command
SPACE stands for Sandboxed Platform for Agentic Code Execution. It runs code inside Firecracker microVMs—isolated virtual machines. Its intended uses include an agent’s execution environment, a user workspace or a job that needs to run code separately from the application directing it.
Work starts with a template that supplies the initial environment. A sandbox is an instance of that template, and multiple commands can run in the same sandbox. The application does not need to create a fresh environment for every command.
The application first creates the sandbox and waits for it to become ready. It then creates a command session and attaches to that session to start the process. From there, it reads the command’s output and exit result. The application can keep, pause or suspend the sandbox, wake it when needed, or delete it.
Commands and lifecycle changes take different paths
Applications control SPACE through an HTTP API that creates Linux environments, executes commands, collects output and manages sandbox lifecycles. SPACE itself is implemented in Rust, but applications do not need to embed a Rust library. They communicate over HTTP and server-sent events, a mechanism for receiving a stream of updates.
Lifecycle changes are asynchronous: the API returns an operation identifier, and the application checks that identifier until the operation completes. Command output travels over a separate connection, using an attachment token scoped to the session.
Deployment comes before the first sandbox
The deployment documentation directs users to install SPACE in a local Kind cluster and authenticate before following the first-sandbox example. That setup guide covers Kubernetes, while the architecture guide explains how SPACE can run without it.
The first-sandbox walkthrough uses a Python example requiring only its standard library. The documentation also covers an E2B compatibility wrapper, a tested E2B Python SDK, and the supported behavior and limitations of that route.
Sources
github.comGitHub - perplexityai/SPACE: Sandboxed Platform for Agentic Code Execution: pluggable-runtime sandboxes for running agent and user code in isolation.
github.comGitHub - perplexityai/SPACE: Sandboxed Platform for Agentic Code Execution: pluggable-runtime sandboxes for running agent and user code in isolation.
Reader comments
Newest comments first. Replies stay oldest first.