A useful separation
Durable lifecycle records and live command traffic take different paths. Your app can manage an environment independently of an open output connection.
Architecture ↗ PERPLEXITY’S OPEN-SOURCE SANDBOX PLATFORM
Big ideas.
A room of
their own.
AI agents write code. SPACE gives that code its own little Linux computer to run in. Isolated, controllable, and ready for the next command.
See what happens inside ↘A hands-on explanation. No infrastructure required.
EXECUTION ENVIRONMENT ISOLATED
your appother sandboxes
◈SANDBOX_01
A computer.
Just for this job.
Just for this job.
LinuxOwn kernelOwn filesystem
Firecracker microVM ↗
$ python analysis.py
✓ Report generated: /home/user/report.csv
Process exited with code 0 ▍
01 / EXECUTE WITH A BOUNDARYCONCEPTUAL VIEW
THE 20-SECOND VERSION ↓
Your agent decides what to do. SPACE manages where the code runs. Your app collects what comes back.
Sandboxed Platform for Agentic Code ExecutionOpen source · Apache-2.0 · HTTP API
01 / FOLLOW THE REQUEST
One command.
A whole system behind it.
Press play, or walk through the steps.
Watch who does what as your code runs.
→
→
CONTROL PLANE ↓
↔
←
▱ Object storageTemplates in · snapshots out
Click any component to look closer.
The diagram groups several worker services to keep the flow readable. Kubernetes is one deployment adapter; direct worker management also exists. Architecture source ↗
02 / GET A FEEL FOR STATE
Close the laptop.
Keep the thought.
Pause holds a VM in memory. Suspend saves it
and releases active resources. Try both.
Running
VM resources activeLIVE MEMORYResident
WORKSPACE FILEreport.csvInside this sandbox
SNAPSHOTNone yetUse suspend to save state
Run: use it Pause: hold it Suspend: save it Delete: retire it
03 / PUT IT TO WORK
What could you build?
SPACE supplies the execution environment.
Your product supplies the purpose.
YOUR APP HANDLES
SPACE HANDLES
AN ILLUSTRATIVE WORKFLOW↗
OUTCOME
These are application ideas inferred from the platform primitives, not bundled products or claims about Perplexity’s internal usage.
04 / THE PART PEOPLE MISS
A connection ends.
Did the job finish?
A request, a VM, a process, and its output stream have different lifetimes. Explore three outcomes.
05 / THE ENGINEERING TAKE
Powerful primitives.
Real operating work.
My read after checking the architecture,
source, compatibility docs, and test coverage.
Linux infrastructure
The documented setup needs x86_64 Linux, KVM, privileged Docker, networking devices, and btrfs. A Mac can be your client; hosting needs a suitable Linux machine.
Host requirements ↗Compatibility has edges
The E2B wrapper tests specific Python SDK versions. JavaScript SDK compatibility is untested; capabilities such as MCP, volume mounts, and IAM create fields are rejected.
E2B contract ↗Still before 1.0
The inspected workspace declares 0.8.0. The release plan reserves 1.0 for stable contracts. Recovery and concurrency tests are encouraging evidence, not proof of your workload’s reliability.
Release policy ↗Open the technical notes Rust, warm pools, trust boundaries, and retries +
What’s actually in the code?
A Rust workspace using Tokio, Axum for HTTP, Tonic for RPC, and SQLx/PostgreSQL for the control plane. Node services manage the VMs; guest-side spaced services handle in-guest work. Files and templates span local disks and object storage.
Pluggable doesn’t mean every runtime ships
The qualified default environment is Linux/x86_64 with Firecracker 1.15.1 and guest kernel 6.1.155. The source also defines approved 1.17.0 bindings for selected non-production environments. That is not general macOS, Windows, or arbitrary-runtime support.
Execution environments ↗Fast creates need a strategy
Warm pools keep ready VMs by template release and size. Native Kubernetes creates require admission-time pool claiming to be enabled; custom disk sizes or file-change tracking use cold boots. Single-node base snapshots offer another startup path. No latency benchmark is asserted here.
Warm pools ↗Isolation is only one boundary
Management bearer tokens, scoped attachment tokens, internal RPC TLS, tenant ownership checks, and network policies have separate jobs. Host services retain VM, disk, and networking privileges. Firecracker isolation does not replace those controls.
Internal transport ↗Retry with evidence
Keep the same idempotency key and original payload for the same declared operation. Guest retry records live for the daemon’s lifetime, so a guest-daemon restart cannot establish exactly-once execution. Replaying a command request also rotates attachment credentials; overlap of old credentials is a deferred contract.
Guest implementation ↗ · Replay contract ↗What I’d verify before adoption
Run your actual workload through disconnects, snapshot restore, and service restarts. Measure cold and warm latency, persist output in your own app, define resource limits and artifact retention, and budget for idle warm VMs. This guide is based on source inspection; SPACE was not deployed or benchmarked for this review.
Recovery coverage ↗A fresh workspace.
A repeatable experiment.
For skill testing, the useful pattern is simple: pin a template, create a fresh sandbox, run a task, collect the evidence, then clean up. Your evaluation harness still decides what “good” means.
Read the first-sandbox walkthrough ↗