Skip to main content

​
What are Usage Tiers?

Usage tiers determine your rate limits and access to beta features based on your cumulative API spending. As you spend more on API credits over time, you automatically advance to higher tiers with increased rate limits. Higher tiers unlock significantly more requests per minute, and once you reach a tier, you keep it permanently with no downgrade.
You can check your current usage tier by visiting your API settings page.

​
Tier Progression

TierTotal Credits PurchasedStatus
Tier 0$0New accounts, limited access
Tier 1$50+Light usage, basic limits
Tier 2$250+Regular usage
Tier 3$500+Heavy usage
Tier 4$1,000+Production usage
Tier 5$5,000+Enterprise usage
Tiers are based on cumulative purchases across your account lifetime, not current balance.

Need Higher Rate Limits?

Need custom rate limits beyond your current tier? Fill out our rate limit increase request form and we’ll review your use case to accommodate your needs.

​
Agent API Rate Limits

The Agent API uses tier-based rate limits that scale with your usage tier:
TierQPS (Queries per Second)Requests per Minute
Tier 01 QPS50/min
Tier 13 QPS150/min
Tier 28 QPS500/min
Tier 317 QPS1,000/min
Tier 433 QPS2,000/min
Tier 533 QPS2,000/min

​
Search API Rate Limits

The Search API has separate rate limits that apply to all usage tiers:
EndpointRate LimitBurst Capacity
POST /search50 requests per second50 requests
Search Rate Limiter Behavior:
  • Burst: Can handle 50 requests instantly
  • Sustained: Exactly 50 QPS average over time
Search rate limits are independent of your usage tier and apply consistently across all accounts using the same leaky bucket algorithm.

​
Sonar API Rate Limits

The Sonar API uses tier-based rate limits that scale with your usage tier:
ModelRequests per minute (RPM)
sonar-deep-research5
sonar-reasoning-pro50
sonar-pro50
sonar50
POST /async/chat/completions5
GET /async/chat/completions3000
GET /async/chat/completions/{request_id}6000

​
How Rate Limiting Works

Our rate limiting system uses a leaky bucket algorithm that allows for burst traffic while maintaining strict long-term rate control.

​
Technical Implementation

The leaky bucket algorithm works like a bucket with a small hole in the bottom:
  • Bucket Capacity: Maximum number of requests you can make instantly (burst capacity)
  • Leak Rate: How quickly tokens leak out of the bucket (your rate limit)
  • Token Refill: Tokens refill continuously at regular intervals based on your rate limit
This design allows legitimate burst traffic when you need it, prevents sustained abuse, and ensures predictable and fair rate enforcement across all users.
Let’s examine how 50 requests per second works in practice. With a capacity of 50 tokens and a leak rate of 50 tokens per second, one token refills every 20ms.Scenario 1: Burst Traffic
Time 0.0s: Bucket full (50 tokens)
→ Send 50 requests instantly → ALL ALLOWED
→ Send 51st request → REJECTED (bucket empty)

Time 0.020s: 1 token refilled
→ Send 1 request → ALLOWED
→ Send 2nd request → REJECTED

Time 0.040s: 1 more token refilled
→ Send 1 request → ALLOWED
Scenario 2: Steady 50 QPS
Request every 20ms:
Time 0.0s: Request → ALLOWED (50→49 tokens)
Time 0.020s: Request → ALLOWED (49+1-1=49 tokens)
Time 0.040s: Request → ALLOWED (49+1-1=49 tokens)
... maintains 49-50 tokens, all requests pass
Scenario 3: Slightly Over 50 QPS
Request every 19ms (≈52.6 QPS):
→ Eventually tokens deplete faster than refill
→ Some requests start getting rejected
→ Achieves exactly 50 QPS on average
The leaky bucket design means you can handle your full rate limit instantly, making it perfect for batch operations or sudden traffic spikes. There’s no need to artificially spread requests when you have available burst capacity.The system enforces strict average rate limits over time while allowing quick recovery after burst usage. This provides consistent performance across different usage patterns and prevents sustained over-limit usage while maintaining fair resource allocation.When building your application, take advantage of burst capacity for batch operations, monitor your usage patterns to optimize request timing, and implement proper error handling for 429 responses.

​
What Happens When You Hit Rate Limits?

When you exceed your rate limits:
  1. 429 Error - Your request gets rejected with “Too Many Requests”
  2. Continuous Refill - Tokens refill continuously based on your rate limit
  3. Immediate Recovery - New requests become available as soon as tokens refill
Example Recovery Times:
  • 50 QPS limit: 1 token refills every 20ms
  • 500 QPS limit: 1 token refills every 2ms
  • 1,000 QPS limit: 1 token refills every 1ms
Best Practices:
  • Monitor your usage to predict when you’ll need higher tiers
  • Consider upgrading your tier proactively for production applications
  • Implement exponential backoff with jitter in your code
  • Take advantage of burst capacity for batch operations
  • Don’t artificially spread requests if you have available burst capacity

​
Upgrading Your Tier

1

Check Current Tier

Visit your API settings page to see your current tier and total spending.
2

Purchase More Credits

Add credits to your account through the billing section. Your tier will automatically upgrade once you reach the spending threshold.
3

Verify Upgrade

Your new rate limits take effect immediately after the tier upgrade. Check your settings page to confirm.
4

Need Even Higher Limits?

If you require custom rate limits beyond Tier 5, fill out our rate limit increase request form and we’ll review your use case to accommodate your needs.
Higher tiers significantly improve your API experience with increased rate limits, especially important for production applications.