Agent skill · software engineering · jeremylongshore
flyio-rate-limits
Implement Fly.io Machines API pacing, per-resource serialization, retry, and reconciliation from the documented action limits. Use when automating Machine or app operations. Trigger with: "handle Fly 429", "throttle Machines API", "batch Fly Machine updates".
Why this skill is useful
Adds a complete rate limiting implementation with backoff and batching for Fly.io Machines API that isn't in public docs.
What it needs
Requires fly.io account access. About 3k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Fly.io Machines API Rate Control Overview Replace the old invented per-organization table with Fly.io documented limits: Machine actions are constrained per action and per Machine or app identifier, reads have a separate ceiling, and app deletion has its own minute-level limit. Safe workers serialize conflicting operations and reconcile after ambiguous outcomes. Prerequisites Exact API operations, app and Machine identifiers, request volume, and completion objective Durable operation IDs, desired-state fingerprints, retry counts, and acknowledgement state Current rate-limit contract and an error budget for delayed or failed operations Instructions Step 1: Classify each request Separate create, update, start, stop, suspend, delete, wait, list, and get operations; identify whether the provider scopes the action to a Machine ID or app ID. Step 2: Encode the documented ceilings For Machine actions, budget one request per second per action and identifier with a short burst up to three. For get-Machine, budget five per second with a burst up to ten. Treat app deletion as at most 100 per minute. Step 3: Serialize conflicts Permit parallel work across independent identifiers only. Never overlap updates, starts, stops, leases, or deletion for the same Machine without a reconciled state boundary. Step 4: Make intent replay-safe Persist desired-state hash, operation, target, current Machine instance version, attempt, and acknowledgement before sending a mutation. Step 5: Back off on throttling Honor provider retry timing when present; otherwise use bounded exponential backoff with jitter. Apply a retry budget and circuit breaker rather than an unbounded loop. Step 6: Reconcile ambiguous results After timeout or transport failure, read current Machine and instance state before retrying. Mark complete only when observed state matches intent. Authentication Send the scoped token as a bearer header only to the documented public or private Machines API base URL. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/flyio-rate-limits