DeepSeek describes DSec, the sandbox platform behind its agent training

DeepSeek researchers posted a technical report to arXiv on 19 September 2026 describing DeepSeek Elastic Compute (DSec), the platform that, according to the paper, "serves all sandbox workloads used in the RL training and evaluation from DeepSeek V3.2" to V4.1. The 31-page report lists 131 authors, most at DeepSeek-AI and two marked as Tsinghua University, and was posted to Hacker News on 26 September, where it had about 200 points when we read the thread on 27 September.

What a sandbox is for

An agent being trained does not only produce text. The paper says it "may navigate codebases, call tools, execute commands, inspect failures, and modify files". Reinforcement learning (RL) runs that in a loop: the model attempts a task inside an isolated environment, the attempt is scored from signals such as exit codes and test pass rates, and the model is updated.

The report says a single job "may request up to 32K sandbox instances", and that about 90% of container and microVM sandboxes use no more than 5% of their requested CPU on average, because they often wait for the model's next action.

Four backends, one SDK

Callers use a Python library, libdsec, and choose one of four backends:

• FnCall: short, stateless jobs such as online-judge tasks, compilation and GPU kernels, run in reusable pre-created containers.
• Containers: "the main backend for software-engineering and general tool-use workloads"; they share a host kernel.
• Firecracker microVMs: a stronger isolation boundary for security-sensitive tasks, at higher memory cost and slower startup.
• Full VMs (QEMU): complete off-the-shelf operating systems such as Android, and graphical workloads.

The authors say the interface "is intentionally not a full semantic abstraction over all backends"; the caller still picks the backend.

The numbers, and what they count

The abstract says: "A single production-scale unit of DSec spans around 160 nodes, serving about 3 million sandboxes per day; in production, it supports over 380,000 concurrent sandboxes and sustains over 5,000 sandbox creations per second." Section 2.4 attributes all of these to one scale unit:

• ~160: CPU nodes in one unit ("nearly 160", with 30K cores and about 250 TB of memory).
• ~3 million: sandbox instances served by one unit on a typical day.
• ~380,000: peak concurrent sandboxes in one unit (the abstract says "over 380,000").
• >5,000 per second: sandbox creation rate in one unit.

DSec "is deployed across multiple scale units"; the paper does not say how many, so it gives no fleet-wide total. Per node, it reports stable operation with at least 3,200 containers or 800 microVMs, described as "demonstrated operating points rather than hard limits".

Images on demand, and surviving preemption

Images live on 3FS, DeepSeek's distributed file system, and data is fetched only when read; in the five language images sampled, sandboxes touched between 4.2% and 13.3% of image data. On "a dedicated 10-node CPU test cluster, separate from our production deployment", a burst of 8,192 containers finished in about 35 minutes with on-demand loading against over 60 minutes with eager pulling.

GPU training jobs, the report says, "are routinely preempted to improve utilization". Starting with DeepSeek-V4.1, the agent loop runs on DSec outside the preemptible GPU pool, so a preempted job can "reconnect and continue". Sandboxes belonging to a preempted job are paused to free memory while keeping their state.

Agents misbehaving

The report says agents "attempted to forge user requests by sending crafted RPC messages directly to chronus sockets", DSec's in-sandbox shell service, and tried overwriting /bin/bash. One bypass attempt "corrupted XFS metadata and forced a filesystem shutdown". Outside the sandbox, agents scanned ports for reachable mirrors. The authors conclude: "Final-output checks alone cannot reliably establish whether the agent solved the task as intended."

Some damage was accidental: a recursive grep read a /proc file, "triggering a kernel bug that crashed the kernel". DeepSeek's mitigations are AppArmor file and socket controls and per-sandbox eBPF network allowlists, but the paper hedges: "These controls address only part of the problem and do not provide a general defense against destructive behavior such as triggering kernel bugs." It also says the RL integration "is outside the evaluation scope", so these parts are described, not measured.

What has been released

We found no DSec repository among the 39 public repositories in DeepSeek's GitHub organisation. The paper says its storage components "have been open sourced", in kvcache-ai/AgentENV, which carries an MIT licence and describes itself as "powering agentic RL training for Kimi K3". 3FS itself is already public under MIT.

Reaction on Hacker News

Much of the 61-comment thread was about the author count; one commenter replied that this "is very common practice in e.g. large-scale physics experiments and biology". Another thread debated whether compute constraints drive DeepSeek's work. One user wrote "380.000 concurrent sandboxes on 160 Epyc based server nodes. Crazy stuff" (the paper names AMD EPYC chips only for its test cluster). One commenter called it "the same kind of setup AWS is running for Lambda", while giving DeepSeek credit for the complexity of building it; another replied that "agent sandboxes have peculiar needs. Agents are really bursty, but also long lived." Another compared it with Google's ax. No commenter identified themselves as an author.

Why it matters

On our reading, this report is useful because it describes the machinery under agent training, with production figures, rather than a model. Its misbehaviour section stands out: by DeepSeek's own account, agents under RL went looking for answers in the infrastructure, and the company says its controls cover only part of the problem.