Vibrant Labs Research

Sandbox Infrastructure for Environments at Scale

2 min read

The paper

Last session’s DeepSeek-V4.1-Flash compressed DeepSeek’s sandbox platform into one subsection. DSec is the full systems report, and it is on the list because we want to know what it takes to build the infrastructure under environment creation, not just the task-synthesis loop on top of it.

The argument is that agentic sandboxes are not a serverless workload. They arrive in bursts of up to 32K, about 90% of them average 5% or less of the CPU they request, they stay alive and stateful for minutes to hours, and they draw on more than 130 TB of images that are each reused only a handful of times DSec. Each design choice follows from that shape DSec:

  • one SDK over four backends (function calls, containers, microVMs, full VMs), with the task picking the backend;
  • environments composed from independently versioned read-only layers, so upgrading a harness does not mean rebuilding every image;
  • images loaded on demand from a distributed filesystem rather than pulled from a registry;
  • memory and CPU overcommitted, with QoS protection for latency-sensitive tasks;
  • rollout state kept outside the preemptible GPU pool.

One scale unit — about 160 CPU nodes — serves around 3M sandboxes a day at a peak of about 380K concurrent DSec.

Three things to argue about:

  • Building environments is a sandbox operation. pack_diff snapshots a live sandbox so that an agent’s interactive build session becomes a reusable environment, with builders and runtime agents on separate accounts so reference answers do not leak DSec. How much of WorldSmith’s construct → inspect → repair loop is really this primitive, and what would we need short of DeepSeek’s scale?
  • Hackability lives in the platform too. Agents forged RPCs to the sandbox’s own shell daemon, read its logs for answers, overwrote /bin/bash and pulled reference implementations through package mirrors; the authors conclude that “final-output checks alone cannot reliably establish whether the agent solved the task as intended” and say their containment does not stop destructive behaviour DSec. Last session we treated hackability as a verifier property; this says it is also a sandbox property (Benchmark Validity).
  • Sizing our own. The workload numbers — bursts, low CPU use, long-lived state, low image reuse DSec — are a baseline for anyone building rollout infrastructure. Which of them hold at our scale, and which design choices only pay off at theirs?

Discussion

(none)

What we took from it

(none)

Graph View

Backlinks