Usage Limits
Per-user Flywheel write limits and how to handle rate-limit responses.
Flywheel limits high-volume writes per user so one runaway job cannot degrade the service for everyone else.
Current Write Limits
| Write type | Limit | Counts toward it |
|---|---|---|
| Node creation | 120 per minute | Creating a new node or branching a node |
| Node creation | 2,000 per 24 hours | Creating a new node or branching a node |
| Graph writes | 120 per minute | Editing, deleting, merging, tagging, sharing, edge changes |
| Graph writes | 2,000 per 24 hours | Editing, deleting, merging, tagging, sharing, edge changes |
| Artifact changes | 120 per minute | Finalizing artifacts, deleting artifacts, editing notes |
Artifact changes count as graph writes. Hook runs created after artifact finalization do not have a separate user-facing quota.
Examples
Creating 100 nodes in one minute is within the node creation limit. Creating 130 nodes in one minute can return a rate-limit response. Creating 2,500 nodes over one day can also return a rate-limit response even if each minute stays under 120 creates.
Editing 80 existing nodes and finalizing 30 artifact batches in one minute is 110 graph writes. That is within the graph-write limit. Doing 130 such writes in one minute can return a rate-limit response. Doing 2,500 graph writes over one day can also return a rate-limit response even if each minute stays under 120 graph writes.
Handling A Limit
When a write is limited, Flywheel returns HTTP 429 with a Retry-After
header. The response body includes:
scope:node_createorgraph_writeperiod:minuteor24hlimit: the matching limitretry_after_seconds: how long to wait before retrying
Clients and scripts should wait for Retry-After, then retry the same
idempotent request. For large imports or generated graph work, pace writes in
small batches instead of sending thousands of writes at once.