Rate limits

Two shared Redis limits use a 60,000 ms window.

Authenticated workspace budget

Every credential for one workspace spends the same budget. Creating or rotating a credential does not multiply it. A club plan may provide a positive integer limit; absent, invalid, zero, or negative values use the system ceiling, currently 6,000 requests per minute. Values above that ceiling are clamped. Resolved plan values are cached for 30 seconds.

On authenticated responses the workspace guard writes:

X-RateLimit-Limit: 6000
X-RateLimit-Remaining: 5999
X-RateLimit-Reset: 60

X-RateLimit-Limit is the effective request count for the window, X-RateLimit-Remaining is the non-negative balance, and X-RateLimit-Reset is the number of whole seconds until the current Redis window expires. These values are authoritative. The older /v1/me rate_limit field is not the workspace entitlement contract. The same values remain available under RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset as compatibility aliases.

Pre-authentication protection

Before signature verification, every source address spends a separate 12,000 requests per minute budget. It protects signing work and also covers invalid credentials. The authenticated workspace headers overwrite these values after authentication. Both limits are shared across replicas through Redis and fail rather than silently becoming per-process counters.

A refusal returns 429 rate_limit_exceeded and Retry-After. Wait at least that many seconds and use bounded exponential backoff; retries consume budget too.