# Cloudflare raises the stateful Dynamic Worker concurrency ceiling from four to ten Cloudflare Durable Objects can now keep ten distinct Dynamic Workers in flight at once instead of four, increasing the amount of isolated runtime code a single stateful supervisor can coordinate before builders need to shard the workload. The new 10-worker ceiling is a niche but concrete scaling change for platforms using Cloudflare Dynamic Workers as agent code sandboxes, generated-app runtimes or multi-tenant automation workers. Ordinary Worker requests remain capped at four distinct Dynamic Workers in flight. - Status: Active - Published: 2026-08-29T09:40:28+12:00 - Updated: 2026-08-29T09:40:28+12:00 - Categories: Artificial Intelligence, Web Development, Cloud & Infrastructure, AI Agents, Cloud Platforms, Developer Tools - Tags: AI agents, Cloudflare, sandboxing, Workers - Canonical HTML: https://beyondthe.news/dossiers/cloudflare-durable-objects-dynamic-workers-concurrency-ten-agent-sandboxes ## What changed Cloudflare increased the concurrency limit for Dynamic Workers used from a Durable Object from four distinct in-flight workers to ten. A Durable Object shares one input/output context across all concurrent requests to that object, so the ten-worker limit applies collectively to that stateful supervisor. Multiple simultaneous requests to the same Dynamic Worker count as one distinct worker. The ordinary Worker-request limit remains four. Dynamic Workers are Cloudflare's low-level primitive for creating arbitrary Worker code at runtime and are explicitly positioned for AI-agent code execution, generated applications, custom automation and multi-tenant platforms. ## Why it matters For most Cloudflare Workers applications, this limit is irrelevant. For builders using a Durable Object as a stateful supervisor around Dynamic Workers, however, four distinct active sandboxes could become an architectural boundary quickly: additional workloads required queuing, consolidating work into fewer runtimes or sharding state across more supervisors. Raising the ceiling to ten increases the amount of parallel isolated code one stateful coordinator can manage by 2.5× without changing the application-level state model. It does not remove other limits such as subrequests, CPU or outgoing connections, so teams should treat it as targeted concurrency headroom rather than a universal scaling increase. ## Durable Objects get the higher limit because they share state Cloudflare distinguishes Dynamic Workers started from an ordinary Worker request from those coordinated inside a Durable Object. A regular request still has a limit of four distinct Dynamic Workers with in-flight requests. A Durable Object shares its I/O context across concurrent requests, and that shared context can now have ten distinct Dynamic Workers in flight. ## One sandbox can handle multiple requests without consuming extra slots The limit counts distinct Dynamic Workers, not raw request count. Multiple in-flight requests to the same Dynamic Worker count as a single entry toward the ceiling. That makes the increase particularly useful for supervisors coordinating multiple isolated tenants, code bundles or agent runtimes rather than simply increasing traffic to one sandbox. ## The practical effect is less forced sharding A platform that previously needed more than four simultaneously active runtime identities under one Durable Object could have to queue work or split supervision across additional objects. The ten-worker ceiling gives that stateful coordinator more parallelism before it reaches the same design pressure, which can simplify session ownership and shared-state logic for agent or generated-application platforms. ## Dynamic Workers remain intentionally constrained sandboxes Cloudflare lets the supervising application define a Dynamic Worker's code, bindings, network access and custom CPU/subrequest limits. The higher concurrency ceiling does not broaden what each sandbox is allowed to do; it only increases how many distinct sandboxes a Durable Object can have active concurrently. ## Other platform limits still determine throughput Dynamic Workers still execute inside the wider Workers/Durable Objects resource model. Subrequest limits, CPU limits, memory, network connections and application-level contention can become bottlenecks before the new ten-worker ceiling. Teams should load-test completed tasks rather than multiplying a four-worker throughput estimate by 2.5. ## Key details - Cloudflare announced the Dynamic Worker concurrency increase on August 28, 2026. - Durable Objects can now have up to ten distinct Dynamic Workers with in-flight requests, increased from four. - The limit is shared across all concurrent requests to the same Durable Object because they share an I/O context. - Multiple in-flight requests to the same Dynamic Worker count as one distinct worker toward the limit. - Ordinary Worker requests remain limited to four distinct Dynamic Workers in flight per request. - Dynamic Workers can run arbitrary runtime-supplied code in isolated Workers and support configurable bindings, network access and resource limits. - Cloudflare lists AI agent code mode, generated applications, automations and multi-tenant platforms among Dynamic Worker use cases. ## Builder takeaways - If a Durable Object currently queues work because it reaches the four-Dynamic-Worker ceiling, benchmark whether the new ten-worker limit lets you simplify sharding or coordinator logic. - Do not automatically raise concurrency to ten in production; test Durable Object CPU, subrequest, storage and external-service contention under the additional parallel work. - Keep per-sandbox network and resource limits narrow. More concurrent sandboxes increase aggregate capability but should not expand each runtime's permissions. - Measure distinct active runtime identities rather than total calls when deciding whether the new ceiling is relevant to your architecture. - For multi-tenant agent platforms, verify that state ownership and failure isolation remain correct when more independently executing workers share one Durable Object supervisor. ## What to watch - Whether Cloudflare raises the ordinary Worker-request Dynamic Worker limit above four. - Pricing or metering changes specifically tied to Dynamic Workers as agent-sandbox use grows. - Higher limits for Durable Object CPU, outgoing connections or related resources that currently constrain parallel sandbox workloads. - Production patterns for sharding large agent or generated-application platforms across Durable Object supervisors. - Whether Cloudflare introduces stronger scheduling, pool-management or lifecycle primitives above the low-level Dynamic Worker API. ## Uncertainties - The change increases one hard concurrency limit but does not establish a proportional throughput improvement because other resources and downstream services may bottleneck first. - Dynamic Workers are a relatively low-level platform primitive, so the benefit is concentrated among builders already using runtime-created Worker sandboxes. - Cloudflare's changelog dates the public announcement August 28 while a Workers changelog entry records the underlying limit update as August 20; the current documented limit is ten. - The higher ceiling does not change the security model or isolation guarantees of an individual Dynamic Worker. ## Sources - [Durable Objects can use up to ten Dynamic Workers concurrently](https://developers.cloudflare.com/changelog/post/2026-08-28-durable-objects-dynamic-workers-limit/) — Cloudflare · primary changelog · 2026-08-28T00:00:00+12:00. Primary announcement for the 4→10 Durable Object Dynamic Worker concurrency increase. - [Dynamic Workers limits](https://developers.cloudflare.com/dynamic-workers/platform/limits/) — Cloudflare · primary documentation · 2026-08-27T00:00:00+12:00. Current Worker-request and Durable Object concurrency semantics and distinct-worker counting. - [Dynamic Workers](https://developers.cloudflare.com/dynamic-workers/) — Cloudflare · primary documentation. Current product scope, sandbox controls and agent/generated-app/automation use cases.