1. What BoxLite is

BoxLite is the compute substrate for AI agents light enough to embed on your laptop, elastic enough to power an agentic cloud. Each box is a hardware-isolated micro-VM that runs any OCI image and keeps its state across turns.

Figure 1. One engine in two places: the embedded BoxLite runtime starts one micro-VM per box, on your machine or on a cloud runner.

The part that runs each micro-VM is the VMM, the virtual machine monitor. That part is the subject of this series.

2. Why we started on libkrun

libkrun describes itself as "a dynamic library that allows programs to easily acquire the ability to run processes in a partially isolated environment", on KVM (Linux) and HVF (macOS on Apple silicon), behind "a simple C API". That fit BoxLite:

• A library, not a daemon: BoxLite embeds in your app, with no root and no background service.
• One API for KVM on Linux and Hypervisor.framework on macOS.
• The guest kernel comes with it (libkrunfw), along with virtio-fs, virtio-blk and vsock.

libkrun is how BoxLite runs boxes on macOS and Linux today.

3. Why we're replacing it

libkrun is clear about what it isn't: its README lists "Become a generic VMM" and "Be compatible with all kinds of workloads" as non-goals. BoxLite's needs grew past those goals:

• The VM's outcome. libkrun ends the process itself, so the caller gets no exit status, and every start failure comes back as -EINVAL.
• The kernel as a shared library. libkrunfw is loaded with dlopen, and that keeps breaking on some hosts; #1512 lists six such issues.
• Devices. Each directory volume gets its own device, and with three a box fails to start with IrqsExhausted (#935).
• What comes next. Hot-plug mounts, live resizing, memory snapshots for AutoPause (#1003) and GPUs all need a VMM we control.

What we're not doing

• Forking or patching libkrun. It ships unchanged until the new VMM is the default, stays one release as a fallback, and is then removed.
• Building a general-purpose VMM. It runs one VM per process with BoxLite's devices only; confidential computing, live migration and Intel Macs are out of scope.

What it costs

• The new VMM needs macOS 15 or later, for Hypervisor.framework's in-kernel interrupt controller. macOS 1214 keep libkrun until cutover.
• A long road: first boot (M1), then a real box (M2), volumes (M3), hardening (M4) and cutover (M5).

4. How a VMM works, in one screen

Figure 2. Inside one machine. The runtime spawns a jailed boxlite-shim per box, and the VMM inside it runs the micro-VM. PROPOSED marks what this series replaces.

A hypervisor (KVM or Hypervisor.framework) runs guest instructions on the CPU. The VMM is the ordinary process around it: it gives the guest memory, creates vCPUs, loads the kernel and emulates every device. Its heart is one loop:

Figure 3. Run a vCPU until it exits, handle the exit, and run it again.

The first guest our new KVM backend ran was 7 bytes long:

mov dx, 0x3f8   ; COM1 serial port
mov al, 'K'
out dx, al      ; KVM exits to the VMM: port 0x3f8, byte 'K'
hlt

Everything else is detail, and each detail gets a part in this series:

5. The series

Status as of October 11, 2026. A part goes out only after its code merges, so every claim links to a merged PR.

Where we are

• Design and one hypervisor contract for KVM, Hypervisor.framework and, later, Windows
• KVM on x86_64: VMs, memory, the run loop, I/O completion, kicks, boot registers, CPUID and MSRs
• A reproducible build of our pinned Linux 6.12 kernel for x86_64
• M1: first boot on macOS arm64, Linux x86_64 and Linux arm64, checked in CI

Follow along on the RSS feed and in every PR on GitHub.

6. Come build it with us

BoxLite is open source, and so is every step of this VMM. We'd love your help:

• Challenge the design. Read the VMM design doc and tell us where it's wrong.
• Pick up M1 work. #1698 lists the open slices and their dependencies: devices, kernel loaders, the Hypervisor.framework backend, arm64 KVM and three-host CI.
• Ask and discuss. Open a GitHub issue or find us on Discord.

Start with CONTRIBUTING.md. Your first PR asks you to sign our contributor license agreement.

Source: hvtracker.net, Sandboxes & Runtimes, updated 2026-10-03 12:10 UTC.

What the score measures

HVTracker scores open-source AI agent projects on public, checkable signals, and doesn't take vendor claims into account. HVTrust is weighted toward the signals that are hardest to fake: build provenance, signed commits and the OSSF Scorecard. Maintenance and adoption make up the rest.

In other words, it answers one question about a sandbox: can you trust the package you install? That matters more for a sandbox than for most software. A sandbox is the one thing you install specifically to run code you don't trust, and if the package itself is compromised, the isolation it promises doesn't matter. It's usually easier to poison a release than to break a hypervisor.

The other five scored below 60. Scores are recomputed daily, so these will move.

Why BoxLite is first

The gap comes from one signal: BoxLite is the only one of the ten that publishes build provenance. Our npm and PyPI releases carry a signed attestation that links each package to the commit and the CI run that built it, and both registries point back to the repository HVTracker tracks. That earns the full 18 points for identity. Every other sandbox in the category scored 10.8.

It isn't popularity. E2B has six times our GitHub stars and about sixty times our weekly downloads, and adoption is 20% of the score. BoxLite still ranks higher, because the signals that are hardest to fake outweigh it.

Where we lose points

The score isn't perfect, and the breakdown is public. Our OSSF Scorecard is 5.2 out of 10, lower than E2B's 6.9 and OpenShell's 6.5. The checks pulling it down are ones we can fix: pinning CI dependencies by hash, scoping workflow token permissions, signing GitHub releases and adding fuzzing. We're working through them, and the score will show it.

What a score can't tell you

HVTrust is one input, not a verdict. It measures how a project is built and shipped. It doesn't measure whether the isolation boundary holds, and it can't see how you deploy it. When you evaluate a sandbox, ask both questions:

• Does the boundary hold? Does each workload get its own kernel, or share the host's?
• Can you verify what you installed? Is every release traceable to its source and the build that produced it?

HVTracker's data is a public answer to the second question. BoxLite's answer to the first has been the same since its first commit: every box is a real virtual machine with its own Linux kernel, isolated in hardware by KVM on Linux and Hypervisor.framework on macOS. A container shares the host kernel, so a container escape lands in the same kernel as everything else on the machine. Escaping a VM is a different class of attack.

Try it

BoxLite ships as an Apache 2.0 runtime you embed in your own program, with no daemon and no control plane, and as BoxLite Cloud, which runs the same boxes behind an API key. Both share one SDK.

pip install boxlite

import asyncio
import boxlite

async def main():
    async with boxlite.SimpleBox(image="python:slim") as box:
        result = await box.exec("python", "-c", "print(2 + 2)")
        print(result.stdout)  # "4"

asyncio.run(main())

• Source: https://github.com/boxlite-ai/boxlite
• HVTracker profile: https://hvtracker.net/agents/boxlite/
• Questions: Discord, or support@boxlite.ai

BoxLite's first commit, on December 8, 2025, said it in the opening line of the README:

BoxLite is an embeddable virtual machine runtime for secure, isolated execution environments.

It took SQLite as its model ("small, fast, reliable") and defined the property in one line:

Embeddable No daemon, no root, just a library in your application.

Ten months later, the design hasn't changed. Every box is a real virtual machine with its own Linux kernel, isolated in hardware: KVM on Linux, Hypervisor.framework on macOS. The VMM runs as a child of your process. There's nothing else to start.

On a Mac, that means BoxLite lives right on your Mac. There's no Linux VM to host the sandbox, no Docker Desktop and no background service. Your program starts a box, and when your program exits, the box is gone.

What "embedded" means

Postgres runs perfectly well on a single machine, and nobody calls it an embedded database. SQLite is embedded because it lives inside your program. There's no server to start, no port, and nothing to operate when your program isn't running.

We hold the embedded sandbox to the same bar:

• It's a dependency, not a deployment. It goes in your lockfile, not your runbook.
• Nothing runs when nothing is running. There's no daemon, no control plane, no database and no reserved memory.
• It runs where your code runs. It works natively on macOS and Linux, with no VM to host the sandbox host.
• It's the same library everywhere. You use it in unit tests, in CI, in a desktop agent you ship to users, and on a customer's air-gapped server.

Putting a sandbox platform on one machine makes it a smaller deployment, not an embedded one. The test is simple: when your program exits, is anything still running?

Why it matters for agents

Agents don't run in one place. They run on a developer's laptop, inside a test suite, in a CLI someone installed with pip, and inside products that ship to customers who will never run your infrastructure. A sandbox that needs its own servers can follow the agent to only some of those places. A library can follow it everywhere.

Isolation shouldn't be the price of that. Agent-generated code is untrusted code, and a shared-kernel container is a different risk class from a VM. BoxLite gives every box its own kernel, so embedding never means weakening the boundary.

BoxLite and E2B Embed

The term has spread this year. In September 2026, E2B launched E2B Embed, which in its own words "runs the whole E2B stack, every feature included, on a single machine." On that machine you run E2B's API, orchestrator, proxy, dashboard, Postgres, Redis, ClickHouse and a log pipeline. The machine has to be Linux with KVM, and on a Mac that means running it inside a Linux VM.

That's a useful product. It gives a customer a private copy of a hosted platform. By the test above, though, it's a single-node deployment rather than an embedded sandbox. The clearest way to show the difference is to measure it, so we installed both on the same MacBook Air (M4, 16 GB, macOS 26.1) and ran the same workload with 512 MiB sandboxes. Each was installed the way its own documentation describes for a Mac:

• BoxLite: natively, with pip install boxlite.
• E2B Embed: in a Linux VM with nested virtualization, as its README requires on a Mac, using the default docker compose up -d --wait.

The table follows from the two designs:

• Fresh creates. E2B Embed creates a fresh sandbox faster, because its server restores each one from a snapshot of the template. That's what a server is good at.
• Admission control. The failed creates are by design: the node lets three sandboxes start at a time and asks the rest to retry.
• The cost of a server. Everything else in the table is what running a server costs you: the services, the reserved memory, and a network hop on every command.
• Nested virtualization. E2B ran under nested virtualization here, because that's how it runs on a Mac. On bare-metal Linux its numbers will be better.

If you want your customer to run a copy of your cloud, E2B Embed does that. If you want the sandbox inside your product, that's what BoxLite was built for.

Each number is the median (p50) or 95th percentile (p95) of repeated runs: 30 creates, 100 commands and 20 resumes per tool. If you get different numbers, especially on bare-metal Linux, open an issue and we'll update this post.

Two forms, one runtime

BoxLite ships in two forms that share one SDK and one core API:

• BoxLite Open Source is the embedded runtime. It's Apache 2.0, runs in-process, needs no account, and no data leaves the machine.
• BoxLite Cloud runs the same boxes as a hosted service, behind a REST URL and an API key.

Moving between them is a change of endpoint, not a rewrite. When you need a server, we run it for you. You never have to start with one.

pip install boxlite

import asyncio
import boxlite

async def main():
    async with boxlite.SimpleBox(image="python:slim") as box:
        result = await box.exec("python", "-c", "print(2 + 2)")
        print(result.stdout)  # "4"

asyncio.run(main())

• Source: https://github.com/boxlite-ai/boxlite
• Questions: Discord, or support@boxlite.ai

The video is a condensed edit. Build and deployment time varies with your configuration, network conditions, and app complexity.

Play the game

What is BoxLite Cloud?

BoxLite Cloud is the managed cloud for AI agents. With a URL and an API key, your agent gets compute, a filesystem that survives restarts, and a public URL for what it buildsall within a hardware-isolated virtual machine.

You do not manage hosts, image caches, or capacity. Boxes start in about a second, stop when idle, and wake when accessed again.

Cloud uses the same boxlite package as the local runtime. To switch from local execution to Cloud, you change the runtime handle, not the client library.

The prompt

We gave the coding agent this request, with the spelling cleaned up here:

Read https://boxlite.ai/agent.md first, then build a Strike 1945 mobile game with a cross-user scoring leaderboard and a working public URL.

BoxLite Cloud credentials were already available in the agents environment. The linked guide gives the agent instructions for working with BoxLite Cloud.

What happened next

The agent read the 'agent.md' guide, built the game and score API, and deployed the app to a public BoxLite URL. It then checked the game in a browser, including mobile controls and scores submitted from separate sessions.

The run included debugging: browser testing caught a mission-start request bug, which the agent fixed. It also checked duplicate and invalid score submissions and reported that saved scores survived a server restart.

The coding agent handled implementation, testing, and deployment commands. BoxLite Cloud provided the environment where the app ran, the public URL, and the disk holding its score data. The leaderboard was shared server-side state, rather than a score saved only in one players browser.

This demo used one box. Its persistent disk is not a replicated database or a backup, and removing the box removes its data.

Try your own idea

Got your own idea? Tweak the prompt and Build on BoxLite Cloud now. New accounts start with $100 in credits.

Cover description: Build and deploy apps with one prompt to your coding agent.Let BoxLite Cloud handle the infrastructure. Start with $100 in free credits.

Youve been building with your coding agent. The app works on localhost. You want a friend to try it, but theres no link you can send.

So you switch from building features to figuring out hosting: where to run the app, how to start it, and how to make it reachable.

BoxLite Cloud gives your coding agent a managed environment to build and deploy apps, with a public URL you can share. Your agent handles the application setup and deployment; BoxLite manages the underlying infrastructure.

New accounts get $100 in free credits, added automatically. Use them to run your first app and keep improving it. See pricing for usage rates.

Start building on BoxLite

Get your first app online

You can try the suggested app in Quickstart or adapt the prompt to an idea of your own. Both use the same workflow: ask your coding agent to build the app, deploy it to BoxLite Cloud, and return a public URL.

1. Copy the prompt into your coding agent

Sign up, open Quickstart, and copy the starter prompt into your coding agent.

Use it as written to try the suggested app, or change the app description before sending it. Describe what you want to build, who its for, and the main thing it should do. You could turn the starter into a task board for your team, a small CRM, or a game with your own rules and design.

Keep the BoxLite instructions and credentials in place so your agent can deploy the app. For your first attempt, focus on one or two features you can test yourself. Then send the prompt and let your agent start building.

Quickstart creates your API key automatically. The preview hides it, but the copied prompt includes the full keytheres nothing to fill in manually.

Keep your agent open and respond if it asks for permission or needs more information.

2. Open the URL and try the app

Quickstart updates automatically when your app is online. Click Open app, then test its main feature. For a CRM, that might mean creating a contact and checking that it appears in the list.

A successful first deployment means the app is running on BoxLite Cloud, its public URL opens, and its main feature works. If something fails, give the error to your coding agent and ask it to fix it.

You built it. Lets give it a try.

That game you keep tweaking, a tool your team needed, or your very first appwed love to see what youve put online. It doesnt have to be polished; it just needs to work.

Share your apps public URL on X and tag @BoxliteAI, or drop the link in #Show-Your-Agent on our Discord. Wed love to give it a try.

Found a bug along the way? Report it in #bugs on Discord with a few steps to reproduce it.

Once weve verified your working app on BoxLite Cloud or validated your bug report, well follow up and add another $100 in credits to your account so you can keep building. No form neededwell take it from there.

You can also explore the project on GitHub and join the conversation in GitHub Discussions.

Build something today

Dont leave your first app on the someday list. Your $100 in free credits is ready when you sign upput it to work today. Try the starter or describe your own idea, send the prompt, and get your first version online. You can keep improving it once someone has tried it.

Start building today with $100 in free credits

Cover description: BoxLite 0.10.0 gives agents a filesystem that outlives the box, an address the world can reach, and a ceiling that holds under concurrency.

That is one sentence. Look at what it demands.

The agent has to install a toolchain and keep it. It has to write files and still have them an hour later. It has to run a dev server that someone who is not the agent can open in a browser. And it has to do all of that inside limits, because "an agent that provisions compute" and "an agent that provisions compute you pay for" are the same sentence.

In 0.9.7 you could not do that through the API. In 0.10.0 you can. That is the release.

246 commits since 0.9.7, and the three largest areas of change are the API, the infrastructure, and the console not the VM. The runtime was never the bottleneck. Everything an agent needs around the runtime was.

One request, three new capabilities

POST /v1/boxes
{
  "image": "python:3.11-slim",
  "volumes": [{ "managed_volume": "agent-home", "guest_path": "/workspace" }],
  "network": {
    "outbound": { "mode": "enabled", "allow_net": ["api.openai.com"] },
    "inbound":  { "mode": "enabled" }
  }
}

Three lines that were not possible over REST before this release: a managed volume attached by name, an egress allowlist that actually holds, and an inbound switch that makes the box's services publicly reachable.

A filesystem that outlives the box

Managed volumes existed in 0.9.x if you were the internal box-creation path. Over REST they were unreachable, which meant every agent building on the public API rebuilt its world on every run.

Now:

• POST, GET, GET /:id, DELETE on /v1/volumes full lifecycle over REST

• Volumes attach in the same call that creates the box

• Addressed by id or name. managed_volume: "agent-home" and managed_volume: "vol_01K2EXAMPLE" both resolve

• Single-file mounts, for when a directory is the wrong unit

• S3-backed volumes through the same interface

• A volumes console, and a rebuilt create-box dialog

The volume:// scheme is gone. It used to live inside a polymorphic source string, which is a parser nobody meant to write, and the CLI, the SDKs and the wire had all drifted on how to read it. VolumeSpec now carries managed_volume and host_path as separate typed fields. Two typed fields cannot disagree.

This is the half of stop-and-wake that makes it safe to use. A box that stops mid-run loses its disk. A volume does not, and the next box mounts it.

An address the world can reach

"Preview on a public URL" is a networking problem, and it landed here:

• Public box service traffic routes through the API, proxy, runner, and guest-port tunnel path

• Box network tunnels are proxied through the API

• Local TCP port publication with automatic or fixed host ports, surfaced through the box-info APIs across REST, CLI and SDKs

• Tunnel listener forwarding local TCP and Unix listeners on prepared tunnels, a fresh tunnel per accepted client, wire protocol unchanged

Two constraints shipped with it, both on purpose. OCI EXPOSE is metadata, never an instruction that opens a host listener. Remote runtimes stay tunnel-first. Each published listener is bounded at 256 concurrent proxied connections.

And a fix that matters more than its size: a tunnel CONNECT against a stopped box used to drop the stream silently. It now rejects. Silent failure is the most expensive kind in an agent loop, because the agent will retry it forever.

A ceiling that holds under concurrency

Every platform ships quota. Most ship it checked on create, which is where it does the least good.

0.10.0 enforces per-organization ceilings cpu, memory, disk, gpu, plus maximum concurrent boxes on every path that adds or grows usage: create, start, warm-pool assignment, proxy auto-resume, and resize. Warm-pool assignment and auto-resume both add usage without anyone calling create. That is precisely how a "we have quotas" platform ends up with a runaway bill.

Underneath: a Redis pending-reservation using atomic Lua with TTL self-heal, checked against summed box-table usage. A projected total over a ceiling is rejected with a 400 before anything is allocated.

Metering grew up with it. Finalized box usage exports to the commerce service through an outbox, open allocations are snapshotted, and the console now binds Usage to the quota API, quotes box price from published usage rates, and confirms plan changes on a page that shows exactly what is queued.

If you are the person who signs off on an agent platform, this section is the one that matters.

A tighter boundary

Three holes in allow_net enforcement are closed. Each was a case where the policy applied in one direction but not another:

• UDP egress was not covered

• The host alias IP was not covered

• Host checks were bound to the requested destination, not the resolved one

The third is the one to sit with. A hostname that passes the check and then resolves somewhere else was never checked at all.

All three are breaking changes, because traffic that used to escape no longer does. That is the correct direction, and it is worth reading carefully if you were relying on the gap without knowing it. We would rather tell you than let you find out.

Alongside: structured container capability controls, no capability mutation from privileged mode, host sandbox grants separated from guest networking, and a minimal guest rootfs to boot from.

Errors that tell you what to do instead

A small thing that says a lot about where the API is going. Send host port publication to the REST API and you no longer get property ports should not exist. You get:

host port publication is local-only; use the box network tunnel endpoint to reach a guest service

Four implementations of CreateBoxRequest had disagreed about which options a remote caller may set. One let a client switch the sandbox off. One refused nothing. Five fields were validated, audit-logged, and then silently dropped at the mapper. They are now either wired through or refused with a sentence that names the alternative.

Upgrading

0.10.0 earns the middle number. Before you bump:

• auto_pause is now auto_stop, across the whole stack. The field never described a pause the core has no pause operation, and the policy performs a real stop with no memory retention. The old name also collided with BoxStatus::Paused, which is the genuine SIGSTOP freeze taken during clone and export.

• volume:// is removed from the wire. Use managed_volume or host_path.

• The REST API rejects host-only box options instead of dropping them silently.

• allow_net now applies to UDP egress, the host alias IP, and resolved destinations.

• The ssh-gateway is removed.

• Box images move to the v0.1.0 line, relocated under apps/.

• Tunnel half-close is owned by the core, which tolerates a hung-up peer.

Start here

The open-source runtime and the managed Cloud share the same SDK call runs against a box on your laptop or a box on our fleet a URL and an API key is the whole difference.

New accounts start with $100 for BoxLite Cloud in credits: https://app.boxlite.ai

Repo: https://github.com/boxlite-ai/boxlite

Docs: https://docs.boxlite.ai

When you create a box in the console you set three switches: Stop when idle, Wake on access, and Delete after stopping. A stopped box wakes on SDK exec, file operations, or a terminal attach. So the agent's home comes back on demand instead of burning compute while nothing is asking it to work.

That is the pitch, and it holds. But the definition underneath it is narrower than most people assume.

What counts as activity

From the Cloud docs, verbatim:

idle means no SDK, terminal, or preview traffic. Work running inside the box does not count, so a long job can be stopped mid-run.

Read that twice. The idle timer is driven by traffic crossing into the box. A for loop pegging the CPU for forty minutes with nothing calling in is, as far as the lifecycle is concerned, silence.

This is not an oversight. It falls out of what wake-on-access requires. To wake a stopped box you have to be watching something that still exists while the box does not an inbound request, a file operation, a terminal attach. You cannot watch a process inside a VM that is not running. Once the signal has to live at the boundary for wake to work, the same signal is the cheapest thing to reuse for stop. Symmetry, not laziness.

The cost of that symmetry is that internal work is invisible to the thing deciding whether you are done.

Failure mode one: the long job that gets cut

An agent that installs a toolchain, kicks off a build, and then waits is doing exactly the kind of work that looks like nothing from outside. If the idle window is shorter than the build, the box stops mid-run.

Two ways out, and they are not equivalent:

• Set the idle switches deliberately for that box. Long-running work is a per-box decision, not a global default.
• Make a mid-run stop survivable instead of preventing it. Mount a managed volume and write progress to it. A box loses everything on its disk when it is destroyed; a volume does not, and another box can mount it later. A job that checkpoints is a job you are allowed to interrupt.

The second is the more durable answer. Tuning a timeout to be longer than your longest job is a bet you will eventually lose.

Failure mode two: treating it as a budget

The billing docs are blunt about this one:

Treat stop-when-idle as a safety net, not a budget. A busy box is never idle, so stop-when-idle will not cap what it spends.

Idle-stop protects you from the box you forgot. It does nothing about the box that is genuinely in use, because that box is never idle by definition. If a runaway agent is hammering a box in a loop, every one of those calls is traffic, and traffic is the opposite of idle.

Pay-as-you-go is metered per hour across three dimensions: $0.0504 per vCPU-hour, $0.0144 per GiB-hour of memory, and $0.00018 per GiB-hour of disk. The smallest box (1 vCPU, 1 GiB, 10 GiB) comes to $0.0666 an hour. Those rates do not care why the box is up.

The habit the docs recommend is the unglamorous one: remove boxes when the work is done, as part of the task rather than as cleanup you plan to get to later.

What this buys you

The reason to accept a boundary-measured lifecycle is the second shape of box it enables. A disposable box for untrusted code does not need any of this; you create it, run, and remove it. But a persistent home for an agent does. It installs its tools once, writes files, stops, and picks the work back up later instead of rebuilding its world on every run.

Keeping that box up around the clock so it is warm when needed is the naive version, and you pay for every idle hour of it. Stop-and-wake gets you the same continuity without the standing bill, precisely because something at the boundary is still listening while the compute is not.

Design for it explicitly:

• Decide per box whether its work is externally driven or internally driven. Internally driven work needs the idle switches set, not defaulted.
• Put anything you would hate to lose on a volume, not on the box disk.
• Use idle-stop as a backstop for forgotten boxes. Use teardown as your cost control.

The lifecycle is managed. Which things count as life is still your call.

Docs: https://docs.boxlite.ai/cloud