Fractional
VRAM slices, 0.5 to 28 GiB
Each sandbox holds a slice of a shared GPU instead of renting the whole card. Ask for accel.vram_gb or a tier: S 1, M 2, L 8 GiB. Tier XL (32 GiB) needs a larger card, which is not live yet. A 0.5 GiB slice runs small CUDA jobs; start at 2 GiB (tier M) for training-sized allocations. Measured through the public API on 2026-10-17 on one RTX 5090 (nvidia.5090), the largest single torch tensor that allocated (binary search, 8 MiB steps) was: 0.5 GiB slice: 248 MiB; 1 GiB slice: 760 MiB; 2 GiB slice: 1784 MiB. About 264 MiB of each slice goes to the CUDA context and allocator. A create is admitted only if the slice fits what is free on the card; GET /v0/gpu/capacity reports the largest one as max_admit_gib.
State
Pause and resume
On pause-capable templates, pausing releases the GPU, unless other processes in your lease hold VRAM or the VRAM probe is unreadable, in which case the lease freezes, keeps its seat and bills its frozen time. When the GPU is released, your GPU state is spilled to host memory and restored bit-exact on resume. Your Python variables persist across execs and across pause and resume.
Billing
Busy-second billing
Every exec is billed from dispatch to result, and a resume bills the time it takes to restore your state. Idle residency bills only while the GPU is observed active, and suspended time bills 0, unless a lease falls back to freeze-only, which happens when other processes in your lease hold VRAM or the VRAM probe is unreadable: the lease then keeps its seat and its paused time is billed. Templates that cannot release the GPU bill while they hold it. Read billed seconds from meters.billed_s on get and exec replies, and from billed_s in the delete reply body; create, pause and resume replies carry no meters.
Planning
Typed refusals, an optional queue
When no seat is free, a create answers at once with a typed error and Retry-After. GET /v0/gpu/capacity shows free seats before you ask, and accel.wait_s (0 to 120 s) makes a create wait for one.
Isolation
A hard VRAM cap
The slice is enforced, not advisory: an over-slice allocation fails inside your job, and on hard-cap hosts, which includes our RTX 5090 node, a watchdog kills a lease that goes past its cap within about a tenth of a second. In 10 hostile-tenant trials at the shipped cap on rented A100 40 GB hosts at full density, the attacker (3 extra CUDA contexts) was stopped in all 10; its neighbours saw 0 errors in 9, and in the tenth one neighbour request was refused for capacity before the attack began.
API
REST, MCP, CLI
The same verbs and X-API-Key auth as the E2B-compatible CPU sandboxes, with an extra accel object on create. GPU leases are driven over REST, the remote MCP server or the sbx gpu verbs of the open-source sbx CLI (create, exec, pause, resume, kill, templates, info), not the stock E2B SDK, which drives CPU sandboxes only.