How Sapiom ran 2.5 million agent sandboxes in three months on Blaxel

In the first three months on Blaxel, Sapiom spun up 2.5 million sandboxes. Each one is a live agent run: a bounded, isolated computer that boots, does autonomous work, and disappears.

Volume like that usually takes a company a year or more to reach. Sapiom passed it in weeks, while the team was still three months old.

The story of how a startup that young absorbed that kind of scale is really a story about what it takes to run autonomous agents at all, and about a vendor relationship that looks nothing like the usual one.

The company

Sapiom is the platform builders use to ship, run, and scale agentic products, removing the infrastructure barriers between a working agent demo and one running in production.

It was founded by Ilan Zerbib, who spent years overseeing billions of dollars in payments at Shopify, and in August 2026 raised a $35 million Series A led by Dragonfly, bringing total funding to $55 million, with Accel, Gradient Ventures, Coinbase Ventures, Operator Collective, Formus Capital, and VanEck Ventures.

The core thesis is simple to state and hard to build: AI has made capable agents easy to build, but most never reach production because the infrastructure underneath them was never designed for autonomous software.

Sapiom removes those barriers, starting with the cost of execution. It sits at the point of execution and, for every action, takes the best allowed path across models, compute, tools, and services, with budgets and permissions enforced before anything runs and every action metered in a complete audit trail.

The problem: running agents is the hard part

When Sapiom started building in late 2025, the plan was to make existing agents more capable. The team quickly ran into a more basic gap. Most people had no reliable way to run an agent in the first place.

“The bottleneck isn't building the agent. It's running it cost-efficiently at scale. You become an infra engineer instead of selling your product.”

David Zhang, Founding Engineer, Sapiom

To close that gap, Sapiom needed compute infrastructure that could satisfy four hard requirements at once:

• Unpredictable, massive bursts. An agent platform can go from zero to tens of thousands of concurrent executions with no warning. Traditional cloud provisioning, where you buy instances, wait for startup, and manage capacity, does not map to that pattern.
• Cost model alignment. Sapiom bills its own customers per agent execution. Paying for always-on infrastructure while agents sit idle would break the economics of the business.
• Security and isolation. Agents run untrusted, AI-generated code. Every execution has to be sandboxed so a misbehaving agent cannot reach another customer's data or escape to the host.
• Speed at the edges. Agents call other agents. Latency compounds across thousands of chained requests, so even small startup delays add up fast.

The evaluation

David Zhang led due diligence on three options: building a custom solution on GCP, adopting E2B, an open-source sandbox provider, and Blaxel.

The bar was deliberately high. Sapiom was not shopping for a prototype environment. They wanted production-grade infrastructure on day one, with a clean path from one customer to a hundred and no rearchitecting later.

“We evaluated based on time to production-ready integration, not time to demo. We didn't want to redo architecture later.”

David Zhang, Founding Engineer, Sapiom

Blaxel matched the requirements point for point.

Isolated micro-VMs gave Sapiom the security boundary. Auto-suspend scaled idle environments down within seconds, rather than holding them at the one-to-fifteen-minute minimum billing increments common elsewhere, which fit Sapiom's usage-based model exactly.

And sandboxes came up in less than one second, faster than anything Zhang had seen on AWS or GCP.

“If on paper what they're claiming is true, we can see this working. We didn't have to stretch our imagination.”

David Zhang, Founding Engineer, Sapiom

Five weeks to production

Sapiom signed up with Blaxel at the end of January 2026 and shipped to production on March 3, 2026. The integration ran roughly five to six weeks.

Provisioning sandboxes and building images went quickly. The harder work sat on Sapiom's side, restructuring application code that had always assumed it would run in-process with full access to everything, so it could instead run in remote, locked-down environments.

That carve-out is an architectural decision, not a copy-paste, and Zhang flags it as the thing other teams underestimate when they evaluate any external compute provider.

What surprised the team ran the other way. Startup was far faster than expected.

“Sub-five-second sandbox startup with pre-built images. Coming from AWS and GCP where you're waiting quite a while for instances, it was pretty surprising.”

David Zhang, Founding Engineer, Sapiom

That speed comes from the architecture underneath. Baseline boots a micro-VM in roughly 200 milliseconds. Blaxel brings resume down to 25 milliseconds using snapshot-based suspend.

The mental model is a laptop lid: the environment stops consuming resources but keeps full memory and filesystem state, then wakes in 25 milliseconds with everything intact.

A vendor relationship that behaves like a team

This is where the Sapiom-Blaxel relationship stops looking like a normal vendor arrangement.

Christophe Ploujoux, a Blaxel co-founder, has a dedicated desk at Sapiom's office, a Sapiom email address, and access to their infrastructure. The teams run a daily 20-to-30-minute sync. When Sapiom surfaces a need, features often ship within days.

“I don't have that kind of relationship with any other vendor. Our inference providers do custom tuning, but they don't build net-new features based on our needs. Blaxel does.”

David Zhang, Founding Engineer, Sapiom

Several features came straight out of that collaboration:

• Billing API. Sapiom needed exact per-sandbox cost data to reconcile charges and bill its own customers accurately. Blaxel built a billing API that returns precise cost when a sandbox is deleted, letting Sapiom pass compute costs through at the transaction level.
• Globally shared images. Sapiom isolates each customer in its own workspace, but needed to share base images across workspaces without breaking that boundary. Blaxel committed to the feature within one to two days of a Slack conversation.
• Custom domains. The feature existed but was region-locked. Blaxel unlocked it globally to fit agent-scale use.

None of these serve only Sapiom. Each one becomes part of Blaxel's product for every customer, which is part of why the relationship works in both directions.

