#Rate Limits & Concurrency

Limits come in three layers: account concurrency, key-level limits, and team member quotas. Hitting a limit returns 429 (throttling) or 403 (team quota). This page covers how to check, tune, and raise each layer.

#The three layers

The dashboard's RPM / TPM metrics (requests / tokens per minute) are observations, not limits — use them to gauge your load.

#What hitting a limit looks like

Full list in Error Codes.

#Behaviour that gets auto-deprioritised

These patterns are not violations, but the system automatically deprioritises or temporarily throttles them (see the Acceptable Use Policy):

• Abnormally high concurrency in short bursts, dense retries without backoff;
• Sustained streams of clearly invalid requests (large volumes of consecutive 4xx).

Adding exponential backoff to your retry logic avoids this entirely; normal traffic peaks are unaffected.

#Raising your limits

#Practices that avoid throttling

• Bound client concurrency: semaphores / connection pools to cap in-flight requests;
• Back off on failure: 429 / 5xx at 1s → 2s → 4s, 3–5 attempts max;
• Smooth the peaks: feed bulk jobs through a queue at a steady rate instead of bursting;
• Split keys by workload: separate keys per business line — quotas don't contend, and per-key usage is easy to watch (key usage lookup).

#Related

• Advanced API Usage — code-level retry and timeout advice
• Error Codes — full 429 / 403 / 402 scenarios
• Teams — member quota mechanics
• Redemption Codes — concurrency boosts