Agent Runtime 2026: Cloudflare Bets Against Containers

In one line: An agent runtime is the execution layer that decides where an agent's code actually runs. On August 3, 2026, Cloudflare shipped @cloudflare/computer, a runtime that gives an agent one filesystem and lets it choose per command between a lightweight isolate and a full Linux container.

TL;DR

Cloudflare opened its second Agents Week of 2026 on August 2, three and a half months after the first one closed.¹² Day two's headline release was @cloudflare/computer, an early-preview, open-source agent runtime built on a premise the company states bluntly: giving every agent its own container will not scale.³

The design gives an agent a single virtual filesystem backed by SQLite, living inside a Durable Object, plus two interchangeable execution backends — an isolate and a container — that operate on the same files.³ The agent picks which one to use per command.

Cloudflare's stated goal is that a container ends up required for less than 10% of an agent's work.³ That number is the falsifiable part of the announcement, and it is the number worth watching.

The rest of the field disagrees about the primitive, not the problem. E2B and Vercel Sandbox isolate agent code in Firecracker microVMs; Modal uses gVisor.⁴⁵ Cloudflare is an outlier in betting that most agent work never needs a kernel of its own.

What You'll Learn

• What an agent runtime is, and how it differs from an agent framework
• What Cloudflare shipped on day two of Agents Week 2026
• Why containers became the scaling bottleneck for agent compute
• How @cloudflare/computer splits work between isolates and containers
• How the isolation choice compares across E2B, Modal, Vercel and Cloudflare
• Which claims here are verified, and which are still just targets

What Cloudflare Shipped on Day Two

Cloudflare's second Agents Week of the year opened on August 2, 2026 with a framing post from Rita Kozlov that names no products at all.¹ The first Agents Week ran April 13–17, 2026 and shipped a much broader slate, including Sandboxes reaching general availability.²

The opening post sets up a five-day arc and a thesis about who the cloud was built for: "The cloud we have today, and the web it sits on, were built for people. Every layer assumes a human is watching."¹

Day two, August 3, carried five posts tagged to the week. Four were platform plumbing: inbound TCP and gRPC support for Workers and Containers, a Billable Usage API built around the FOCUS specification, Workers RPC working across Python and JavaScript, and an engineering post on serving Kimi and GLM models more cheaply.⁶

The fifth is the one that carries an argument. "Your agent needs a computer, not a container" introduces @cloudflare/computer, written by Matt Carey and Aron Carroll.³

It ships as an early preview and an open-source library, installable with npm install @cloudflare/computer.³ Two innovation weeks on the same theme in under four months is itself a signal about how fast this layer is moving.

Why Containers Became the Bottleneck

The post opens with an observation about how agent architecture shifted during 2026. At the start of the year, the norm was to spin up a container and run the agent inside it.³

More recently, agent harnesses moved to offering sandboxed code execution as a tool instead. Cloudflare describes this as separating "the hands (the sandbox where work is done) from the brain (the agent loop)."³

That separation is now common across the industry. The disagreement is about what the hands should be made of.

Cloudflare's case against containers is a capacity argument, and it is stated without hedging: "across all the clouds, all the hyperscalers, there's nowhere near enough compute in the world for every company to give each of their users' agents their own containerized compute environment."³

The company ties this directly to a market condition builders will recognise from their invoices: "This is why there is desperate, panicked industry demand for CPU compute, not just GPU compute."³

That framing is worth pausing on. Most coverage of the agent compute crunch focuses on GPUs. Cloudflare is arguing the CPU side is where per-agent scaling actually breaks — a point that lines up with what the new agentic inference benchmarks started measuring earlier this year.

The Bet Cloudflare Already Made

The isolate argument is not new for Cloudflare, and the post is explicit that this is a position nearly a decade old rather than a fresh idea.

Cloudflare introduced Workers on September 29, 2017, and Durable Objects in September 2020.⁷⁸ Containers followed much later, reaching public beta in June 2025.⁹

The stated reason for preferring isolates is horizontal scale. They spin up and tear down quickly, can hibernate while an agent is idle, can hold the agent's own state, and can spin up further isolates to run untrusted code.³

Cloudflare's architecture has run the agent harness in a Durable Object and called an attached container on demand as a tool since containers arrived.³ @cloudflare/computer is the attempt to stop making developers wire that split together themselves.

How @cloudflare/computer Works

The central piece is the workspace: a virtual filesystem backed by SQLite, populated from cloud storage, source control, or arbitrary files, and instantiated on any Durable Object.³

Execution runtimes attach to that filesystem. All of them expose the same interface, exec(string, options), and two ship out of the box.³

The isolate backend uses just-bash to translate shell code into JavaScript, running inside a dynamic worker with the filesystem available directly via worker bindings.³

