# Rate Limits for Runner and App Management By Steven Van · 2026-10-13 The limits cover CLI, Python SDK and REST management calls; requests to app endpoints are unaffected. Calls that manage apps and runners on [fal]() now have per-minute limits across the CLI, Python SDK and REST API. The limits protect the shared control plane and do not apply to requests that call app endpoints. ## Limits by operation Calls are counted separately for each client in a one-minute window. A CLI command and its corresponding Python SDK method share the same limit. - Listing apps or runners: 120 calls per minute. - Listing an app’s runners: 300 calls per minute. - Runner logs: 120 calls per minute. - Runner shell or exec: 90 calls per minute. - Stopping runners: 60 calls per minute. - Killing runners: 300 calls per minute. The REST endpoints GET /runners and GET /runners/{runner\_id} each allow 120 calls per minute. The CLI’s logs command fetches runner details once before showing logs, and that call counts toward the runner-detail endpoint’s limit. ## Handling rejected calls Exceeding a limit returns 429 Too Many Requests through REST, or RESOURCE\_EXHAUSTED through the CLI and Python SDK. Both include an x-ratelimit-reset header giving the seconds until the window resets. For gRPC calls, it is available in trailing metadata. The CLI and SDK do not retry automatically. Code must wait until the window resets and retry the rejected call. If a stop or kill call is rejected, the runner continues to run. The [rate-limit documentation]() recommends spacing out polling calls, fetching all runners for an app in one list call, and spreading large batches of stop or kill calls over time. [![]()]() ![fal]() fal A generative media platform and inference API for running fast image, video, and audio AI models at scale. [View fal →]() [Original source]() [Read Rate Limits for Runner and App Management on Creators Toolbox]() --- Canonical source: https://creatorstoolbox.com/blog/fal-rate-limits-for-runner-and-app-management