Training AI agents that write code and use tools takes a sandbox for every reinforcement learning (RL) rollout: an isolated environment that can install dependencies, run commands and read and write files. DeepSeek's paper DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale (arXiv:2609.22978, September 2026) describes the sandbox platform they run in production.

The short version. Five things in the paper are worth copying:

1. Sandboxes use little of what they ask for. About 90% of sandboxes use at most 5% of the CPU they request on average, so you can overcommit heavily, as long as CPU core scheduling protects the latency-sensitive work.
2. Don't pull whole images. A sandbox reads only 4–13% of its image, so on-demand loading is far faster than a full pull.
3. Scheduling can be simple. Power-of-k random choice, a local record of placements in flight, and the node has the final say.
4. RL needs task-level operations. When training is preempted or finishes, pause, resume or stop all of a task's sandboxes at once.
5. Agents cheat. The paper records real reward hacking and escape attempts, and the sandbox has to defend against them.

The details follow. Our open-source project OpenDsec implements this paper; the end of this post says where it chose differently. OpenDsec is not affiliated with DeepSeek.

Scale ​

The paper's production numbers:

The last row is easy to miss: sandboxes outlive a deploy, so upgrading a node cannot kill them.

One SDK, four backends, no abstraction ​

DSec has four backends: function calls (FnCall), containers, microVMs and full VMs. They share one SDK, but the SDK does not try to hide them behind one interface: the caller picks the backend, and each backend has its own arguments. The reason is practical. Containers, microVMs and VMs differ a lot in start time, isolation and whether they can have a GPU, and a common abstraction would only hide that.

Scheduling: power-of-k, and the node decides ​

Placement uses the classic power-of-k choices (the paper cites Mitzenmacher): pick k candidate nodes at random and take the least loaded. It needs no exact global state and still spreads load evenly.

Two details make it work under heavy concurrency:

• In-flight overlay. Node load is reported periodically, so a sandbox placed between two reports is invisible. Each scheduler instance records a placement the moment it picks a node and adds it to the load it computes, so a burst does not pile onto one node.
• The node has the final admission decision. Placement is best effort. The node checks its own capacity and memory pressure again and refuses if it is short; the scheduler retries elsewhere.

The control-plane services (API server, state collector) keep no persistent state: after a restart they poll the nodes again. A sandbox id encodes its node, so routing needs no lookup.

Overcommit and CPU core scheduling ​

About 90% of sandboxes use at most 5% of the CPU they request on average. Allocating by request wastes most of the machines, so DSec overcommits CPU heavily.

The cost falls on latency-sensitive work. Marking background work SCHED_IDLE is not enough: it only decides who runs first on one hardware thread, not what the neighbour on the other hyperthread of the same core does to the shared execution units and caches. The paper measured that, under a 50% interfering load, latency rose 45.2% unprotected; SCHED_IDLE improved that by at most 3.4%; with Linux CPU core scheduling the rise was 17.3%.

For memory, the paper also shares and reclaims: paused sandboxes have their memory swapped out, and identical read-only data is shared between sandboxes.

Images: layered builds, on-demand loading ​

RL environments are many, and each is used little, so pulling a whole image onto a node first is wasteful. DSec instead:

• Layers environments from independently versioned parts such as base, workspace and toolkit, so changing one part does not rebuild the whole image.
• Loads on demand from 3FS, DeepSeek's distributed file system: a sandbox fetches only the data it uses, which the paper measured at 4–13% of the image.
• Result: a burst of 8,192 containers took 35 minutes with on-demand loading and over 60 minutes with a full pull.
• Separates building from running: the accounts that build environments are not the accounts that run tasks, so a running task cannot write into an image others use.

A lifecycle designed for RL ​

DSec is co-designed with the RL training framework: stateful rollout execution happens in sandboxes, separate from GPU training, which can be preempted. For that the platform provides:

• Task-level operations: pause, resume or stop all of a task's sandboxes. Pause them all when training is preempted; resume them all when it is back.
• Transparent resume: any operation on a paused sandbox resumes it first.
• Reclaim on timeout: an explicit stop, or an idle timeout.
• Nested projects and bounded delegation: projects nest to any depth (say root/rl/job-42/agent-7), and an identity can only delegate permissions it holds.

Cheating and escape attempts ​

