DeepSeek's DSec paper describes sandbox infrastructure running 3 million agent environments a day

The problem DSec targets

Training and evaluating large language models as agents — having them read repositories, call tools, execute commands and interact with task-specific services — depends on isolated execution environments that keep state across long interactions. According to the arXiv paper, which was submitted on September 19, 2026 and reached Hacker News's front page about a week later, these workloads spawn sandboxes in sudden bursts, span a wide range of isolation requirements, and draw on large image libraries where reuse is limited. The authors' conclusion is that no single sandbox runtime can serve this mix, so the execution platform itself has to be elastic.

One SDK, four backends

DSec exposes four sandbox backends — FnCall, containers, microVMs and full VMs — through a unified SDK, letting each workload pick its own isolation-versus-overhead tradeoff. A cluster-level layer coordinates placement and lifecycle management across nodes. Environments are assembled from independently versioned layers, so common software stacks can be shared rather than duplicated inside every sandbox. Density comes from combining memory sharing, memory reclamation and CPU scheduling, while image data is loaded on demand from 3FS, DeepSeek's cluster-wide distributed filesystem, instead of being staged in advance on every machine.

Co-designed with reinforcement learning

The platform was built alongside DeepSeek's reinforcement learning framework rather than as a generic compute service. Stateful rollout execution, where agents act inside their sandboxes, is decoupled from preemptible GPU training jobs. Sandbox lifecycle is coordinated with the training loop so that rollout state is preserved while idle resources are reclaimed for other work. The paper also reports that this design helps mitigate agent misbehavior such as reward hacking, the failure mode where an agent games its reward signal instead of doing the intended task.

The production numbers

A single production-scale unit of DSec spans roughly 160 nodes and serves about 3 million sandboxes per day, according to the paper. At peak it supports more than 380,000 concurrent sandboxes and sustains over 5,000 sandbox creations per second. These are self-reported deployment figures; the Hacker News item points to the arXiv abstract, which claims the platform's mechanisms cut environment-setup and image-distribution overhead, improve memory efficiency, and keep latency-sensitive workloads performing acceptably under high-density overcommit.

Why it matters

Agentic reinforcement learning is moving toward the center of LLM development, and DSec offers a rare, concrete account of what the supporting infrastructure looks like at production scale. The compute story for agents is no longer only about GPUs — the environments they act in form a first-class, CPU- and memory-heavy layer of the stack.

Several of the design ideas transfer directly to smaller systems. Composing environments from independently versioned layers, fetching image data on demand from shared storage, and tying sandbox lifecycle to the training loop are all patterns that apply to agent evaluation harnesses, coding-agent test beds and RL environment servers. The reported scale — hundreds of thousands of concurrent sandboxes from a 160-node unit — also sets a reference point for what serious agentic training demands beyond the GPU fleet. And the mention of reward hacking is a reminder that infrastructure-level containment is becoming part of the safety story as agents gain the ability to run arbitrary commands.