AgentENV: Kimi’s Open-Source Sandbox System for Agentic RL Training

Moonshot AI's Kimi team and kvcache-ai have open-sourced AgentENV (AENV), the distributed sandbox platform behind the agentic reinforcement learning training for Kimi K3, their 2.8-trillion-parameter Mixture-of-Experts model. Released under an MIT license, AgentENV runs each agent environment inside a Firecracker microVM rather than a shared container, targeting the isolation-versus-speed trade-off that makes large-scale agentic RL expensive. Snapshot, fork, and resume operations are measured in tens of milliseconds, and the system exposes an E2B-compatible API so existing agent codebases can point to a self-hosted server without modification.

What happened

Detail	Fact
Project name	AgentENV (AENV)
Released by	Moonshot AI (Kimi team) and kvcache-ai
License	MIT
Model it powered	Kimi K3 (2.8T-parameter Mixture-of-Experts)
Sandbox technology	Firecracker microVMs
Boot / resume time	Under 50 ms
Pause / snapshot time	Under 100 ms
Max fork children per node	16 independent sandboxes
Minimum host kernel	Linux 6.8+ with /dev/kvm access
Recommended network (shared storage)	10 Gbps or faster

Agentic reinforcement learning (RL) trains a model by having it actually execute actions inside a real computer environment rather than just generating text. Each training rollout needs an isolated Linux environment with its own filesystem, network stack, and running processes. That requirement has historically forced a choice between containers (fast but sharing the host kernel) and full VMs (properly isolated but slow to boot and memory-hungry at rest). AgentENV is built specifically to close that gap.

How the architecture works

Each sandbox is a Firecracker microVM with its own Linux kernel, filesystem, and network namespace. Incoming requests hit an Axum HTTP API, which passes them to an orchestrator managing sandbox lifecycle. Inside each VM, a daemon called envd handles command execution, file operations, and health reporting on port 49983. A reverse proxy routes HTTP and WebSocket traffic from clients to services running inside the VM.

Storage uses a ublk userspace block device backed by overlaybd layered images. Read-only base layers are shared across sandboxes; each sandbox writes into its own upper layer. This lets nodes serve images on demand from a bounded local disk cache without pre-warming every image or holding a full copy of every snapshot cluster-wide.

Snapshot, pause, resume, and fork

These four operations are the core reason the project exists. AgentENV captures snapshots incrementally rather than writing a full image each time. Boot or resume from a snapshot takes under 50 ms. Pausing takes under 100 ms. Incremental snapshot capture finishes in under 100 ms even under heavy disk modification.

Fork is the feature most specific to RL workflows. A running sandbox can clone into up to 16 independent child sandboxes on the same node. The source pauses briefly during capture, then resumes. Every child inherits the exact filesystem, memory state, and resource configuration of the parent. The practical result: install dependencies and reach a task state once, then branch that exact state into parallel rollouts. Snapshots persist to S3-compatible object storage or a shared distributed filesystem.

Two density mechanisms help sustain high sandbox counts on a single host. The host page cache is shared across storage and memory-snapshot data. Memory ballooning returns reclaimable guest memory to the host as environments diverge over time, enabling overcommit.

E2B compatibility and deployment options

AgentENV exposes an E2B-compatible HTTP API. Teams already running agents on E2B can self-host by pointing the E2B_API_URL environment variable at their own server. The official E2B Python and TypeScript SDKs work without any code changes. A native aenv CLI is also available for AgentENV-specific workflows.

Five deployment paths are documented:

1. An install script that runs the server as a systemd service (requires Ubuntu 24.04)
2. A Docker image at ghcr.io/kvcache-ai/aenv-server
3. A Docker Compose stack simulating a multi-node cluster
4. Kubernetes manifests with a gateway, scheduler, and node DaemonSet
5. Build from source using the Rust toolchain

Multi-node deployments add a gateway on port 8080 and a scheduler on port 9090. The multi-node control plane is documented as a prototype. The server is Linux-only because it requires KVM; the CLI supports Linux and macOS on x86_64 and arm64.

Why it matters

The quality of an agentic AI model is directly tied to the quality and scale of its training environments. Slow or leaky sandboxes mean fewer rollouts per hour and noisier training signal. By releasing the infrastructure that trained Kimi K3, Moonshot is giving other labs and researchers a credible starting point for their own agentic RL pipelines rather than forcing everyone to rebuild this from scratch. You can read more about Kimi K3’s open-weights release and what the 2.8T parameter model means for the field.

The E2B-compatible API is a smart distribution move. Many agent frameworks already target E2B’s sandbox interface. AgentENV becoming a drop-in self-hosted alternative lowers the switching cost to near zero for teams that want on-premise control over their execution environment.

Our take

The engineering here is genuinely careful. Sharing read-only base layers, on-demand image loading, and memory ballooning together address the real operational cost of running thousands of ephemeral VMs. The fork-to-16-children limit is specific enough to plan around, and sub-50 ms resume times are fast enough for tight training loops.

That said, the multi-node control plane being marked as a prototype is worth flagging for anyone thinking about production use. The 10 Gbps network recommendation for shared storage is also a real infrastructure ask for smaller teams. For businesses exploring AI integration on their own infrastructure, this release is worth watching but probably not worth adopting until the multi-node path matures.

The MIT license removes any licensing friction, which matters. Expect forks and hosted versions to appear quickly.

What to do about it

1. Check whether your agent framework already targets the E2B API. If it does, self-hosting AgentENV is a minimal code change.
2. Confirm your host kernel is 6.8 or newer and that /dev/kvm access is available before attempting setup.
3. Start with the Docker Compose path to test locally before committing to a Kubernetes deployment.
4. Set shared storage bandwidth to at least 1 Gbps (10 Gbps strongly recommended) before running multi-node workloads.
5. Watch the GitHub repository for updates to the multi-node prototype before using it in a production training pipeline.

If you are building agentic workflows and want to understand whether infrastructure like this fits your stack, talk to the Lumien team.

Source: Marktechpost