WeEnv: The Environment for Agentic Reinforcement Learning at WeChat

1 Introduction

• Environment initialization takes 53.4% of iteration time with E2B and 39.5% with Docker, while training takes 15.4%–24.0%.With E2B, initialization is 2.6× task execution; with Docker, it is roughly on par.Source: §1 · p. 1
• Dynamic assembly adds about 20 seconds per environment, whereas static bundling requires republishing every artifact containing an updated component.WeEnv publishes components as independently referenced layer groups and composes them into the environment at initialization, avoiding monolithic repackaging.Source: §1 · pp. 1–2
• WeEnv launches environments from layer metadata and fetches contents on demand, then adjusts CPU and memory quotas live from cgroup signals.Its provisioning scales up aggressively and down conservatively, avoids starving admission of new environments, and fails explicitly when a task cannot be served.Source: §1 · p. 2
• 5.6–14.2×: WeEnv reduces median environment initialization over E2B, Docker, and AgentENV, cutting its iteration-time share from up to 53.4% to 9.1%.On-demand fetching launches environments 3.1× faster and shortens end-to-end iterations by 1.35×; elastic provisioning accelerates resource-intensive tasks by up to 45×.Source: §1 · p. 2

2 Background

• Rollouts generate trajectories with the current LLM, while the train phase updates model weights using those trajectories.During task execution, a harness repeatedly invokes the model and tools inside an environment until the task is judged done.Source: §2 · p. 2
• Some tasks use a separate clean environment to evaluate results and compute rewards, preventing rollout-side modifications from contaminating evaluation.This separation guards against reward hacking.Source: §2 · p. 2
• Environments are managed in a separate cluster to isolate concurrent rollouts and keep CPU- and memory-heavy task execution from fragmenting GPU capacity.The environment is commonly instantiated as a virtual machine or container containing task dependencies.Source: §2 · p. 2
• Environment management proceeds through offline packaging into a registry artifact, initialization into a root filesystem and launched instance, and resource provisioning during execution.An artifact may omit components that the tooling installs during initialization.Source: §2 · p. 3

3 Motivation

• The experiments use Slime with Megatron and SGLang, SWE-Smith-Python, Qwen3-8B, and Claude Code across 256 task rollouts.The workload draws 32 unique dataset instances and rolls out each eight times with GRPO.Source: §3 · p. 3

3.1 The Non-negligible Environment Tax

• 53.4% of E2B iteration time goes to initialization, 2.6× task execution; Docker initialization takes 39.5%, roughly matching task execution at 44.0%.Across these backends, rollout accounts for 73.6% of iteration time with E2B and 83.5% with Docker.Source: §3.1 · p. 3

3.2 Environment Packaging

• Dynamic assembly adds about 20 seconds per environment, while static bundling can require up to T × H images and repackaging each affected image after a component update.Updates to harnesses and evaluators can therefore touch many artifacts and lengthen experimentation cycles.Source: §3.2 · pp. 3–4

3.3 Environment Initialization

• 0.81% of an artifact is accessed by the median task and 6.02% at the 99th percentile, while current solutions fetch the complete artifact before initialization.Full-image fetching can transfer over 100× the bytes execution accesses.Source: §3.3 · p. 4

3.4 Environment Provisioning

• Peak CPU demand ranges from about 1 core at the median to 68.3 cores at the 99th percentile; peak memory rises from a 0.15 GiB median to 7.0 GiB at the 99th percentile.A uniform quota sized for the median starves high-demand tasks, while one sized for the tail wastes resources on most tasks.Source: §3.4 · p. 4
• 310.5 s under the smallest quota versus 201.6 s under the largest: a tight quota inflates one resource-intensive task's rollout by 1.5×.The measurements support differentiated rather than uniform resource allocation.Source: §3.4 · p. 5

Packaging

• Conventional layers are bound to complete artifacts, preventing independent publication or composition; evolving components must otherwise be installed at initialization or bundled into many artifacts.Resolving the packaging dilemma requires separately packaging changing components and composing them without time-consuming installation.Source: §4 · p. 5

Initialization

• Conventional layers interleave metadata with contents and use sequential gzip compression, so launching before full arrival and fetching arbitrary byte ranges require a different format.The metadata cannot be recovered without walking the layer, and reading a byte requires decompressing everything before it.Source: §4 · p. 5

Provisioning

• Task resource demands vary sharply across tasks and over time, including abrupt CPU bursts, so early usage does not reliably predict later needs.Ten traced tasks showed varied CPU and memory usage; one task's CPU demand surged about 47× in one second.Source: §4 · p. 5
• WeEnv abandons prediction and adjusts environment resources dynamically during execution, while monitoring usage and avoiding disruption to running tasks or starvation of other environments.The design requires live quota adjustment with negligible disruption and protection against starving other environments.Source: §4 · p. 5

