· via Hacker News – Front Page (native)
BoxLite is replacing libkrun with a from-scratch VMM for its AI agent micro-VMs
BoxLite, which runs each AI agent in its own micro-VM, is dropping libkrun in favour of a virtual machine monitor it is writing itself — with the build documented in public as each change merges.

What happened
The team behind BoxLite — a runtime that gives each AI agent its own micro-VM — has announced it is dropping libkrun, the library that currently creates those virtual machines, and writing its own virtual machine monitor (VMM) from scratch. In a post on the BoxLite engineering blog that reached the Hacker News front page on October 12, 2026, the team says the rewrite will be carried out in public, with each installment of a planned series published only after its code has merged.
Why libkrun no longer fits
According to the post, libkrun was chosen initially because it is a library rather than a daemon — BoxLite embeds directly in an application, with no root privileges and no background service — and because it exposes a single API over KVM on Linux and Hypervisor.framework on macOS, bundling a guest kernel plus virtio-fs, virtio-blk and vsock support.
The trouble is that libkrun explicitly disclaims the goals BoxLite now needs: its README rules out becoming a general-purpose VMM or supporting every kind of workload. The BoxLite team describes several concrete failures that followed:
- When a VM finishes, libkrun ends the process itself, so the caller never receives an exit status, and every start failure is reported as -EINVAL.
- The guest kernel ships as a shared library loaded with dlopen, which the team says keeps breaking on some hosts; the post points to an upstream issue listing six such cases.
- Every directory volume becomes its own device, and a third volume makes a box fail to start with an IRQ-exhaustion error.
- Planned features — hot-plug mounts, live resizing, memory snapshots for the AutoPause feature, and GPU support — all require a VMM the team controls.
Notably, the team says it will not fork or patch libkrun. The library ships unchanged until the new VMM becomes the default, stays in place for one release as a fallback, and is then deleted. The replacement is deliberately narrow: one VM per process, with BoxLite's devices only. Confidential computing, live migration and Intel Macs are all out of scope.
The first guest was seven bytes long
The post doubles as a primer on VMM internals. A hypervisor such as KVM or Hypervisor.framework runs guest instructions on the CPU; the VMM is an ordinary process around it that allocates guest memory, creates vCPUs, loads the kernel and emulates devices. Its core is a loop: run a vCPU until it exits, handle the exit, then run it again.
The first guest the new KVM backend executed was a seven-byte program that writes the letter K to the COM1 serial port and halts — a minimal test proving the exit-handling path works.
As of October 11, 2026, the project reports a unified exit contract spanning KVM, Hypervisor.framework and, eventually, Windows; a working x86_64 KVM backend covering VMs, memory, the run loop, I/O completion, boot registers, CPUID and MSRs; and a reproducible build of a pinned Linux 6.12 kernel for x86_64. The next milestone, M1, is a first boot on macOS arm64, Linux x86_64 and Linux arm64, verified in CI.
One cost of the move: the new VMM requires macOS 15 or later, because it relies on Hypervisor.framework's in-kernel interrupt controller. Machines on macOS 12 through 14 keep libkrun until the cutover.
The roadmap after that runs from a first real box (M2) and volumes (M3) through hardening (M4) and the final cutover (M5), with later work on memory snapshots, hot-plug mounts, GPUs and a custom network stack. The planned series covers memory layout, the exit contract, safely stopping a vCPU, x86 CPU state, boot, and devices — starting with simple ones like serial, RTC and reset before building virtio from scratch, and finishing with a measured comparison against libkrun before removing it.
Everything is open source, and the team is inviting contributions: challenging the design document, picking up open M1 work such as kernel loaders, the Hypervisor.framework backend, arm64 KVM and three-host CI, or discussing on GitHub and Discord. First-time contributors sign a contributor licence agreement.
Why it matters
Running untrusted, model-generated code safely is one of the defining infrastructure problems of the AI-agent era, and micro-VMs are among the strongest isolation primitives available. BoxLite's decision illustrates the trade-off between reusing mature infrastructure and owning the layer your product depends on: the team hit hard limits — missing exit codes, IRQ exhaustion, fragile kernel loading — that upstream's stated non-goals meant would not be fixed for them. For the wider developer community, the public, PR-by-PR format turns an internal rewrite into a rare, auditable walkthrough of how virtual machine monitors actually work, from a seven-byte first guest up to virtio devices, with code anyone can read, run and contribute to.
- #virtualization
- #libkrun
- #ai-agents
- #open-source
- #kvm