The container backend uses Cloudflare Containers for a full Linux environment, with the filesystem provided through a FUSE mount so changes sync back to the source of truth.³

Both work against the same files. That shared-state design is what makes switching between them per command coherent rather than a migration.

For agents, Cloudflare provides an AI SDK compatible toolkit exposing read, write, edit, ls and exec.³ All operations are gated, audited and observed, which matters given how much of the last year's agent containment work has been about knowing what an agent actually did.

The exec tool is the interesting one. It takes a backend argument, and the tool description is written to steer the model toward the right runtime — a fast, cheap worker, or the fully featured container.

Cloudflare's claim is that this works: "In our testing, the frontier models are very good at making the correct decision and falling back to using containers only when needed."³ That is a vendor claim about its own testing, with no published benchmark attached.

The documented example runs on @cf/zai-org/glm-5.2, Z.ai's agentic coding model on Workers AI, paired with @cloudflare/think.³

The Sub-10% Target

The concrete, checkable claim in the whole announcement is this one: Cloudflare's goal is a runtime "where a container is required for less than 10% of its work," with coding tasks, audio and video manipulation, and document creation all handled by isolates.³

Note the tense. That is a goal, not a measured result — Cloudflare does not publish a current figure against it.

It is still the right number to track, because it is the whole thesis in a single metric. If real agent workloads need a container 40% of the time, the abstraction is a convenience wrapper. If they genuinely need one under 10% of the time, the per-agent cost curve changes, which is the same lever behind the token and compute cost per task problem teams are already fighting.

How the Field Compares

The agent sandbox market did not wait for Cloudflare. The comparison below covers the isolation primitive each provider uses, which is the substantive difference between them.

The pattern is clear. The other major providers moved toward stronger kernel-level isolation, because a shared-kernel container is a weak boundary for untrusted model-generated code.

Cloudflare is arguing something different: that most agent commands are file manipulation, data processing and git operations that never needed a kernel at all, and that the right move is to make the strong-isolation path the exception rather than the default.

Both things can be true. A V8 isolate is a language-level boundary, not a hardware one, and that trade-off is the part builders should price in — particularly anyone who followed the sandbox escapes disclosed this summer.

What Is Actually New, and What Isn't

Worth separating, because the framing here is doing some work.

Not new: the phrase "give your agent a computer." Cloudflare's own April post announcing Sandboxes GA was titled "Agents have their own computers with Sandboxes GA."¹⁰ Vercel used near-identical language when its Sandbox went GA in January.⁵ The framing predates this release on both sides.

Not new: running agent code in a sandbox as a tool. That shift happened across the field during the first half of 2026.

Also not new: pluggable execution backends. The managed agent runtimes AWS, Google and Alibaba shipped this year already provision isolated per-session environments behind a single API, and agent frameworks have offered swappable sandbox targets for a while.

The actual distinction: who chooses, and when. In most multi-backend designs the developer picks a backend at configuration time. Here the tool description steers the model to choose per command, at runtime, against one filesystem that stays in sync across both. That is a narrower novelty than the headline implies, but it is a real one.

Unproven: that frontier models reliably pick correctly, and that the sub-10% target holds on real workloads. Both are Cloudflare assertions today.

What This Changes If You're Building Agents

If you are already on Cloudflare, this collapses a wiring problem you were solving in userspace. The filesystem, the git tooling, the shell and the audit trail arrive as one package instead of three.

If you are not, the useful takeaway is the question rather than the product. For your agent's actual command mix, what fraction genuinely needs a Linux userland?

Most teams have never measured this. They picked a sandbox provider, gave every agent a full environment, and absorbed the cost. If your answer is well under half, you are paying microVM prices for cat, grep and git.

The counter-consideration is security posture. Firecracker and gVisor exist because model-generated code is untrusted input, and the industry moved that direction deliberately. An isolate-first default is a cost optimisation that narrows your blast radius less than a microVM does.

Cloudflare has now moved this layer twice in under four months, and it is not moving alone. Read it alongside what AWS, Google and Alibaba shipped — the hyperscalers are selling the agent loop as managed infrastructure, while Cloudflare is arguing about what the loop should run on.

The Bottom Line

The headline is a provocation, but the argument underneath it is a capacity claim: there is not enough compute in the world to give a billion concurrent agents a container each, so something in the default has to give.

Cloudflare's answer is to make the container the exception and let the model decide when it is needed. That is a real architectural position, and it runs against where E2B, Modal and Vercel have been heading.

What is missing is evidence. The sub-10% figure is a goal, the claim about model routing accuracy is untested in public, and the whole thing is an early preview.

Watch for two numbers over the next quarter: a measured container-usage rate on real workloads, and any independent evaluation of how well frontier models actually pick their own backend. Until those land, this is a well-argued bet rather than a settled result.