Layer composition

• WeEnv packages components as separately published layer groups and composes them into a complete environment at initialization, so updates republish one group rather than many artifacts.Composition is lightweight, avoiding time-consuming installation.Source: §5 · p. 6

On-demand fetching

• WeEnv launches environments before the complete artifact arrives and fetches contents on demand, using local and peer caches whenever possible.Its layer format separates metadata from contents so metadata can support launch and byte ranges can be fetched independently.Source: §5 · p. 6

Elastic provisioning

• WeEnv starts environments with a small CPU and memory quota, monitors cgroup signals, and adjusts quotas live to match changing resource demands.Its scaling principles include aggressive scale-up, conservative reclaim, and preventing scale-ups from starving later admissions.Source: §5 · p. 6

6.1 Environment Plan and Composition

• Each layer group receives its own reference, and an environment plan lists group references in stacking order; cached mappings resolve references to layer digests.This removes the need to locate a layer through an enclosing image.Source: §6.1 · pp. 6–7
• At initialization, WeEnv concatenates the groups' ordered digest lists and mounts them as a read-only root filesystem, with higher groups overriding lower ones.Composition manipulates metadata and mounts the stack without copying, unpacking, or executing layer contents; the plan assembles the stack at initialization rather than freezing it during packaging.Source: §6.1 · p. 7

6.2 Packaging Guided by Composition

• Packaging boundaries follow change rates: frequently changing components get separate groups, while relatively stable contents are grouped and shared.Harness and evaluator updates republish their own small groups rather than touching all task groups.Source: §6.2 · p. 7
• For tasks sharing a repository, WeEnv packages at repository granularity and applies each task's small mutation dynamically at initialization.For 39,471 SWE-Smith-Python tasks across 131 repositories, mutations complete within a few hundred milliseconds, compared with about 20 seconds to install a harness.Source: §6.2 · p. 7

7 On-demand Fetching

• WeEnv launches environments instantly and fetches artifact contents on demand, supported by a layer format whose metadata and bytes are independently fetchable.The format is designed to permit launch from metadata alone and reads of any byte range without fetching the rest of the layer.Source: §7 · p. 7, §7.2 · p. 8

7.1 Data Flow of On-demand Fetching

• FUSE redirects task reads through envlet and node caches before remote registry fetches; background filling retrieves remaining chunks off the critical path.Writes go to the local writable layer, while partial writes to lower-layer files surface as reads through the on-demand path.Source: §7.1 · pp. 7–8

7.2 Layer Format

• Conventional gzip-compressed tar layers interleave file headers with contents and compress as one sequential stream, preventing metadata-only launch and independent range reads.Recovering metadata requires walking the layer, and reading a byte requires decompressing preceding data.Source: §7.2 · p. 8
• WeEnv stores metadata in a standalone table of contents at the layer tail, enabling metadata retrieval with a size query and small range read.The TOC records each file's path, attributes, and payload byte range; stacking the referenced layers' TOCs yields the root filesystem namespace.Source: §7.2 · p. 8
• In the converted format, each file's payload is stored contiguously, making any requested byte range usable without reading the rest of the layer.The converted layer is published as an ordinary blob, preserving the registry protocol while enabling range reads.Source: §7.2 · p. 8

8.1 Monitoring Usage

• WeEnv monitors CPU and memory through each environment’s cgroup every 200 ms, with reads taking tens of microseconds and using less than 0.1% of one core.Source: §8.1 · p. 8

8.2 Scale Up and Down

• Scale-ups respond to a single pressure sample, doubling quotas under ordinary pressure or quadrupling them under severe pressure.CPU and memory have separate pressure thresholds; scale-down waits for sustained low usage to avoid disrupting execution.Source: §8.2 · p. 8
• Scale-ups are capped and may be preempted to preserve admission capacity for evaluation environments that overlap with executions.The default per-environment maximum is 64 cores and 32 GiB, and a configured share of the node is reserved for admissions.Source: §8.2 · p. 9
• When an OOM emergency persists with no quota tier left, WeEnv terminates the task and reports the cause so the RL framework can resample it.Source: §8.2 · p. 9

9.1 Setups

• The experiments use Slime with Megatron and SGLang, comparing WeEnv against E2B virtual machines, Docker containers, and AgentENV Firecracker virtual machines.Source: §9.1 · p. 9

9.2 Overall Performance

