The AI Studio sandbox
The workspace behind every Studio project - starting, pausing and restarting it, what happens when it is left unused, and how your files come back.
Every AI Studio project has a sandbox: a private container where the assistant writes files and runs commands, and where your preview is served from. This page covers how it starts and stops, what the platform does with it when nobody is using it, and what to do when it fails.
The states it can be in
The chip next to the project name always shows one of these:
| State | What it means |
|---|---|
| Not started | The project exists; its sandbox has never run. |
| Starting, Waking | On its way up. Usually a few seconds. |
| Running | Ready. This is the only state that is billed. |
| Pausing, Paused | Stopped, with its files and processes kept for a fast resume. |
| Failed | It stopped or could not start. The reason is shown above the panes. |
| Off | Its container has been removed. Your files are kept unless you deleted them. |
It starts by itself
Opening a project starts its sandbox if it is paused, off or not started. You do not have to press anything.
The assistant does the same. If you send a message while the sandbox is off or failed, it starts the sandbox, waits for it, and carries on with your request. A failed sandbox is rebuilt rather than reused when this happens.
The power menu
The power icon at the top right of a project opens the sandbox's own controls:
- Start / Resume - bring it up. Shown when it is not running.
- Sleep - pause it. Files and running processes come back on resume, and billing stops.
- Restart - rebuild the container around your files. Use this when the sandbox failed or stopped answering. Your files are not touched.
- Power off - remove the container and keep your files. Start it again whenever you like.
- Delete - remove the container and every file in the workspace. You are asked to confirm, and this cannot be undone.
While the sandbox is changing state the menu waits: the actions come back as soon as it settles.
When it fails
A failed sandbox shows a banner above the panes with the reason in plain words and a Restart button. Typical reasons:
- It ran out of memory. A heavy install or build used more than the sandbox has. Restart it; if it happens again, run lighter commands.
- It stopped unexpectedly. Your files are safe. Restart it.
- It took too long to start. Starting it again usually works.
- The region is at capacity. Every machine for sandboxes is busy with running ones. Try again shortly.
Restart fixes most failures because it does not reuse the broken container: it removes it and creates a fresh one on the platform's current image, mounted on the same files.
What happens when you stop using it
Two things, at two different delays.
After 15 minutes without activity, it is paused. Nothing is lost; it resumes when you come back, with the processes it had.
After 6 hours without activity, it is taken off its machine. The workspace is written to a .zip archive, then the container and its storage are removed. The chip reads Off. The next time you open the project, a new sandbox is created and the archive is unpacked into it before anything else runs, so your files are where you left them.
What the archive leaves out, because a build restores it: node_modules,
Python virtual environments (.venv, venv), __pycache__, .cache and
.next. After a long break, expect to run your install command again.
Processes do not survive this step either. A dev server that was running before has to be started again - ask the assistant, or use the Logs tab.
Keeping your work safe
The sandbox is a place to work, not a place to keep things. The archive is one file on one machine. What makes your work durable is:
- Publishing the project, which builds an image and deploys it.
- Connecting a Git repository and pushing to it.
- Download code (.zip) in the project's menu, which gives you every file a publish would take.
DevOps Agent projects are different
A project created with Deploy with the DevOps Agent holds repositories cloned to be read and deployed, not written. Its sandbox is never archived: the code is deleted when the work ends. See The DevOps Agent and your code.