Baseten 发布 Sandboxes，为智能体提供可暂停恢复的有状态执行环境

Please rotate your device

To continue exploring this website, please rotate your device to a vertical orientation

Product

Building the Agent Cloud: Introducing Baseten Sandboxes

Baseten Sandboxes let agents run long tasks securely and statefully, with instant pause and resume. They’re the first piece of our cloud for agents.

Authors

Paul Sinai

Nicolas Lecomte

Sai Maddali

Rachel Rapp

Date

November 5, 2026

Today, we’re introducing Baseten Sandboxes, the cornerstone of a cloud purpose-built for agents.

Agents are already taking on entire projects, from writing software to investigating problems and running core business workflows. To complete that work quickly and reliably, these agents need models, tools, compute, and state built to work together over long-horizon tasks.

Together, these needs demand a new kind of cloud: a cloud made for agents, with stateful runtimes, storage, and networking designed as a single system. Sandboxes are the first piece in that puzzle, giving agents their own persistent computer.

We’re making Baseten Sandboxes free to run until November 16th; try them out!

Sandboxes: the foundation for agent execution

Sandboxes are the foundation that agents need to act. At its core, agent performance is a systems problem. Running code in a container isn’t hard on its own; the hard problems to solve are:

1. Statefulness: how do agents run long tasks without losing context between steps, or you paying for compute while they sit idle?
2. Security: how do you let agents run untrusted code without putting your infrastructure, data, or other users at risk?
3. Latency: how do you spin up new sandboxes without compounding latency across long-horizon work and network round-trip with inference?

Baseten Sandboxes solve each of these problems. They’re built from the ground up to be:

1. Stateful: as soon as the agent finishes, the sandbox suspends immediately while preserving state; suspend/resume are instant, so you don't pay for idle compute.
2. Isolated: Sandboxes run on microVMs, which are the gold standard for isolating untrusted code.
3. Elastic: boot a sandbox from standby in only 25 milliseconds, and scale to thousands of sandboxes within seconds.

The Baseten dashboard for a deployed sandbox, showing its region, allocated RAM, image, and labels, plus live metrics for API requests, error rate, CPU, and memory. Each sandbox comes with built-in observability, so you can see what an agent’s environment is doing without setting up your own monitoring.

Enabling isolation and fast spin-ups with microVMs

Each Baseten Sandbox gets its own microVM with its own kernel and hardware-level isolation, providing more isolation than container-based solutions. This allows agents to execute code, manipulate files, and run processes inside an environment configured for their work without risk of lateral movement.

Initial startup and in-sandbox operations (read/write) are extremely fast, so latency doesn’t compound over agentic loops.

Keeping long-running agents stateful with instant suspend and resume

Whereas other sandboxes are ephemeral, or require developers to manage state explicitly, statefulness was a priority for us from inception. When an agent disconnects from a sandbox, everything is snapshotted—filesystem, memory, and actively running processes—and when it wants to resume its work, it restarts within 25 ms (up to 5x faster than other sandboxing tools, which compounds quickly over long-running agentic work). This enables us to scale compute to zero while the environment sleeps to reduce unnecessary cost.

A sandbox’s lifecycle across three states. An idle sandbox snapshots its files, memory, and processes into standby with compute at zero, then resumes in about 25 ms on the next request. Agents keep their full state between tasks without you paying for idle compute.

This fundamentally changes what teams can build: agents can carry a project across sessions, pause for input from teammates, and continue with their environments intact. There are also utilization and cost benefits, since applications can maintain many persistent workspaces while allocating compute to the ones actively doing work.

As agents run longer and serve more users, preserving progress and managing idle compute become essential parts of agentic infrastructure.

Building a new cloud

Sandboxes are the first building block of a new kind of cloud, one made for agents.

Before the advent of GenAI and agents, every cloud primitive was built to deploy one application capable of serving millions of users. Agents invert that paradigm; instead of a single application, you now have millions of micro-applications, with each serving a handful of human or agent users.

To function properly, each agent’s environment must include the tools it needs to function, the work it accumulates, and the files it needs to carry between tasks. This demands a new type of cloud, purpose-built for agents: one that combines the compute, storage, networking, and identity required for high-scale, long-running agentic work.

To meet these needs, we’re building the foundation of an agent cloud. It will include:

• Compute: Sandboxes (described in detail above)
• **Storage:**Agent Drive, a shared, distributed, remote filesystem across sandboxes. Think of it like storage on Google Drive in addition to your local laptop, but optimized for high write volume and small-sized files (like code and markdown).
• **Networking:**Agent Proxy, which controls what agents can and cannot connect to, enforced outside the sandbox. Credential injection happens on the fly so agents can make sensitive calls (e.g., to Stripe for a payment), and the proxy can inject the credential without the agent ever seeing it.

This all includes a built-in permission system, an audit trail with thorough logging, and support for firewalling, static IPs, and many configurable knobs for builders.

Stay tuned for more announcements as Agent Drive and Agent Proxy come online in the coming months.

The whole is greater than the sum: inference, training, and execution