DeepSeek Just Revealed How It Runs 380,000 Agent Sandboxes at Once. Is Agent Infrastructure Still a YC W27 Wedge?

On September 23, DeepSeek posted a paper to arXiv titled "DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale." This week it climbed the Hacker News front page. The headline numbers are the story: a single production unit of roughly 160 nodes sustains more than 380,000 concurrent sandboxes, creates over 5,000 new sandboxes per second, and churns through about 3 million sandboxes per day. DeepSeek founder Liang Wenfeng is the corresponding author, alongside 100+ co-authors, and the paper was prepared for ACM SIGOPS ATC 2026.

If you are drafting a YC W27 application anywhere near agent infrastructure, this paper just changed the question you will get asked. It used to be "how do you run agents safely at scale?" Now a frontier lab has published a detailed answer. The question becomes: what is left for a startup?

What did DeepSeek actually publish?

DSec is the sandbox layer under DeepSeek's agentic reinforcement learning pipeline. It exposes four backend types, function-call, container, microVM, and full VM, through one unified SDK, so a training run can pick the cheapest isolation level that fits the task. It loads sandbox images on demand over 3FS, the distributed filesystem DeepSeek open-sourced in early 2025, and it coordinates sandbox lifecycles with GPU training steps so expensive accelerators are not idling while rollouts wait on environments.

The use case is agentic training and evaluation: models inspecting repositories, invoking tools, and executing commands inside isolated environments, hundreds of thousands of times in parallel.

One important caveat: as of this writing, DSec is a paper, not a code release. Unlike 3FS, DeepSeek has not announced that DSec itself is open source.

Does DSec kill sandbox and agent-infra startups?

No, and the reasoning matters more than the conclusion, because a YC partner will make you walk through it.

First, a blueprint is not a product. DSec assumes DeepSeek's stack: colocated GPU clusters, 3FS, an RL pipeline on the other side of the API. Nothing in the paper bills a customer, isolates one tenant from another commercially, or passes a SOC 2 audit.

Second, DSec was built for exactly one customer, DeepSeek's own training runs. The design choices that make it brilliant for RL rollouts, like tying sandbox lifecycle to training steps, are irrelevant to a product team that just needs its support agent to execute code without touching production data.

Third, and most useful for your application: the paper is a demand signal. If one lab burns 3 million sandboxes a day, every serious agent effort has some version of this problem, and almost none of them can staff a platform team to build a 160-node sandbox fabric. The gap between "the frontier labs solved this internally" and "a 40-person company can buy this" is where infrastructure startups have always lived.

Where is the actual wedge for a W27 application?

The commodity layer is shrinking. YC itself open-sourced QM, its multi-agent harness, earlier this year, and DSec now describes the scale-out execution layer. If your pitch is "we run containers fast," you are pitching a feature both of those projects already demonstrate. Three adjacent layers look more defensible.

Sandboxes for teams that are not labs

DeepSeek optimized for throughput on trusted internal workloads. A product company shipping agents to end users has the opposite problem: hostile inputs, multi-tenant isolation, per-customer data boundaries, billing, and compliance evidence. Selling that as a service is a different company than DSec, even if the microVMs look similar.

Environments as the scarce asset

DSec makes execution cheap. It does not make realistic environments cheap. A sandbox that boots in milliseconds is worthless for training or evaluating a healthcare agent unless something inside it behaves like an EHR, with the permissions, the mess, and the edge cases. Domain-specific evaluation environments, for insurance back offices, bank reconciliation, hospital systems, are labor-intensive to build and hard to copy. TesterArmy (YC P26) is attacking the adjacent problem with AI testing agents; the environments those agents run against are the flip side of the same market.

The trust boundary around the sandbox

Once agents execute real commands at DSec-like volumes in production rather than training, the urgent questions become identity, credentials, and audit: what did the agent touch, as whom, and who approved it. OneCLI (YC S26) reached 300K downloads with a credential firewall for agents, which suggests how much pull exists at this layer already.

How should you frame this in your application?

Expect two hard questions. One: why won't this leak out of the labs as open source? DeepSeek has a track record of releasing exactly this kind of internal tooling, 3FS included, so "they will keep it closed" is not a safe assumption. Your answer has to be a customer the lab version will never serve, not a head start. Two: who is desperate for this today? A W27 application with 15 design partners running real agent workloads through your sandbox beats any TAM slide about the agent economy.

And before you submit, pressure-test whether your wedge survives contact with someone who has sat on the other side of the table. Getting your application reviewed by YC alumni through YC Roaster is a cheap way to find out whether "DSec but as a product" reads as a company or as a feature, before a partner asks.

The one-line takeaway: DSec proves the demand and commoditizes the how. The companies that get funded out of this moment will own the customer the labs will never serve, the environments the labs cannot fake, or the trust layer the labs do not want to be liable for.