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 and XGBoost. 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 under the chat input. 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: T4, L4, A10, L40S, A100 (40 GB and 80 GB), H100, and H200.
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. An idle sandbox shuts down on its own after a while, so you're not paying for a GPU you walked away from.
What's pre-installed
Sandboxes come with the common Python data stack ready to go, so you're not starting from an empty environment. Need something else? Ask the agent to install it, or install it yourself from a cell or the terminal. On a GPU runtime, the deep-learning frameworks are set up to see the GPU.
How this ties into branching
Branching depends on the runtime being able to snapshot and restore kernel state. 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.