Perplexity launches SPACE runtime for long-running AI agents

Official Perplexity Research image for the SPACE runtime article.Perplexity Research
Official Perplexity Research image for the SPACE runtime article.Perplexity Research
AI & Automation

Perplexity says SPACE now runs 100% of Computer sessions, giving its agent product a VM-based sandbox layer for persistent state, snapshots, egress control, and faster startup.

Perplexity has moved its Computer agent product onto SPACE, a sandbox runtime built for agents that need to run code, keep files, pause, resume, and survive long sessions. The company says SPACE now powers 100% of Computer sessions after a June rollout, with millions of sandbox creations and tens of millions of reconnects already handled.

That makes this more than a backend engineering note. Perplexity is describing the execution layer underneath recurring cloud tasks, agent sessions, and future developer-facing runtimes. For teams comparing AI agents, the useful question is also where the agent runs, how credentials are protected, and whether state can be recovered when a task spans hours or days.

SPACE gives Perplexity Computer a persistent execution layer

Perplexity defines SPACE as the Sandboxed Platform for Agentic Code Execution. The architecture is built around a stateless control plane, node-local services, and the sandbox itself. The sandbox runs as a virtual machine with its own guest kernel, plus an in-guest space daemon that brokers filesystem, process, and readiness operations over a controlled private channel.

That design targets a different workload from short container jobs. Agent sessions may collect context, create files, open processes, call tools, and wait on a user or external event. Destroying the environment after each step would break the workflow. Keeping it alive without stronger isolation would create security and credential risk.

Perplexity's own Help Center now frames Scheduled Tasks in Computer around this same agent system. Users can ask Computer to run recurring work, such as monitoring inbox replies, producing reports, or sending briefings, and the task runs in the cloud rather than on the user's laptop. The public help page says those scheduled tasks can use the same tools, connectors, and subagents available in a one-off Computer conversation.

The security model keeps secrets outside the sandbox

The important technical claim is that SPACE treats the agent workload as untrusted. Perplexity says each sandbox has VM isolation and host process isolation, so an attacker would need to cross multiple boundaries to reach other workloads. Network access is forced through a gateway, and communication with the sandbox runs through dedicated channels rather than direct client access.

Credentials are handled outside the sandbox boundary. Perplexity describes a credential store with vault backends, scoping, expiry metadata, rate limits, and audit logging. When an agent needs access, credentials can be injected at the network layer or filled by a browser agent instead of being placed directly in the guest environment.

This is the part agent builders should read closely. Long-running agents need permissions, files, and network access to be useful, but every additional capability expands the blast radius if a prompt injection or malicious dependency steers the agent into the wrong action.

Snapshots make agent sessions pause, recover, and branch

SPACE supports create, pause, resume, suspend, restore, rollback, forking, and crash recovery through an explicit sandbox lifecycle. Disk snapshots capture filesystem state frequently, while full snapshots checkpoint the paused virtual machine less often. When a session is suspended, Perplexity says artifacts move to object storage only after a database record can confirm the full snapshot is restorable.

That matters because interruption is normal. A task can wait for human approval, hit a rate limit, need a later check, or crash after modifying files. A runtime that can resume from a known point is better suited to recurring work than one that has to reconstruct every step from scratch.

Perplexity also says SPACE uses btrfs for copy-on-write storage. Warm pools keep common templates ready, and matching requests can bind to a prepared pod instead of downloading or copying a full image. In production comparisons, Perplexity reports median sandbox creation falling from 185 milliseconds to 60 milliseconds.

What LinkLoot readers should verify

For end users, the visible change is tied to Perplexity Computer: recurring tasks, background runs, notifications, and saved task sessions. For developers and platform teams, the bigger signal is that agent vendors are turning runtime isolation, snapshotting, and credential handling into product infrastructure.

The open questions are practical. Perplexity says it wants SPACE to expand across Linux microVMs, Windows guests, and local machines, but the current public article is primarily an architecture release for Perplexity's own Computer sessions. Teams should verify product availability, pricing, connector permissions, retention controls, and enterprise key-management terms before treating SPACE-backed tasks as a regulated workflow runner.

If you are evaluating agent platforms, compare this with your own risk checklist: where code runs, how files persist, how secrets enter the session, which network paths are allowed, and whether logs or snapshots can be audited. LinkLoot's broader guide to AI agent tools is a useful place to track those differences as runtimes become part of the buying decision.

Sources and methodology

This post uses Perplexity Research as the primary source, Perplexity's Help Center for the Computer Tasks rollout surface, and TestingCatalog for independent discovery context. Social posts were treated as signal only; the article relies on public Perplexity pages and corroborating coverage for factual claims.