On Runtime, a sandbox's CPU, memory and disk limits are enforced on the host, outside the guest. You pay for the CPU the sandbox actually uses: $0.025 per active vCPU-hour, measured, with a floor of 50 thousandths of a vCPU (pricing). Root inside the sandbox cannot raise any of these limits.
How do cgroups work?
The kernel documentation calls a cgroup "a mechanism to organize processes
hierarchically and distribute system resources along the hierarchy in a
controlled and configurable manner." Groups are directories in a filesystem,
usually mounted under /sys/fs/cgroup. A process joins a group when its PID
is written to the group's cgroup.procs file. Limits are files too:
memory.maxsets a hard memory ceiling. When a group reaches it and cannot reclaim memory, "the OOM killer is invoked in the cgroup".cpu.maxtakes "$MAX $PERIOD": the group may use up to MAX microseconds of CPU in each PERIOD.pids.maxis a "hard limit of number of processes". The kernel docs name the reason: "a fork bomb is likely to exhaust the number of tasks before hitting memory restrictions". Past the limit,forkandclonefail withEAGAIN.
Version 2 replaced the several hierarchies of version 1 with one. The kernel docs say "cgroup v2 has only single hierarchy".
Facts
| Property | cgroups, as the man page and kernel docs state it |
|---|---|
| Version 1 | Introduced in Linux 2.6.24 |
| Version 2 | Developed from Linux 3.10, released in Linux 4.5 |
| Interface | A filesystem, usually under /sys/fs/cgroup |
| v2 controllers | cpu, cpuset, freezer, hugetlb, io, memory, perf_event, pids, rdma |
| Hierarchies | Many in v1; one unified tree in v2 |
Are cgroups isolation?
No. Cgroups provide accounting and limits. Docker's security page says cgroups "implement resource accounting and limiting" and are "essential to fend off some denial-of-service attacks". They stop one container from starving its neighbors of memory or CPU. They do not hide anything. Namespaces do that.
Cgroups also work around virtual machines, on the host. Firecracker's design notes say that each Firecracker process can be placed in its own cgroup. This controls CPU affinity and quotas across many microVMs on a host. Its jailer creates those groups before it starts the monitor.
Why it matters for AI agent sandboxes
Agents start many sandboxes at the same time. A runaway build or a fork bomb in one must not slow the rest. Resource limits are also what a bill is computed from. A sandbox that can raise its own limits can raise its own cost.
How Runtime relates to it
Runtime describes the result, not the mechanism. Each sandbox gets a guaranteed
CPU floor and can burst up to its vcpu count. Memory is the amount you request.
The disk is shared by weight among the sandboxes on a server. Each sandbox gets
at least about 40 MB/s, and up to about 1 GB/s when the others are
idle. This stops one sandbox from swamping a shared drive
(disk, CPU and memory). The
host enforces all of this, along with the network rules. sudo in the guest
cannot reach it (security).
Related: container escape, microVM, Docker vs virtual machine.
Sources
Checked 25 October 2026.
Facts on this page were checked on 25 October 2026.