The numbers

“From seed to late-stage startups multiple times, the volume we're seeing at machine level would typically take a year, maybe 18 months. A week later, we've already surpassed it.”

David Zhang, Founding Engineer, Sapiom

In the first three months on Blaxel, Sapiom created 2.5 million sandboxes, each one a bounded, isolated agent run.

To put that in context:

• 2.5 million total sandboxes created as of June 2026
• 732,000 sandboxes in a single recent month
• 25,000 to 70,000 sandboxes per day at peak
• Sub-1-second startup times per sandbox with pre-built images
• 25 millisecond resume from suspended state

Sapiom went from zero to one of Blaxel's largest customers in weeks.

The relationship began as usage-based, with automatic top-up when the balance drops below a threshold, and is now moving toward an annual commitment.

Under the hood

For technical leaders sizing up infrastructure for autonomous workloads, the lifecycle is where the design choices show.

Each Sapiom agent execution runs like this:

1. An agent requests a sandbox through Sapiom Runtime. Sapiom checks the request against the agent's mandate, budgets, and permissions, and enforces those limits before execution rather than in application code.
2. Blaxel provisions an isolated micro-VM. The agent receives a sandbox URL and execution capabilities.
3. The agent runs its task inside the sandbox. It has full filesystem and process access, isolated from every other execution.
4. After 15 seconds of inactivity, the sandbox auto-suspends. Memory and filesystem state are preserved as a snapshot, and no compute charges accrue while suspended.
5. When the agent needs the sandbox again, it resumes in 25 milliseconds with state intact.
6. When the sandbox is deleted, Blaxel's billing API returns exact cost, and Sapiom reconciles it against the customer's account.

The 15-second idle scale-down was, in Zhang's words, “extremely important.”

Sapiom could not predict customer workloads. Some agents finish in seconds, while others run intermittently over much longer stretches. Minimum billing increments of one minute, or the 15 minutes some providers default to, would have made the economics unworkable.

Security lives at the hypervisor level. Each sandbox runs in its own micro-VM, the same isolation technology that powers AWS Lambda.

A misbehaving agent cannot escape to the host or reach another customer's environment.

Blaxel's Proxy service adds a second layer by injecting API keys into sandboxes at runtime rather than storing them inside, which keeps agents away from raw credentials.

Blaxel holds SOC 2 Type II and ISO 27001 certifications, with HIPAA compliance supported too.

What customers see

Sapiom's largest customer, Polsia, an AI company builder, runs roughly 100,000 applications across 10,000 active companies, with close to 10,000 deployments a day.

With Sapiom, Polsia's own customers get fully powered compute environments with stateful persistence across sessions, secure tool access, and the ability to run more than 10,000 concurrent agents without touching the core application.

“Zero friction to spin up an isolated, bounded environment. Now they truly have complex autonomous workflows running at scale, concurrency, and safely.”

David Zhang, Founding Engineer, Sapiom

The isolation story carries real weight for these customers.

Agents in Blaxel micro-VMs are bounded, cannot escape the sandbox, and are ephemeral by default, alive only as long as the work requires. For anyone running untrusted AI-generated code in production, that boundary is the difference between confidence and exposure.

What running agents at scale looks like

Ask Zhang what surprised him most about operating agents at volume, and the answer is not about any single feature. It is about how differently this workload behaves from anything that came before it.

The wall arrives early. Building the agent was never the hard part; running it was. Zhang expects more teams to hit that wall in week one rather than a year in, as people go from zero to a million agents in a matter of days.

The load does not look like human traffic.

Autonomous agents show up in bursts that would have read as an attack a few years ago. Sapiom has seen spikes of more than 200,000 sandbox requests in a single second.

The instant nature is what makes them brutal to absorb: by the time fresh capacity comes online, the spike is already gone. Sapiom's own safeguards have occasionally flagged the company's traffic as suspicious, because tens of thousands of agents spawning at once still looks anomalous by every historical measure.

The load is also getting harder to forecast.

A team running a finished agentic system produces relatively stable traffic. A team constantly building new things on top of its agents produces load nobody can predict, because the builders themselves do not yet know what it will look like.

On security, Zhang's view is blunt. Agents are rarely malicious, but they are relentless about finishing a directive. After Sapiom cut off one route to a credential, agents wrote scripts to find another.

Hard isolation at the infrastructure level does what prompt-based guardrails cannot.

“Standard security practices and physical isolation still matter. Defensive prompting is maybe not even worth the tokens it's costing you.”

David Zhang, Founding Engineer, Sapiom

What's next

The partnership is spreading across Blaxel's product surface. Sapiom is actively moving into:

• Application deployment, with an expected 3x cost reduction for always-on apps
• Scheduling, so agents can decide when to wake themselves up, do work, and go back to sleep
• Storage, Agent Drive and Volumes, for data that has to persist across agent sessions
• Proxy, for centralized secret management across sandboxes

The longer-term vision is durable agents that run autonomously for weeks or months, parallelizing work, treating compute as a managed resource, and safely persisting state between sessions.

“We're teaching LLMs the same infrastructure tricks our engineers learned over their careers. How to parallelize. How to manage resources. How to save state. The goal is agents that can design and run fully autonomous applications.”

David Zhang, Founding Engineer, Sapiom

Sapiom is the platform builders use to ship, run, and scale agentic products; Blaxel is one of the infrastructure components powering the compute layer inside Sapiom Runtime.

Together they are assembling the stack that autonomous agents actually need to operate at production scale.

Ready to run autonomous agents at scale? Talk to the Blaxel team about infrastructure built for autonomous workloads.