AgentENV: What Kimi K3's Self-Hosted E2B-Compatible Sandbox Really Costs on Owned Hardware

One always-on E2B sandbox costs about the same as an entire dedicated server. E2B's default sandbox — 2 vCPUs, 4 GiB of RAM — meters at roughly $0.166 per hour, which is about $121 a month if it never sleeps. A Hetzner AX42 with 8 cores, 64 GB of ECC RAM, and two NVMe drives rents for €97.30 a month. The box pays for itself at something like 600–700 sandbox-hours a month, at any recent exchange rate — and then every sandbox-hour past that is nearly free.

That arithmetic is the whole reason kvcache-ai's AgentENV matters. Open-sourced alongside Kimi K3 in late July 2026, AgentENV is a distributed, self-hosted sandbox runtime that runs each agent environment as a Firecracker microVM — and exposes an E2B-compatible HTTP API, so the official E2B SDKs work against your own gateway without code changes. It is the off-ramp from the per-second sandbox meter for teams whose agents already speak E2B.

This post gives that move a concrete accounting: what AgentENV is and what it demonstrably does at K3 scale, what the E2B-compatible lever really buys you, the cost math across three representative workloads, everything the move shifts onto your plate, and where AgentENV's reinforcement-learning lineage shows through in day-to-day ergonomics.

What AgentENV actually is​

Strip away the launch announcement and AgentENV is five mechanisms composed into one runtime:

1. One Firecracker microVM per sandbox. Every agent environment gets its own guest kernel, filesystem, processes, and network stack. Isolation is kernel-level, not container-level — the same boundary E2B itself uses.
2. OCI images become reusable templates. You aenv pull a Docker image or aenv build a Dockerfile into a template, then start sandboxes from it. Base layers load on demand via overlaybd, and local disk acts as a bounded cache that retains hot data and evicts cold — so the aggregate image footprint can exceed any single host's disk by orders of magnitude without pre-warming every machine.
3. Snapshot-backed lifecycle in milliseconds. The project claims snapshot-backed environments boot or resume in under 50 ms and pause in under 100 ms, with incremental memory-plus-filesystem snapshots completing in under 100 ms even under heavy disk modification. A paused sandbox releases its CPU and memory and returns when new work arrives.
4. Fork one sandbox into many. A running environment snapshots into independent children for parallel agent workflows — the launch coverage describes up to 16 children on the same node.
5. Durable snapshots outside the host. Snapshots persist to S3-compatible object storage or a shared distributed filesystem, so a dead node does not take checkpoints with it.

The Kimi K3 production numbers are what make these claims worth taking seriously: 51,219,741 sandboxes created across 1,505,678 images during K3's training and evaluation, with 133 ms checkpoints and 49 ms resumes measured in that fleet. Two details from the K3 writeup deserve attention. First, a sandbox spends up to 98% of its lifetime waiting on model inference — which is why the entire design is pause-first: idle environments must cost nothing. Second, memory ballooning plus a shared host page cache delivered a 9.6x memory overcommit ratio in production, as long-running environments diverged. Both numbers come from K3's homogeneous RL fleet, so treat them as ceilings to reproduce in your own benchmark, not guarantees — fork and snapshot latency in particular depends on guest memory size and storage speed. But they are measured ceilings, not slideware.

Architecturally it is a small system: an Axum HTTP API in front, an orchestrator managing sandbox lifecycle, Firecracker VMs on a layered overlaybd-plus-ublk block device, and an envd daemon inside each guest handling command execution, file operations, and health reporting. The prerequisites are refreshingly honest: Linux kernel 6.8 or newer and /dev/kvm access. On dedicated hardware that is a non-issue; on cloud VMs it means checking for nested virtualization first.

The adoption lever: your E2B code works unchanged​

AgentENV's deliberate growth hack is API compatibility. The runtime implements the E2B HTTP API, so existing E2B SDK code runs against your own gateway without modification — you repoint the endpoint and keep your agent code. For a team already paying E2B's meter, that collapses a migration that would normally mean rewriting every sandbox call site into an afternoon's work: stand up the gateway, point the SDKs at it, compare behavior, cut over.

Two honest caveats come with the lever. First, AgentENV authenticates API requests with a key but does not encrypt traffic — TLS termination and ideally an auth proxy in front are not optional in production, and the install guides say plainly to run it only on trusted networks otherwise. Second, the E2B-compatible secure-sandbox path was still being hardened in public review after launch, with maintainers pushing back on token trust-boundary handling before it merged. That is normal for a weeks-old open-source runtime, but it means you should verify the exact SDK surface you use against your pinned version rather than assuming byte-identical E2B semantics on day one.

The cost math: three workloads, one table​

E2B's published rates are $0.000014 per vCPU-second and $0.0000045 per GiB-second, storage included free. Sandboxes top out at 8 vCPUs and 8 GiB, sessions run to 24 hours on Pro, and everything is CPU-only — there are no GPU sandboxes. The plan ladder is Hobby at $0 (20 concurrent sandboxes, 1-hour sessions, $100 in one-time credits), Pro at $150 a month (100 concurrent), and Enterprise with a $3,000 monthly minimum.

Converted to sandbox-hours, the meter reads:

Now put three representative teams next to one €97.30/month AX42 (8C/16T, 64 GB ECC, 2×512 GB NVMe, unmetered gigabit):

