Limits

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 — 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 CJS play bundle, enforced at submit time.

Revision storage

Limit	Value	What it means
Persisted play revision metadata	`1 MB`	Maximum Convex-encoded size of one saved play revision, including source, static pipeline, bindings, and metadata. This is separate from the compiled bundle limit.

Run duration

Limit	Value	What it means
Standard play runtime	`30 min`	Maximum active user-code runtime for a standard play run before it is timed out.

Inline composition & budgets

Limit	Value	What it means
Inline composition depth	`8`	Maximum nesting depth for inline `ctx.runPlay(...)` composition. It prevents accidental recursion; `ctx.runPlay` never creates a child run.
Tool-call budget	`5,000,000`	Total `ctx.tool(...)` call budget for a play invocation.

Concurrency

A play run has two independent concurrency layers: map rows (how many rows of a ctx.dataset().map(...) resolve at once — platform-controlled, not configurable per call) and tool calls (outbound provider requests — a global blocking backstop; extra calls wait for a slot rather than failing). Inline ctx.runPlay(...) composes inside its caller and shares both limits; it never creates a separately scheduled child. 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 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
Play return	`5 MiB`	Maximum serialized size of the complete value returned by a play. Arrays have no row-count limit within this byte budget; larger returns fail with OUTPUT_TOO_LARGE instead of being silently truncated.

Runtime sheet

Limit	Value	What it means
Sheet viewport max rows	`5,000`	Maximum rows returnable by a single (non-live) sheet viewport read.

Getting started

Tutorials

How-to guides

Explanations

Real-world examples

Reference

Submit & input

Bundle & compile

Revision storage

Run duration

Inline composition & budgets

Concurrency

Output & logs

Runtime sheet

​Submit & input

​Bundle & compile

​Revision storage

​Run duration

​Inline composition & budgets

​Concurrency

​Output & logs

​Runtime sheet

Submit & input

Bundle & compile

Revision storage

Run duration

Inline composition & budgets

Concurrency

Output & logs

Runtime sheet