Runtimes & sandboxes

Every cell runs in an isolated sandbox with its own filesystem, Python and R sessions, and installed packages. Nothing runs on your computer, and one project cannot see another project's sandbox.

Three settings describe it:

• the stack (also called the sandbox type), which decides what software is preinstalled,
• the hardware, which is CPU or a specific GPU,
• and the amount of RAM.

Sandbox types

All types are available on every plan. Auto reads the first request and selects Machine learning, Documents, or Web when the match is clear, with Base as the fallback. You can choose the stack yourself before execution.

The type locks after the first run

You can change the type until the project's first cell finishes successfully. After that it is permanently locked because saved state and installed software are tied to the original image. To use another stack after the lock, create a new project.

Hardware and RAM remain changeable for the life of the project.

CPU and GPU

CPU is the default and is fixed at 8 vCPUs and 8 GiB of RAM. It is a good fit for loading and cleaning data, plotting, querying, and classical machine learning. Higher selectable system-RAM tiers apply to GPU sandboxes only.

GPUs are available on paid plans and are metered by wall-clock time while the sandbox is running. Use one for deep-learning training, fine-tuning, or large matrix work, then switch back to CPU when it is no longer needed.

For GPU sandboxes, selectable system RAM is capped at 16 GB on Plus, 32 GB on Pro, 64 GB on Max 10x, and 128 GB on Max 30x. Free has no GPU; its CPU sandbox remains fixed at 8 GiB.

Using the sandbox picker

Before the notebook surface is visible, the sandbox picker sits in the chat context bar. Once a notebook is open, it moves to the canvas tab bar beside Share. In compact and floating-chat layouts it is also available from the overflow menu.

The picker edits a draft. Choose the stack, hardware, and RAM you want, review the before/after rows, then select Apply once. Reset discards the staged changes. Options outside your plan are locked and open the relevant upgrade choice.

Sandbox changes are disabled while work is running.

Switching hardware without losing work

A hardware or RAM change replaces the machine. If the current kernel has state to lose, Apply asks how to make the move:

• Transfer state (recommended) copies variables to the new sandbox. Objects that cannot be pickled—open files, database connections, CUDA handles, and similar live resources—are left behind. A transfer can take a few minutes.
• Start clean moves faster and starts with an empty namespace. Existing cell outputs stay visible until you rerun them.

Your notebooks, workspace files, installed packages, and environment are kept either way. If there is no kernel state to lose, the switch applies without the extra question.

A transferable branch checkpoint is capped at 4 GiB. If the state is too large or cannot be captured, the switch is refused with an explanation and the dialog lets you choose Start clean instead. Save large data or model weights to workspace files before moving machines.

On the Machine learning stack, CPU and GPU images carry aligned PyTorch packages, which avoids reinstalling the deep-learning stack during ordinary switches.

What is preinstalled

Every sandbox uses Python 3.11. The Base image includes:

• Data: numpy, pandas, scipy, pyarrow, openpyxl
• ML and stats: scikit-learn, statsmodels
• Plotting: matplotlib, seaborn, plotly
• Utilities: requests, httpx, tqdm, tabulate, Jupyter, git, and git-lfs

The typed images add their specialized packages, and GPU runtimes add a CUDA-enabled deep-learning stack. Install anything else with pip in a cell or ask the agent to do it. Packages you add are recorded and reinstalled best-effort after a rebuild.

Starting, pausing, and resuming

The first cell starts the sandbox, so it is slower than later cells. CPU cold starts usually take seconds; a GPU image can take tens of seconds or, when cold, a couple of minutes.

A sandbox shuts down after about 15 idle minutes. A running cell prevents that idle shutdown while someone remains present. If everyone disconnects and no agent run is active, the separate leave boundary starts after 60 seconds, gives an in-flight cell up to 30 more seconds, then interrupts it and pauses or releases the sandbox.

• A CPU sandbox pauses and usually resumes with memory already present.
• A GPU sandbox is released; the next one cold-starts and restores the last saved state.

Billing stops when the sandbox pauses or is released. On Free, CPU time consumes the free allowance; on paid plans, CPU is unmetered. A GPU sandbox has a hard 24-hour lifetime, so write training checkpoints to workspace files and complete a leave/transfer boundary—or export them—before relying on them after that machine is gone.

A leave boundary saves a durable bundle before the runtime pauses or is released. CPU usually resumes with memory intact; after a release or unavailable machine, a fresh sandbox restores the saved state without rerunning the notebook.

What survives

• Notebook cells and outputs persist independently. They are stored outside the live machine as work proceeds.
• Workspace files become durable at a completed boundary. Files written since the last successful leave or transfer capture can still be lost in an abrupt sandbox failure.
• Kernel variables persist at durability boundaries. Clusy saves them when the project leaves and when you choose Transfer state during a sandbox switch. See Saving & restoring state.
• Packages are reinstalled best-effort. Keeping important installs in a cell still makes the environment easiest to reproduce.

Live sandbox limits

This caps simultaneously running projects, not the number you can own. Paused projects do not count. Branch kernels have a separate limit: 3 on CPU and 8 on GPU.