Read the table left to right and the story is clean. Under a few hundred sandbox-hours a month, E2B wins outright — the meter is cheaper than any box, and Hobby's free tier covers the side project entirely. Past roughly 600–700 default-sandbox-hours a month, one dedicated box breaks even, and the eval harness at nearly 6,000 hours costs more than ten times as much on the meter as on owned hardware. Sandbox size moves the breakeven proportionally: small sandboxes halve E2B's hourly rate and double the hours needed to justify a box; large sandboxes do the reverse.

Pause discipline is the sensitivity knob on both sides. AgentENV's design assumes K3's profile — sandboxes idle 98% of the time, paused to zero — and E2B likewise stops the meter on paused sandboxes. A team that pauses aggressively narrows the gap; a team running long-lived interactive sessions widens it. The table above assumes running hours are billed hours, which flatters neither side.

One more honest input to the math: the setup fee (€49 on the AX42), a floating IP if you need one, and whatever object storage your snapshots land in. None of them change which row wins. What can change it is concurrency: if your burst needs exceed one box, the owned column steps to two boxes while E2B's meter stays smooth — which is exactly why the next section's density math matters.

What moves onto your plate​

The meter disappears; the work does not. Here is the concrete checklist, with sizing:

• Template registry ops. Templates are your new base-image supply chain: aenv pull and aenv build pipelines, versioning, garbage collection of stale templates, and overlaybd layer distribution. The bounded-cache design means you do not pre-warm every host, but somebody owns the registry's availability.
• Snapshot storage. Incremental snapshots are small individually and enormous in aggregate — K3 produced 51 million of them. Budget S3-compatible object storage (or a shared filesystem) with lifecycle rules from day one, and measure bytes-per-sandbox-week for your workload before sizing.
• Gateway HA and TLS. The single-node quickstart is one systemd unit on one machine. Production wants the gateway behind TLS termination and an auth proxy, with a second node and a plan for orchestrator failover. AgentENV's no-built-in-encryption posture makes this your explicit design task, not a default you inherit.
• KVM capacity planning. On the AX42, 16 threads and 64 GB give you roughly 8 concurrent active default sandboxes before threads bind (RAM allows ~14 after host overhead) — plus hundreds of paused ones at near-zero cost. The bigger AX162 (48 EPYC cores, 128 GB, €612.30/month) flips the bind: RAM caps you near 28–30 active default sandboxes. Treat K3's 9.6x memory overcommit as an RL-fleet ceiling; heterogeneous interactive sandboxes share less page cache, so plan active capacity on provisioned RAM and let overcommit be upside.
• Node images. Kernel 6.8+, /dev/kvm, Firecracker binaries, and the jailer/seccomp posture you want for untrusted tenant code. On a Cluster API fleet this is a machine-image build pipeline with a tested upgrade path, not a one-time install script.
• Runbook. Upgrades of the runtime itself, snapshot restore drills, noisy-neighbor policy for shared hosts, and per-tenant usage accounting to replace the bill you stopped getting. E2B's invoice was also your usage dashboard; self-hosting means building the small version of that yourself.

None of this is exotic — it is standard small-fleet platform work. But it is real, and it is the actual price of the rows in the table above. If your team has no one who will own a machine-image pipeline and an object-storage bucket, stay on the meter until you do.

Where the RL-training lineage shows​

AgentENV was built to run 51 million similar environments for RL rollouts, and the ergonomics show it — mostly as strengths. Fork-one-into-sixteen on the same node is a rollout-parallelism primitive that interactive agent teams rarely get from sandbox runtimes. The pause-first lifecycle, the S3-backed incremental snapshots, the overlaybd layer sharing across 1.5 million images: every one of these is a throughput-of-similar-envs optimization that happens to serve bursty agent fleets beautifully.

The chafing points are where interactive use diverges from training use. Homogeneous RL envs share enormous page cache; ten engineers' heterogeneous dev sandboxes share far less, so your overcommit will undershoot K3's 9.6x. Training fleets tolerate CLI-and-CRD ergonomics; product teams want dashboards, per-tenant quotas, and the usage accounting E2B's console gives them for free. And the E2B-compat surface, as noted, is young — verify, don't assume.

Positioning-wise, AgentENV claims a slot that has been conspicuously empty. One engineer's six-month survey of the space concluded that every agent-sandbox project is either a managed cloud you cannot self-host or a single-node runtime you cannot scale past one machine. Microsandbox owns the single-node corner well (sub-200 ms boot, MCP integration, laptop-scale friendly); Beam offers an open-source core but with container/gVisor isolation rather than microVMs; boxxkite and containarium round out the self-hostable shortlist. AgentENV is the first credible entry that is both distributed across machines and genuinely self-hostable with kernel-level isolation — with a drop-in E2B API as the migration path. That combination is why it is worth the ops checklist above rather than just another runtime to watch.

Verdict: who should switch, who shouldn't​

If your agents already speak E2B and you burn past ~700 default-sandbox-hours a month with someone to own a small fleet, AgentENV is the cheapest serious infrastructure move available to you: one dedicated box replaces a four-figure meter, and the SDK compatibility makes the migration reversible — the rollback plan is repointing the endpoint. Start with the eval harness or staging sandboxes, measure your real pause ratio and bytes-per-sandbox-week, then move production.

If you are under a few hundred sandbox-hours, have no fleet owner, or need E2B's console, quotas, and support contract more than you need the savings, stay put. The meter is the right price for not operating things, and Hobby's free tier plus $100 in credits is a long runway.

Either way, the direction is set: the sandbox runtime is becoming open infrastructure, and the per-second meter is becoming a choice rather than a tax. Kimi K3 needed 51 million sandboxes and built the runtime to match; the rest of us just get to run it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.