What is a hypervisor?
A hypervisor is software that runs virtual machines, giving each guest its own virtual CPUs and memory isolated by the processor's hardware.
Runtime puts a hypervisor boundary around every sandbox and charges only for the CPU the sandbox actually uses: $0.025 per active vCPU-hour, plus $0.0075 per reserved GiB-hour of memory, with no plan fee (pricing). Each sandbox is a Firecracker microVM on KVM, the hypervisor in the Linux kernel.
What does a hypervisor do?
A hypervisor lets several operating systems share one physical machine while each believes it has a machine of its own. It uses the processor's virtualization extensions (Intel VT or AMD-V on x86) so guest instructions run directly on the real CPU, and it steps in when a guest touches something it must not reach directly, such as a device or another guest's memory.
On Linux the hypervisor role is usually split in two:
- The kernel part. KVM is "a full virtualization solution for Linux on x86 hardware containing virtualization extensions", shipped as kernel modules. It owns the vCPUs and guest memory mappings.
- The user-space part. A virtual machine monitor such as QEMU or Firecracker asks KVM for a VM, then emulates the devices the guest sees.
QEMU's documentation names the hypervisors it can sit on: "KVM, Xen or Hypervisor.Framework". Cloud Hypervisor runs on KVM and on Microsoft's MSHV.
Hypervisor, VMM and emulator compared
| Term | What it is | Example |
|---|---|---|
| Hypervisor | Runs guests on virtualization hardware | KVM, Xen, Hyper-V (MSHV) |
| VMM | User-space program that drives the hypervisor | Firecracker, Cloud Hypervisor |
| Emulator | Imitates a CPU in software, no hardware help | QEMU user mode, which "always" emulates the CPU |
| Container | Host processes fenced by the host kernel | Docker, which shares the kernel |
In common usage "hypervisor" often names the whole stack, KVM plus its monitor. Cloud Hypervisor, for example, is a VMM with "hypervisor" in its name.
Why a hypervisor matters for AI agent sandboxes
An agent installs packages, runs model-written code and may be steered by a prompt injection. Under a hypervisor that code gets its own guest kernel. Reaching the host means breaking the guest kernel and then the hypervisor and its monitor, instead of one bug in a shared kernel, which is the usual path of a container escape. Docker's own documentation states that containers share the host's kernel and a VM has its own.
How Runtime relates to it
Runtime operates the hypervisor hosts: dedicated servers running a Firecracker microVM per sandbox. You never configure the hypervisor. Inside the guest you are root, and root still cannot change network rules, CPU, memory, leases or billing, all enforced on the host (security).
Related: KVM, microVM, Docker vs virtual machine, Cloud Hypervisor vs Firecracker.
Sources
Checked 25 September 2026.
Facts on this page were checked on 25 September 2026.