Baseten Sandboxes preserve state through standby

An agent waiting for a human to approve a change should not need a running computer just to keep its workspace intact. Baseten's answer is to suspend that computer, including its memory and processes, then resume it when work returns. The catch matters: a suspended process keeps its place, but it does not keep working.

Baseten launched Sandboxes on November 5 (opens in new tab) as the first component of its planned cloud for agents. The service gives an application an isolated environment for each user or project, where an agent can execute code, manipulate files, and carry work between sessions. It is available now and free to use until November 16, with a default limit of 10 concurrent sandboxes per organization (opens in new tab). Higher limits require contacting support.

The useful distinction is between keeping an environment and keeping compute active. Baseten promises the former without continuously paying for the latter. Its lifecycle rules determine whether that fits a particular agent.

Standby saves the process, not its progress while asleep

Each sandbox gets its own microVM, with its own kernel and hardware-level isolation, according to the launch announcement (opens in new tab). Baseten says idle environments are snapshotted, preserving the filesystem, memory, and active processes. A later request restores that state rather than rebuilding a workspace from an image.

That memory is the memory of programs inside the environment. It does not, by itself, give an externally hosted language model a persistent conversation, restore the application's agent loop, or decide what belongs in the next prompt. Developers still own those parts of the system.

The lifecycle documentation (opens in new tab) is explicit about execution: when requests stop, the sandbox goes into standby, its processes pause, and only storage is billed. The next request resumes it. A background worker that must continue after the caller disconnects needs keep-alive, exposed as --keep-alive in the CLI and corresponding SDK options.

Consider a coding agent that prepares a website, starts a development server, and waits for feedback. Standby can preserve that environment between review sessions. But if the agent starts an unattended analysis and expects it to finish while no requests arrive, it needs keep-alive. The saved worker otherwise waits too. Keeping local process state does not guarantee that every external connection survives suspension.

Baseten advertises a 25-millisecond resume from standby and says that is up to five times faster than other sandbox tools. The announcement does not supply benchmark conditions or identify the comparison set. Treat it as a vendor resume claim, not a measured promise for cold creation, network round trips, or a complete agent turn.

A snapshot does not cancel expiration

By default, sandboxes expire seven days after creation (opens in new tab), even if they are active. Developers can configure maximum-age, idle-duration, and fixed-date deletion policies. When several apply, the first condition reached deletes the sandbox. Updating a maximum-age policy still counts from creation, not from the update.

Deletion or expiration permanently removes local files. Recreating a sandbox from the same image restores the image's starting contents, not the deleted workspace. A standby snapshot therefore should not be treated as a backup or an indefinite retention promise.

For files that must outlive the environment, Baseten offers persistent volumes (opens in new tab). They survive deletion of the sandbox that used them, but each volume belongs to one region and can be mounted by only one sandbox at a time. Volumes can grow, not shrink. A project checkout on a volume can pass to a replacement sandbox in that region; the same volume is not a shared disk for a fleet of simultaneous workers.

Compute choices also require planning. A sandbox's name, image, memory, vCPU count, and region cannot change after creation (opens in new tab). The default is 4,096 MiB and two vCPUs (opens in new tab), with account-specific resource ceilings. A workload that outgrows its allocation needs a replacement environment and a plan for moving its files. Available regions come from the sandbox configuration API (opens in new tab), not a blanket promise of every Baseten deployment region.

Two APIs, with the runtime inside the image

The service separates provisioning from work. The Management API (opens in new tab), hosted at api.baseten.co, manages sandbox instances, images, previews, and volumes. Each sandbox serves its own runtime API (opens in new tab) for file and process operations, plus network inspection.

That runtime API is a process inside the sandbox. A general-purpose container image is not enough: it must include and start Baseten's sandbox API server. The image documentation (opens in new tab) provides built-in environments for Python, Node, browsers, web applications, and desktops, as well as custom-image builds. Builders can pin the API image to a tested tag or digest, rather than letting latest silently change new builds.

The TypeScript, Python, and Go SDKs (opens in new tab) wrap both APIs and handle sandbox access tokens. The CLI offers commands and an interactive terminal; an MCP endpoint exposes command and file tools to clients. Applications needing narrower agent tools can define their own SDK-backed functions instead of exposing the full MCP tool surface. CLI sandbox commands remain pre-release.

Successful deployment is not successful work. A sandbox in standby still reports DEPLOYED. The runtime can return HTTP 200 when a command exits unsuccessfully (opens in new tab), so orchestration must inspect the command's exit code and output. The dashboard's error-rate chart counts HTTP failures (opens in new tab), not every failed program.

Isolation leaves credential decisions with the application

The microVM is the isolation boundary Baseten describes for running untrusted code. That architecture is not proof that a malicious agent cannot misuse whatever data or credentials the application deliberately places inside it.

The configuration docs warn that secret environment variables remain readable to code inside the sandbox (opens in new tab), including an agent able to run commands. Masking those values in ordinary configuration responses does not hide them from the workload. Baseten specifically warns against putting its API key in a sandbox environment.

Sandbox access tokens expire after two hours (opens in new tab), carry the caller's team memberships, and are not scoped to one sandbox. The SDKs and CLI obtain replacements automatically; direct integrations must handle that themselves. The token endpoint is experimental. These tokens belong outside agent prompts, logs, and submitted code.

Sharing an application is a separate permission decision. HTTPS previews are private by default (opens in new tab) and require their own preview tokens; a sandbox access token does not grant access to a private preview. Making one public lets anyone with its URL reach the application. Preview tokens are credentials too, and their expiration is separate from the preview's expiration and the sandbox's deletion policy.

Free launch access, published storage charges

The free-until-November-16 offer is time-limited, not a permanent free tier. Alongside that offer, Baseten's public pricing page (opens in new tab) lists these sandbox rates:

Those are the rates displayed on November 6, not an assumption about an unannounced post-promotion tariff. The standby billing rule (opens in new tab) eliminates idle compute charges while retaining storage charges. Persistent workspaces still have a storage budget, even when their CPUs are asleep.

Baseten's broader plan goes beyond the runtime. The announcement describes Agent Drive (opens in new tab), a shared remote filesystem, and Agent Proxy, an externally enforced networking layer with credential injection, as coming in the following months. Those roadmap products should not be counted as current Sandboxes features or confused with today's single-attachment volumes.

For agents that alternate between bursts of execution and long waits for people, saved process state is a concrete advantage. For continuously running workers, shared multi-agent storage, or credentials that must never enter the environment, standby alone does not answer the requirement. The adoption decision starts with what must keep running, what must survive deletion, and what the agent is allowed to read.