> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Limits > Hard limits on the Deepline plays runtime: submission and bundle sizes, run duration, nested-play depth, concurrency, and output caps. These are the hard limits that bound a single play run. They protect the platform (and your run) from runaway resource use, so a misbehaving play fails fast with a clear error instead of hanging or starving other work. 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](https://code.deepline.com) — 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 a `ctx.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. |