Runway · Rate Limits

Runwayml Rate Limits

Runway governs the developer API through per-organization usage tiers rather than a single published global rate limit. Tiers set how many generation tasks you can have running concurrently (per model) and your request throughput; organizations move up tiers with spend / usage history, and higher limits are available by exception for enterprise customers. Because generation is asynchronous, the practical constraint is task concurrency and your credit balance, not a per-minute request cap. Clients polling GET /tasks/{id} should not poll more than once every five seconds per task.

Runwayml Rate Limits is the machine-readable rate-limit profile for Runway on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring concurrent_tasks, requests, and credits.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Video Generation, AI Video, Generative AI, Rate Limiting, and Quotas.

4 Limits Throttle: 429
Video GenerationAI VideoGenerative AIRate LimitingQuotas

Limits

Task Concurrency organization
concurrent_tasks
per usage tier (per model)
The main constraint - how many generation tasks can run at once, set by your org's usage tier and model.
Request Rate organization
requests
per usage tier
Request throughput is governed by tier; no single fixed global per-minute number is published.
Task Polling task
requests
<= 1 poll / 5 seconds per task
Runway advises not expecting task updates more often than once every five seconds for a given task.
Credit Balance organization
credits
prepaid balance
Tasks are billed in credits; an empty balance blocks new billable generation tasks.

Policies

Usage Tiers
Concurrency and rate limits scale by organization usage tier; higher limits available by exception for enterprise.
Backoff Strategy
On 429, back off with exponential delay and jitter and honor any Retry-After header before retrying.
Asynchronous Draining
Prefer increasing task concurrency headroom over aggressive polling; poll each task no more than once every five seconds.

Sources