Baseten has added a way to give every user of your agent app its own computer. Baseten Sandboxes are isolated environments where an agent runs commands and works with files, and Baseten's documentation says they are available now, "free to use until November 16," with up to 10 sandboxes at once per organization (Baseten docs). The launch came in the same week as Baseten's Grid model router, which we covered in Baseten Grid Router: is the 72% coding cost cut real?.
This post sticks to what Baseten's own docs say. A few launch claims, such as millisecond boot times, appear only in social posts relayed by an aggregator, and we mark them as unconfirmed.
TL;DR: the questions people ask first
| Question | Answer (from Baseten's docs) |
|---|---|
| What is it? | Isolated environment where an agent runs commands and works with files |
| Cost? | Free until November 16; no later price in the docs we read |
| Limit? | 10 sandboxes at once per organization, raised through support |
| Idle behavior? | Standby after about 30 seconds; files and processes kept; storage billed |
| Default lifetime? | Expires 7 days after creation |
| How do I use it? | Baseten CLI, SDKs for TypeScript, Python and Go, or the API |
| Saved data? | Deleted with the sandbox; use outside storage or a volume |
How a sandbox works
Each sandbox starts from an image, a container image that includes a base environment such as Python or Node.js, tools, starting files, defaults for memory and ports, and a sandbox API server that runs commands and file operations. You can use a built-in image or build a custom one from a Dockerfile or import from a registry. A general-purpose image such as python:3.12 does not include the API server, so a custom image must add it. Baseten builds and versions the image, and each sandbox starts from a copy of a built version.
Files a sandbox creates while it runs do not change its image. For task inputs and outputs, Baseten tells you to use file operations.
Standby, resume and keep-alive
This is the feature that matters for agent apps. According to the lifecycle docs:
- A sandbox goes on standby after about 30 seconds without requests.
- On standby it keeps its files and running processes, and you pay only for storage.
- Processes pause until the next request resumes the sandbox "where it left off."
- A process started with
--keep-alivekeeps the sandbox awake while it runs.
Many users never run their agent continuously. A per-user environment that costs only storage while idle makes one sandbox per user practical. The docs do not state resume latency or how process state is preserved, so test resume time and whether your own processes survive a pause.
Expiration: the default is 7 days
Sandboxes expire 7 days after creation by default. You can set one policy of each type:
| Policy | Meaning |
|---|---|
| TTL_MAX_AGE | A duration after creation; activity does not extend it |
| TTL_IDLE | A duration without activity |
| DATE | A specific timestamp |
Baseten deletes the sandbox when the first condition is met, and deletion permanently removes its local data. The docs say to retrieve results first. To keep files across sandboxes, mount a sandbox volume. A sandbox that expires mid-task must be recreated and its saved outputs restored.
For an agent product, that is a design constraint. Long-running user projects need a plan for saving state outside the sandbox or a volume, or users will lose work on day 8.
Try it in five minutes
The docs give a short CLI path:
baseten auth login
baseten sandbox create --name hello-world
baseten sandbox exec --name hello-world -- 'printf "hello from the sandbox\n"'
baseten sandbox delete --name hello-world
Creation waits for status DEPLOYED. You can also open an interactive terminal with baseten sandbox connect, preview a running web app through a public or private HTTPS URL, and create a sandbox access token so sandbox requests and MCP connections do not need your API key. For lifetime control, add --max-age 1h when you create one.
Why agent apps need per-user environments
A chat assistant only returns text. An agent that builds a website, runs a data analysis or edits a repository needs somewhere to execute code and keep files between steps. Running that on your own servers means solving several problems at once: isolating one user's work from another's, cleaning up abandoned workspaces, keeping idle environments from costing money, and recovering state when a task spans hours or days.
Baseten's pitch is that the sandbox handles those problems as a service. The agent loop stays in your application, and each tool call runs in the user's sandbox. When the user leaves, the sandbox goes on standby. When they return, the next request resumes it.
This pattern is already common in coding agents, and it is the reason sandboxes are becoming a product category of their own. The questions to ask any provider are the same: how fast does it resume, what survives a pause, what does an idle environment cost, and what happens at the limit.
Questions the docs leave open
The pages we read answer how to use Sandboxes but leave several buyer questions unanswered:
- Price after November 16. Only the free period is stated.
- Resume time. Standby is described, but no latency figure appears in the docs we read.
- Concurrency above 10. The limit can be raised through support, with no published tiers.
- Compute sizes. Images set memory defaults, but the pages we read do not list sizes or limits.
- Network controls. The docs mention public and private preview URLs and access tokens, but we did not find a description of outbound network policy.
- Regions and data residency. Not stated in the pages we read.
None of these are unusual for a launch. They are the items to settle in a pilot before relying on the service.
What is claimed but not confirmed
A news aggregator relaying Baseten posts on X describes more:
- Sandboxes "boot from standby in milliseconds" and scale to thousands of instances in seconds.
- They snapshot an agent's processes, memory and filesystem on disconnect.
- A Baseten executive described them as the cloud for agents, built on the company's Blaxel acquisition.
- A serverless fine-tuning product called Loops was due to reach general availability on Friday.
We could not confirm these in the docs we read, and we found no announcement of a Blaxel acquisition on a primary page. Treat the numbers as vendor claims to test. For comparison, our earlier post on the same company, Baseten Grid Router, shows how to separate Baseten's claimed numbers from checkable ones.
Security: what isolation does and does not give you
A sandbox limits where an agent can run code. It does not decide what the agent should do. Isolation reduces the blast radius if an agent runs unsafe commands, but you still need to control credentials, network access and what data goes in. The docs mention access tokens that let you authenticate sandbox requests without your API key, which is a sensible control.
Practical rules for any agent sandbox:
- Give each user their own sandbox. Do not share one across users.
- Keep secrets out of images and out of files the agent can read, unless the task needs them.
- Set a short TTL for experiments and require explicit extension for long projects.
- Log commands run and files written, so you can reconstruct an incident.
- Add a policy layer before the agent acts. AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.
For background on agent sandboxing, see our posts on NVIDIA OpenShell and what developers say, Cloudflare's agent browser on V8 isolates, Oracle's agent sandboxes on Vera CPUs and the MCP security guide.
What this means for what you build or pay
If you build an agent product with per-user workspaces, a managed sandbox with idle standby saves you from running that infrastructure. The free period until November 16 is a chance to test it, with a cap of 10 concurrent sandboxes that fits a prototype, not a launch. The key unknown is the price after November 16. Docs say you pay for storage on standby, but they give no rate for active compute, so do not commit a product to it until the pricing page is published.
A short evaluation plan
- Create sandboxes from your real image and measure create time and resume time from standby.
- Start a long process, let the sandbox go idle, resume it and check the process state.
- Test the expiration policy by setting a short TTL and confirming deletion removes data.
- Hit the 10-sandbox cap on purpose to see how your app handles the error.
- Compare cost and behavior with an alternative you already use before moving workloads.
Related reading
- Baseten Grid Router: is the 72% coding cost cut real?
- NVIDIA OpenShell sandbox runtime for agents
- Cloudflare agent browser on V8 isolates
- Oracle agent sandboxes on Vera CPUs
- MCP security guide
Details are accurate as of November 5, 2026. Sandboxes are new, and limits, pricing and behavior may change. See the lifecycle docs for current details.