• WeEnv reduces initialization’s iteration-time share from 28.9%–53.4% under the baselines to 9.1%, while task execution accounts for 74.0%.Source: Figure 9 · p. 9, §9.2 · p. 9
• 10.6 s is WeEnv’s median environment initialization time, versus 59.7 s for AgentENV, 111.0 s for Docker, and 150.6 s for E2B.The reported reduction is 5.6–14.2×; WeEnv launches before the complete artifact is fetched, and layer composition avoids harness installation at each initialization.Source: Figure 9 · p. 9, §9.2 · p. 9

9.3 Layer Composition

• WeEnv maintains B+2+H artifacts for B repository-level base images and H harnesses, rather than dynamic assembly’s one image per task or static bundling’s H images per task.Table 1 identifies the packaging-strategy comparison; for SWE-Smith-Python, static bundling requires 39,471H images, while WeEnv maintains 133+H.Source: Table 1 · p. 10, §9.3 · p. 10
• Updating a harness or evaluator republishes one WeEnv layer group, while per-task patches are applied at initialization with a 0.43 s median overhead.Installing a harness takes 20 seconds per initialization.Source: §9.3 · p. 10

9.4 On-demand Fetching

• 10.6 s is the median initialization with on-demand fetching, compared with 32.5 s without it; P95 falls from 83.5 s to 35.1 s.Figure 10(a) presents the initialization-latency CDF; only immediately touched chunks are transferred before launch.Source: Figure 10 · p. 10, §9.4 · p. 10
• 1,845 s falls to 763 s in the first RL iteration with on-demand fetching; across all iterations, total time drops from 8,092 s to 5,988 s.The first-iteration reduction is 2.4×, and the total speedup is 1.35×; Figure 10(b) shows per-iteration end-to-end time.Source: Figure 10 · p. 10, §9.4 · p. 10

9.5 Elastic Resource Provisioning

• 61 task executions save more than 100 s each; the slowest two rollouts fall from the 1,800-s timeout to about 40 s, a 45× reduction.A few executions take longer under elastic provisioning because the agent sampled a different, longer solving trajectory.Source: §9.5 · pp. 10–11
• 8,968 s of total rollout latency under fixed quotas falls to 5,988 s with elastic provisioning, a 1.50× speedup.Iterations 3, 5, and 8 drop from 1,949 s, 1,773 s, and 1,981 s to 542 s, 806 s, and 534 s, respectively, with gains up to 3.7×.Source: Figure 11 · p. 11, §9.5 · p. 11
• In one resource-intensive task, CPU quota rises to 64 cores during evaluation while memory stays at 8 GiB during solving and rises to 32 GiB for evaluation.Figure 12 traces CPU and memory quotas; CPU returns stepwise to 2 cores as a solving burst subsides.Source: Figure 12 · p. 11, §9.5 · p. 11

9.6.1 Harness

• 108 s is WeEnv’s median task time with Codex, versus 260 s for E2B, 228 s for Docker, and 178 s for AgentENV.Median initialization is 13.7 s with WeEnv, versus 87.3 s for AgentENV, 126.8 s for Docker, and 160.2 s for E2B.Source: Figure 13 · p. 11, §9.6.1 · p. 11

9.6.2 Dataset

• WeEnv’s median task times are 66.9 s on Rust, 131.5 s on C++, 78.9 s on Go, and 105.3 s on JavaScript, leading each dataset’s backend comparison.The advantage over the best baseline narrows to 1.2× on compilation-heavy C++, while Rust and Go reach up to 3.4× faster than baselines.Source: §9.6.2 · pp. 11–12, Figure 14 · p. 12

9.6.3 Scaling to Larger Models

• 188 s is WeEnv’s median task time with Qwen3-14B on the eight-server cluster, versus 288 s for E2B, 253 s for Docker, and 207 s for AgentENV.Median initialization is 13.9 s with WeEnv, versus 60.4 s for AgentENV, 108.2 s for Docker, and 150.7 s for E2B; the initialization speedup holds as the model scales.Source: Figure 15 · p. 12, §9.6.3 · p. 12

• Agentic RL frameworks decouple agent programs from trainers, while scheduling systems optimize workflow placement or rollout batching; these systems treat environments as black boxes.WeEnv instead optimizes environment management across the full lifecycle.Source: §10 · p. 12
• Lazy image distribution enables use before a complete image arrives, while snapshot and fork techniques target instances restored from a known, unchanged root filesystem.Because agentic RL tasks each arrive with their own initial state, WeEnv accelerates how the artifact reaches the node.Source: §10 · p. 12

• WeEnv manages the entire lifecycle of the environment for agentic RL.Source: §11 · p. 12
• WeEnv aims to let agentic RL iterations spend time on learning rather than preparing environments.Source: §11 · p. 12
• WeEnv is deployed for agentic RL at WeChat.Source: §11 · p. 12