The paper records what agents actually did inside sandboxes: unbounded output filling the disk, forged requests to the sandbox's own management process, reading that process's logs for the answers, overwriting /bin/bash, corrupting file system metadata with ioctls, and scanning ports for package mirrors.

DSec's defences include AppArmor confinement and a network policy enforced with eBPF: outbound traffic denied by default and allowed by rule.

Cloud bursting ​

Above 80% utilization of the on-premises cluster, DSec sends part of the container work to the cloud. Only tasks whose images are in a deduplicated EROFS set of about 30 TB qualify; that set covers about 70% of container tasks.

Lessons for building your own sandbox platform ​

• Plan capacity by use, not by request, then protect latency-sensitive work with core scheduling.
• Image size is not the problem; how much gets read is. Load on demand first, tune storage later.
• Simple random placement is enough if nodes have the final say and schedulers remember what they just placed.
• Design task-level operations and pause from day one. RL training will be preempted.
• Treat the agent as untrusted code: capped output, deny-by-default network, grading kept apart from the agent.

OpenDsec: an open-source implementation, with different choices ​

OpenDsec implements the paper's architecture (IAM, placement, state collection, nodes, SDK and image store) and runs in production on two 384-thread bare-metal nodes. We chose differently in a few places:

Some measurements made against the paper (the project's bare-metal test machines, 2 × AMD EPYC 9Y24):

• CPU core scheduling: under a 50% interfering load, the latency rise fell from 18.0% unprotected to 2.1% (SCHED_IDLE plus core scheduling); under 100%, from 81.0% to 10.0%. Same direction as the paper.
• Density: one 384-thread node created a burst of 5,120 microVMs in 37 seconds; two nodes created a burst of 8,192 containers, all successfully.
• Anti-cheating: each incident the paper lists is handled, for example at most 64 MB recorded per output stream of a command, and agent sessions as an unprivileged user.

OpenDsec also has a fleet service for batched rolling upgrades and config changes, with running sandboxes untouched.

Not done yet: no on-demand versus full-pull comparison, and GPUs are untested on real hardware.

FAQ ​

Is DSec open source? ​

The paper describes DeepSeek's internal system and comes with no code. OpenDsec is not DeepSeek's code but our independent open-source implementation of the paper (server AGPL-3.0, SDKs Apache-2.0) and is not affiliated with DeepSeek.

Does DSec use containers or virtual machines? ​

Both. DSec has four backends (function calls, containers, microVMs and full VMs), with containers as the main one; the caller picks per task.

Why does RL training need its own sandbox platform? ​

One RL job can need tens of thousands of sandboxes at once, each installing dependencies, running tests and living for hours, and training can be preempted at any time. General container platforms usually lack task-level pause, large bursts of creation and defences against cheating.

How much can sandboxes be overcommitted? ​

About 90% of sandboxes use at most 5% of the CPU they request. OpenDsec overcommits CPU 8× by default and protects latency-sensitive sandboxes with CPU core scheduling. The right ratio depends on your workload.

What is reward hacking, and how does a sandbox prevent it? ​

Reward hacking is an agent earning reward by gaming the grader instead of solving the task, for example by reading the answers from grading logs or replacing system commands. The usual defence is to keep the agent away from grading: different users for agent and grader, capped output, and network denied by default.

Is this useful if I only need a code execution sandbox for an AI agent? ​

Yes. Overcommit, on-demand loading and escape defences apply to any service that runs untrusted code. OpenDsec also works as a code execution sandbox for AI agents and speaks the E2B SDK's API: see self-hosting E2B.

Further reading ​

• The paper: arXiv:2609.22978
• OpenDsec concepts
• OpenDsec compared with E2B, Daytona and Modal
• Quickstart: OpenDsec on one Linux machine

OpenDsec is an open-source project by Kernflux and is not affiliated with DeepSeek. Everything said here about DSec comes from the paper above.

E2B is one of the most used code execution sandboxes for AI agents: the code an agent writes runs in an isolated Firecracker microVM, and many agent frameworks support E2B. But E2B is mainly a hosted cloud service, so your code and data go to E2B's cloud. When data must stay on your network, the network is air-gapped, or you run enough sandboxes that the hosted price stops making sense, you self-host.

The short version. There are two ways to self-host E2B:

1. E2B's own open-source runtime (e2b-dev/runtime, Apache-2.0). It can be self-hosted on one machine (Embed); deploying into your own cloud account (BYOC) is an enterprise feature.
2. OpenDsec's E2B gateway. OpenDsec is an open-source sandbox platform with a gateway that serves the E2B API. Code written for the E2B SDK runs unchanged on your own machine or cluster after you set three environment variables.

This post walks through the second: a single-machine install, calling it with the E2B SDK, setting up the code interpreter, growing into a cluster, and how it differs from E2B.

Step 1: install on one machine ​

You need a Linux x86_64 machine (tested on Ubuntu 24.04) with systemd and cgroup v2. For microVMs (Firecracker, as in E2B) you also need /dev/kvm: bare metal, or a cloud VM with nested virtualization.

sudo -i                                    # the rest runs as root
apt update && apt install -y make git python3-venv
curl -fsSL https://go.dev/dl/go1.27.3.linux-amd64.tar.gz | tar -C /usr/local -xz
git clone https://github.com/kernflux/opendsec && cd opendsec
deploy/quickstart.sh

The script builds the binaries, downloads Firecracker and the guest kernel, and installs every service, including the E2B gateway (port 7400) with a template named base (Python 3.12). On a fresh 8-core VM the whole run took about 11 minutes, most of it building.

Step 2: call it with the E2B SDK ​

The install writes /root/opendsec-ops/demo.env, which already holds the three variables the E2B SDK reads:

. /root/opendsec-ops/demo.env       # sets E2B_API_URL, E2B_SANDBOX_URL, E2B_API_KEY
python3 -m venv .venv && .venv/bin/pip install e2b

E2B_API_KEY is an OpenDsec token. From here the code is exactly what you would write for E2B's cloud (run it with .venv/bin/python):

from e2b import Sandbox

sbx = Sandbox.create()                          # template "base"
print(sbx.commands.run("python3 -V").stdout)
sbx.files.write("/tmp/a.txt", "hello")
print(sbx.files.read("/tmp/a.txt"))
sbx.kill()

To call it from another machine, point the three variables at this machine:

export E2B_API_URL=http://<gateway>:7400
export E2B_SANDBOX_URL=http://<gateway>:7400
export E2B_API_KEY=<your OpenDsec token>

The JS/TS SDK works too (Node.js 22.19 or newer).

Fork, snapshots and pause ​

On microVMs, fork, snapshots and pause all keep memory, so running processes carry on:

from e2b import Sandbox

src = Sandbox.create(timeout=300)
src.files.write("/tmp/state", "v1")

forks = src.fork(count=2)                       # two copies of the running sandbox
snap = src.create_snapshot()                    # a snapshot
again = Sandbox.create(snap.snapshot_id)        # a sandbox from the snapshot

# Pause instead of ending at the timeout; connect resumes
s = Sandbox.create(timeout=60, lifecycle={"on_timeout": "pause", "auto_resume": True})
s2 = Sandbox.connect(s.sandbox_id)

for x in [src, *forks, again, s2]:
    x.kill()

Forks suit an agent's tree search, or fanning out many RL rollouts from one prepared environment.

Step 3: set up the code interpreter ​

E2B's code interpreter (run_code, with results, charts and pandas tables) needs a template of its own. OpenDsec builds it from E2B's open-source code-interpreter server: a memory snapshot of a microVM already running that server and a Python Jupyter kernel, so a new sandbox runs code at once.

The build installs packages inside the sandbox, so the machine needs access to apt mirrors and PyPI. Still in the opendsec directory:

curl -fsSL https://codeload.github.com/e2b-dev/code-interpreter/tar.gz/refs/heads/main | tar -xz
. /root/opendsec-ops/env                        # the admin token: publishing into the root project
.venv/bin/pip install ./sdk/python
.venv/bin/python deploy/e2b/build-code-interpreter.py code-interpreter-main/template

That builds the image root/code-interpreter:v1. Add a template for it under e2b.templates in /root/opendsec-ops/opendsec.json:

"code-interpreter-v1": {"image": "root/code-interpreter:v1", "backend": "microvm", "cpu": 2, "memory_mb": 2048}

Push the config and restart:

export OPENDSEC_OPS=/root/opendsec-ops
deploy/prod/opendsecops push-config all && deploy/prod/opendsecops restart

Callers then install e2b-code-interpreter and use it:

from e2b_code_interpreter import Sandbox

sbx = Sandbox.create("code-interpreter-v1")
print(sbx.run_code("6 * 7").text)               # 42

Speed ​

Measured on 2026-10-23 on the project's bare-metal test machines (AMD EPYC 9Y24), through the gateway, on Firecracker microVMs:

Growing into a cluster ​

If one machine is enough, stop here. With more sandboxes, OpenDsec grows into a multi-machine cluster (deployment docs), and the E2B gateway into several replicas:

1. In the cluster config's e2b section, list the gateways' addresses, the project sandboxes go into, and the templates.
2. Give nodes the fleet role e2b=<index>.
3. Put a load balancer in front: TCP 7400, health check HTTP 9467 /readyz.

The gateway keeps no state of its own and makes every call to OpenDsec with the caller's token, so permissions, quotas and audit records apply as usual.

How it differs from E2B's cloud ​

The full list is in E2B compatibility. The main points:

Options the gateway cannot honour return 400 instead of being ignored, so a program never runs without a setting it asked for.

E2B self-hosted or OpenDsec? ​

• E2B self-hosted (Embed) suits one machine that is enough and a preference for E2B's own code; deploying into your own cloud account (BYOC) is an E2B enterprise feature.
• OpenDsec suits multi-machine clusters, air-gapped installs, large bursts of creation such as RL rollouts, or wanting containers, QEMU VMs and task-level pause besides the E2B SDK. The cost is the compatibility gaps above, and the project is still 0.x.

More in OpenDsec compared with E2B, Daytona and Modal.

FAQ ​

Can E2B be self-hosted? ​

Yes. E2B's runtime is open source (Apache-2.0) and can be self-hosted on one machine; deploying into your own cloud account is an enterprise feature. Alternatively, OpenDsec's E2B gateway serves the API the E2B SDK calls on your own machine or cluster.

Do I need to change my E2B code to use OpenDsec? ​

No. Set E2B_API_URL, E2B_SANDBOX_URL and E2B_API_KEY to point the SDK at the gateway. Features the gateway lacks, such as directory watching, return a clear error.

Does it support E2B's code interpreter? ​

Yes. Build the template with deploy/e2b/build-code-interpreter.py and run_code works, with results, logs, errors, charts and pandas tables. Only the Python kernel for now.

Does it work on a cloud VM without KVM? ​

Yes. Without /dev/kvm the install sets up containers only, and the gateway's base template uses the container backend. Fork and snapshots then keep only the file system, and the code interpreter template needs microVMs.

Can it run fully offline? ​

Yes. OpenDsec has an offline bundle (deploy/offline); we tested installing it and using the E2B SDK on a VM with no internet access. See Install.

What does self-hosting cost? ​

OpenDsec is free, open-source software (server AGPL-3.0, SDKs Apache-2.0); you only need your own machines.

Further reading ​

• E2B compatibility: what works and what differs
• Quickstart
• Multi-machine cluster deployment
• DeepSeek's DSec paper: where OpenDsec's design comes from

OpenDsec is not affiliated with E2B; it implements the API the E2B SDK calls. What this post says about E2B comes from its documentation and repositories, checked on 2026-10-25.

OpenDsec's automated tests always ran, and passed, on our development machine and our production cluster. But the development machine has everything installed, and the production cluster was tuned step by step. A new user starts from a fresh machine and a README. So before the release we took a new user's place: fresh Ubuntu 24.04 VMs, the documentation, and every feature a user might touch.

What we tested ​

Two serious issues ​

On a current Ubuntu kernel, every microVM resume failed. Ubuntu 24.04's 6.8.0-147 kernel kills a process placed with CLONE_INTO_CGROUP into a cgroup that has ever been through cgroup.kill. OpenDsec ends the VM process on pause and starts a new one in the same cgroup on resume, so every resume failed. Our production machines run an older kernel, which is why we never saw it; a kernel upgrade would have exposed it. Killing now freezes the cgroup and sends SIGKILL to each process instead of using cgroup.kill, and a regression test fails on the affected kernel.

Restarting a control node failed a few calls with unknown edge. After a restart the watcher only learned about compute nodes when they re-registered, up to 10 s later, and meanwhile the apiserver treated them as gone. A hard reset of one control node failed 3 of 3,911 calls in a load test. The watcher now starts from the nodes its peers know, and the apiserver keeps a node it briefly cannot see for 2 minutes. The same hard reset now fails none.

The rest ​

Most of the other 20 are things a new user hits on day one:

• Install: fresh machines lack make, and the script only failed halfway through the build; fresh Ubuntu lacks python3-venv; fresh cloud images have no package lists until apt update.
• CLI: opendsecctl exec dropped argument quoting, breaking python3 -c '...'; --help did not work; batch create printed no IDs; importing a missing local file went to Docker Hub.
• E2B: a single-machine install had no E2B gateway, and on clusters that deny internet by default E2B sandboxes had none, while E2B allows it by default.
• Operations: opendsecops restart skipped the E2B gateway; the disk alert used a fixed threshold and fired on every machine under 200 GB; on Kubernetes the apiserver could not write the image store.
• Performance: the NFS 4.1 we recommended cannot find holes in sparse files, so creating from a memory snapshot on another node read the whole memory file and took 141 s; with 4.2 it takes 62 s. The docs now say 4.2, and store-check warns about 4.1.

Each is listed in the CHANGELOG.

Not covered ​

Real GPUs, ARM machines, multi-node Kubernetes, and distributions other than Ubuntu 24.04. If you run OpenDsec on one of these and something breaks, please open an issue.

Takeaway ​

A full test run on a development machine shows the code is right on our machines. It does not show a user can get it working from the docs. Both serious issues came from the environment: a newer kernel, and restart timing that production never produced. Walking through the docs on a fresh machine finds problems a development machine never will.

Today we published the OpenDsec source on GitHub. OpenDsec is sandbox infrastructure for reinforcement-learning training and code-executing agents: it creates, pauses, copies and destroys isolated environments in bulk, on your own machines.

Why ​

Agentic RL training runs thousands of rollouts at once, and each needs an isolated environment that can install dependencies, run tests and reach the network. Training gets preempted, so environments must pause as a batch. The same state gets explored several ways, so environments must be copied together with their memory.

DeepSeek described the system they built for this in DeepSeek Elastic Compute (DSec). OpenDsec follows that paper: a stateless apiserver, IAM with nested projects and quotas, a watcher that aggregates scheduling state, power-of-k placement with final admission on each node, layered images, a default-deny network policy and task-level pause. Where the paper is silent we made our own choices, and the SPEC in the repository marks which design points come from the paper and which are ours.

OpenDsec is an independent project. It is not affiliated with DeepSeek and contains none of its code.

What it does ​

• Fast: a Firecracker microVM cold-starts in about 0.1 s, is created from a memory snapshot in about 55 ms and resumes from a pause in about 50 ms.
• Fork: fork(count=N) copies a running VM with its memory while pausing the source for about 10 ms. Copies on one node share memory pages; 64 of them restore concurrently in about 0.2 s.
• Scale: one 384-thread node took a burst of 5120 microVMs in 37 s.
• E2B compatible: code written for the E2B SDK runs on your machines after changing three environment variables. E2B's own Python and JS SDK acceptance checks all pass.
• Operable: mTLS between components and a Raft-replicated IAM; staged fleet rollouts with automatic rollback; offline installs. Upgrading any component leaves running sandboxes alone.

These numbers come from our own bare-metal machines; the SPEC says how each was measured.

Try it ​

One Linux machine with Ubuntu 24.04, about 10 minutes:

sudo -i
apt update && apt install -y make git python3-venv
curl -fsSL https://go.dev/dl/go1.27.3.linux-amd64.tar.gz | tar -C /usr/local -xz
git clone https://github.com/kernflux/opendsec && cd opendsec
deploy/quickstart.sh

See Get started for the details, and Deployment for clusters and offline installs.

License ​

The servers are AGPL-3.0. The Python SDK, the Go client and the API definitions are Apache-2.0, so programs that call OpenDsec are not bound by the AGPL. A commercial license covers closed modifications, offering OpenDsec as a service without publishing changes, and the enterprise edition's single sign-on and audit export.

What's next ​

OpenDsec is at 0.x, and interfaces may change before 1.0. Not yet verified: distributions other than Ubuntu 24.04, real GPUs, and multi-node Kubernetes. Issues and pull requests are welcome on GitHub.