Every provider throttles differently: OpenAI by spend-earned tiers, Anthropic by published per-model token budgets, Gemini by daily caps and rolling spend windows. This is the reference we wished existed — transcribed from each provider's own docs and dated, so you can tell what will actually stop your agent.
Agents multiply every dimension at once: parallel tool calls burn requests-per-minute, long contexts burn tokens-per-minute, and always-on loops burn daily caps. Provider limits are organization-wide, so several agents share one pool — one busy agent can starve the rest.
It depends on your tier and dimension. Anthropic publishes full per-model tables (up to 10,000 RPM and 10M input tokens/min at Scale tier); OpenAI's limits scale with cumulative spend to Tier 5; Gemini offers the most generous free tier but enforces daily request caps that hit always-on agents hardest.
Exponential backoff with jitter, request batching, prompt caching (on Anthropic, cache reads don't count toward input limits at all), spreading load across models, and moving non-interactive work to batch APIs. Or remove the constraint class entirely with a flat-rate gateway that paces heavy use instead of rejecting it.
No — at every major provider, limits apply at the organization or project level. Creating more keys does not create more capacity.
Full disclosure: this reference is maintained by Standard Compute, a flat-rate gateway built on a different trade-off — no RPM, TPM, or daily caps; sustained heavy use is paced gradually instead of rejected with 429s. If your agent's problem is the limits themselves rather than tuning around them, that's the class of fix. If per-token pricing with headroom suits you, the tables above are kept honest either way.