These values are generated directly from the runtime source, so this page is always current. Need a higher limit for a specific workload? Get in touch — most are raised per workspace.
Submit & input
| Limit | Value | What it means |
|---|---|---|
| Inline input file size | 64 KiB | Largest CSV/file input that can be sent inline with a run submission. Bigger inputs must be staged with plays files stage and passed by handle. |
| Inline submission threshold | 100 KB | Submitted input at or below this size stays inline in coordinator state. Above it (up to the hard ceiling) the input is externalized to a short-lived artifact automatically. |
| Maximum submitted input | 1 MiB | Absolute ceiling on a single submission’s input/retry state. Larger payloads must use staged files or ctx.csv inputs. |
| Synchronous wait ceiling | 15 s | How long the run endpoint blocks for a synchronous result before returning a pending handle to poll or stream. |
Bundle & compile
| Limit | Value | What it means |
|---|---|---|
| Compiled play bundle (hard cap) | 30 MiB | Absolute ceiling on a compiled play bundle across all artifact kinds, enforced at submit time. |
| Workers bundle (local cap) | 1.15 MB | Tighter ceiling for the Cloudflare esm_workers artifact. The local Worker Loader silently fails to instantiate larger bundles, so this is surfaced as a hard, actionable failure at submit time. |
Run duration
| Limit | Value | What it means |
|---|---|---|
| Standard play runtime | 20 min | Maximum active user-code runtime for a standard play run before it is timed out. |
Nested plays & budgets
| Limit | Value | What it means |
|---|---|---|
| Nested play depth | 8 | Maximum nesting depth for ctx.runPlay(...) chains. Threaded through every child launch and enforced on both execution substrates. |
| Child plays per parent | 100,000 | Maximum direct child plays a single play may launch. |
| Play-call budget | 100,000 | Total ctx.runPlay(...) budget counted along a root-to-leaf branch. |
| Nested-play descendants | 100,000 | Total nested-play descendants created during a run. |
| Tool-call budget | 5,000,000 | Total ctx.tool(...) call budget for a play invocation. |
Concurrency
A play run has three independent concurrency layers, from outermost to innermost: map rows (how many rows of actx.dataset().map(...) resolve at once — platform-controlled, not configurable per call), tool calls (outbound provider requests — a global blocking backstop; extra calls wait for a slot rather than failing), and child plays (ctx.runPlay(...) launches — excess launches block until a slot frees). All three are identical across execution substrates: a single shared policy governs both, so they cannot drift. Per-provider rate pacing — not these counters — is the real outbound throughput governor.
| Limit | Value | What it means |
|---|---|---|
| Map row concurrency | 1,000 | How many rows of a dataset map resolve their fields at once. Platform-controlled — not configurable per call. Pure-compute maps run on a separate fast path and are not bound by this. |
| Concurrent child plays | 32 | Maximum concurrently in-flight child plays (ctx.runPlay(...)). Identical on both execution substrates; excess launches block until a slot frees up. |
| Concurrent tool calls | 256 | Global backstop on concurrently in-flight tool calls within a play run. A blocking ceiling: extra tool calls wait for a slot rather than failing. Per-provider rate pacing is the real throughput governor. |
Output & logs
| Limit | Value | What it means |
|---|---|---|
| Run result payload (per event) | 2 MiB | Maximum serialized size of a run-event result payload persisted to the run ledger. Larger results are trimmed; full rows live in the runtime sheet. |
Runtime sheet
| Limit | Value | What it means |
|---|---|---|
| Sheet viewport max rows | 5,000 | Maximum rows returnable by a single (non-live) sheet viewport read. |