Runtimes & sandboxes

Where your code runs. An isolated sandbox on CPU or GPU, with the GPU and RAM you pick.

Every cell runs in a sandbox: an isolated environment with its own filesystem, its own Python kernel, and its own installed packages. Nothing runs on your machine, and one project's sandbox can't see another's. That's what lets the agent install packages, write files, and train models safely.

CPU and GPU

The runtime is the machine the sandbox runs on. There are two kinds:

CPU is the default. It's fine for loading and cleaning data, plotting, querying, feature work, and classical ML like scikit-learn. CPU is free on every plan, with 8 vCPUs and 8 GB of RAM.
GPU is for the cells that need one: training or fine-tuning deep models, large matrix work, anything that would crawl on CPU. GPUs are metered by the minute and available on paid plans.

You don't pick one runtime for the whole project and live with it. Attach a GPU when a cell needs it, and let the rest run on CPU.

Picking a runtime

The runtime picker sits next to the model picker in the chat toolbar. You choose a GPU type and a RAM tier, and it shows a live estimate of the hourly rate for that combination. Options your plan doesn't include are locked.

GPU types, grouped by the plan that unlocks them:

Tier	GPUs	Plan
Entry	T4 (16 GB), L4 (24 GB), A10 (24 GB)	Plus
Performance	L40S (48 GB), A100 (40 GB and 80 GB)	Pro
Flagship	H100 (80 GB), H200 (141 GB)	Max

RAM tiers: 8, 16, 32, 64, and 128 GB. How high you can go depends on your plan. Free tops out at 8 GB, Plus at 32, Pro at 64, and Max at 128.

You can also set a project's default runtime so new work starts where you want it, then change it per run when one step needs more than the rest.

You're billed for GPU time as it runs

GPU runtime is metered by the minute while it's attached to your work, and the picker's hourly estimate tells you the rate before you commit. A sandbox that has seen no activity for about 15 minutes is torn down on its own, so you're not paying for a GPU you walked away from. A long-running cell doesn't count as idle: an execution in flight keeps the sandbox alive.

There's a second, harder limit worth knowing before you start a long job. A GPU sandbox has an absolute lifetime of 12 hours, and a running job cannot extend it. If your training run would cross that mark, checkpoint your weights to the workspace and resume from them in a later run.

The figure on the usage page shows how the meter actually behaves across a run.

What's pre-installed

Every sandbox boots with a fixed Python 3.11 image, so you're not starting from an empty environment. What's in it:

Data: numpy, pandas, scipy, pyarrow, openpyxl
ML and stats: scikit-learn, statsmodels
Plotting: matplotlib, seaborn, plotly
Everything else: requests, httpx, tqdm, tabulate, plus the Jupyter kernel itself and git / git-lfs

GPU runtimes add the deep-learning stack on top, already wired to see the GPU: PyTorch with CUDA, torchvision, transformers, accelerate, datasets, huggingface-hub, sentence-transformers, and OpenCV.

Anything else, including common names like XGBoost, LightGBM, and Polars, is one install away. Ask the agent to install it, or run !pip install <package> from a cell yourself.

Cold starts and what survives a restart

The first cell you run in a project has to start the sandbox, so it takes longer than the cells after it. On CPU that's usually a few seconds. On GPU it's slower, tens of seconds when the image is warm and up to a couple of minutes on a genuinely cold start, because the GPU image is large. Once the sandbox is up, the cells after it run immediately.

Two things behave differently across a restart, and it's worth being clear about which:

Files in the workspace persist. Anything you or the agent wrote under the workspace is synced out, and a fresh sandbox is rehydrated from it. Your CSVs, saved models, and outputs are still there tomorrow.
Installed packages do not. A pip install lives in the sandbox image, not the workspace, so a new sandbox starts from the base image again. If a package matters to a notebook, keep the install in a cell so re-running the notebook reinstalls it.

Kernel state is checkpointed

The sandbox shutting down does not mean your variables are gone.

While a project sits quiet, Clusy checkpoints the kernel's namespace — your DataFrames, fitted models, and other variables — and stores it. When the sandbox comes back, whether that's after the idle teardown, after you switch runtime profile, or the next morning from a cold start, the namespace is restored before your next cell runs. You don't re-run the notebook from the top to get df back.

The sandbox really does go away: about fifteen idle minutes and it is torn down. Your kernel namespace does not go with it — it is checkpointed on the way out and restored into the next sandbox, so df, model and scaler are already there and nothing re-runs from the top.

Two limits to know about:

Big namespaces are skipped. Over roughly 256 MiB of state, the checkpoint is not taken. Reload from a file rather than relying on a namespace that size.
Some objects can't be captured. Anything Python can't pickle — an open database handle, a live CUDA context, a file descriptor — is dropped from the checkpoint. The rest of the namespace still restores; those specific names come back missing, and you rebuild them.

How this ties into branching

Branching runs on the same machinery. When you fork a branch, Clusy checkpoints the variables in the sandbox and the new branch restores from that checkpoint. That's why forking keeps your loaded data and fitted models instead of recomputing them — and why the same two limits apply: a namespace over ~256 MiB isn't carried across the fork, and unpicklable objects don't survive it. The fork figure on the branches page shows what does and doesn't move.