Choosing a Sandbox: CPU, RAM and storage

The golden rule: GPU inside the Sandbox?

If your work is an agent or app that calls an LLM, inference happens in Token Factory, not in your Sandbox. In that case a CPU-only Sandbox is enough: it is the cheapest, and the model runs on the cluster B200s, which you reach over the internal RDMA network.

You only need a GPU inside the Sandbox if you run a model locally, do fine-tuning, process video/image with acceleration or experiment with CUDA. For everything else, CPU-only and use Token Factory.

Available profiles

Each profile has CPU and RAM ranges you adjust when creating the Sandbox:

How much CPU and RAM

CPU: for a coding agent, 2–4 vCPU is plenty; the bottleneck is the network to the model, not your container. Go higher if you compile, run heavy tests or process data in parallel.

RAM: size it by the data you keep in memory (datasets, indexes, large context). For normal development, 8–16 GB. For in-memory datasets or several services at once, more.

Storage

The volume is persistent: it survives suspensions and restarts, on DDN EXAScaler storage. It is prorated by how long the volume exists, not by CPU usage. Size it by your repo + dependencies + data; you can grow it later.

Auto-suspend: you pay for real usage

When the Sandbox is idle it auto-suspends and stops counting the compute rate (the persistent volume stays, so your data is kept). Reconnect over SSH and it resumes. This means leaving a Sandbox "open" all week does not ruin you: you only pay active hours, or pick a flat monthly rate if you work daily.