The two scopes
A per-key cap can never exceed the org bucket: the org-tier bucket is the hard upper bound, and per-key limits are carved out beneath it. Raising a per-key cap above what the org’s tier allows is a tier-gated feature, not a per-key setting.
Per-org request limits
Requests-per-minute and daily request caps are enforced on a per-org bucket, shared by every API key in the org, and scale by your API tier:
Tiers not listed fall through to the default (60 RPM / 5,000 daily). Issuing more keys does not raise the bucket. A per-key ceiling can be configured on top of this, but it can only tighten what that key may draw — never exceed the org bucket.
Tokens per minute
The tokens-per-minute column above is the org-level ceiling that per-key TPM caps are carved out beneath. A per-key cap can tighten it for that key; it can never exceed it.Handling 429
When a limit is hit, the response is a 429 with a retryable error:
Retry-After header (RFC 6585) carries the wait in seconds. To handle 429 correctly:
1
Read Retry-After
Wait the number of seconds in the
Retry-After header before retrying.2
Back off if no value is present
If neither is set, use exponential backoff with a ceiling rather than retrying immediately.
3
Respect the bucket
Persistent
429s mean you are at the org or tier ceiling — spread load over time or move up a tier rather than retrying harder.X-RateLimit-Remaining-Requests, X-RateLimit-Reset-Requests, and token-level equivalents) so you can throttle proactively before hitting a limit.
Spend cap is a separate limit
A dollar spend cap is independent of RPM/TPM — it protects the bill across a billing cycle, not against burst traffic. When the cap is reached, requests return402 AI_CREDITS_EXHAUSTED with an error.details.cycle_reset_at timestamp. Spend caps are configured in Settings → Billing.
Full reference
For response-header details and per-org aggregate RPM figures, see the AI API rate-limits reference:AI API Rate Limits
The full three-layer model, response headers, and the spend-cap behavior.