SiliconFlow Free Tier and AI API Rate Limits Compared: OpenAI, Anthropic, DeepSeek, DashScope (2026)
Compare SiliconFlow's free tier and usage levels against OpenAI, Anthropic, DeepSeek, and DashScope rate limits. This 2026 guide breaks down RPM, TPM, burst behavior, and upgrade paths so production teams can route around throughput ceilings before 429 errors hit users.
Rate limits determine how many requests and tokens your application can push through an LLM API per minute. They vary wildly across providers — from OpenAI's five-tier system to DeepSeek's concurrency-only model — and understanding these differences is essential for production routing decisions.
We compared rate-limit structures across OpenAI, Anthropic, DeepSeek, DashScope (Alibaba Cloud Model Studio), and SiliconFlow. This page is the reference we built for our own fallback routing configuration, and we keep it updated as providers change their limits.
TL;DR — Rate Limit Comparison Table
| Provider | Limit model | Key metrics | Tier structure | Entry-level RPM | Entry-level TPM | Burst policy | Upgrade path |
|---|---|---|---|---|---|---|---|
| OpenAI | Tier-based (Free–Tier 5) | RPM, TPM, RPD, TPD | 6 tiers by cumulative spend | ~500 RPM (Tier 1, GPT-5) | ~30K TPM | Per-second enforcement possible | Auto-upgrade on spend thresholds |
| Anthropic | Tier-based (Start–Custom) | RPM, ITPM, OTPM | 4 tiers by usage history | 50 RPM (Start) | 40K ITPM / 8K OTPM | Token bucket algorithm | Auto-upgrade; Custom by arrangement |
| DeepSeek | Concurrency-based | Concurrent connections | No tiers — flat per account | N/A (no RPM cap) | N/A (no TPM cap) | Queue + keep-alive | Free capacity expansion on request |
| DashScope | Per-model, account-level | RPM, TPM (+ RPS, TPS) | No formal tiers; expandable | 500–1,200 RPM (varies by model) | 500K–2M TPM | Per-second burst enforcement | Console self-service temp increase |
| SiliconFlow | Usage-level tiers (L0–L4) | RPM, TPM, RPD, TPD | 5 levels by monthly spend (RMB) | 100–1,000 RPM (free models fixed) | 50K–500K TPM | RPM/TPM whichever hits first | Auto-upgrade on monthly spend |
Data retrieved June 30, 2026. OpenAI from developers.openai.com. Anthropic from platform.claude.com. DeepSeek from api-docs.deepseek.com. DashScope from alibabacloud.com. SiliconFlow from docs.siliconflow.cn.
What Are API Rate Limits and Why They Matter
OpenAI-compatible means a provider exposes a chat-completions endpoint whose request and response shape matches the OpenAI API contract closely enough that an unmodified OpenAI SDK call works against it after swapping three values: API key, base URL, and model name. The minimum surface in practice is POST /v1/chat/completions with messages, model, and an OpenAI-shaped streaming response.
Rate limits cap how many requests (RPM) and tokens (TPM) your organization can send to an API within a time window — usually per minute. They exist because GPU compute is finite: without limits, one heavy user could starve everyone else.
For routing decisions, rate limits matter as much as pricing. A provider charging $1/M tokens is useless if their rate limits cap you at 10 RPM during peak hours. The practical questions are:
- How many concurrent users can my application serve before hitting 429 errors?
- If I hit a limit, how quickly does it recover?
- Can I increase limits without switching to enterprise contracts?
- Does the provider count cached tokens toward my limit?
Each provider answers these differently. Let's break them down.
OpenAI: Five-Tier System by Cumulative Spend
OpenAI uses the most structured approach: six tiers (Free through Tier 5) based on how much you've cumulatively paid. Each tier unlocks higher RPM and TPM limits across all models.
Tier qualification thresholds
| Tier | Qualification | Monthly usage limit |
|---|---|---|
| Free | Allowed geography | $100/month |
| Tier 1 | $5 paid | $100/month |
| Tier 2 | $50 paid | $500/month |
| Tier 3 | $100 paid | $1,000/month |
| Tier 4 | $250 paid | $5,000/month |
| Tier 5 | $1,000 paid | $200,000/month |
Key characteristics:
- Organization-level and project-level limits. All API keys under an organization share the same quota. Projects can have their own sub-limits.
- Model-specific within tiers. GPT-5.5 at Tier 1 has different limits than GPT-4o at Tier 1. Heavier models get stricter caps.
- Shared limits for model families. Some models share a combined TPM pool — calling any model in the family draws from the same bucket.
- Long-context surcharge. Models like GPT-5.5 with large context windows have separate, lower rate limits for long-context requests.
- Auto-upgrade. As your cumulative spend crosses a threshold, you graduate to the next tier automatically.
Rate limit headers
OpenAI returns rate-limit state in every response:
x-ratelimit-limit-requests: 60
x-ratelimit-remaining-requests: 59
x-ratelimit-reset-requests: 1s
x-ratelimit-limit-tokens: 150000
x-ratelimit-remaining-tokens: 149984
x-ratelimit-reset-tokens: 6m0s
This makes client-side throttling straightforward — you can read remaining capacity and back off before hitting 429.
Source: OpenAI Rate Limits documentation, retrieved June 30, 2026.
Anthropic: Unified Tier Model with Cache-Aware Limits
Anthropic's Claude API uses a four-tier system (Start, Build, Scale, Custom) with a distinctive feature: cached input tokens don't count toward your ITPM limit for most models.
Tier structure
| Tier | Monthly spend cap | RPM (typical) | ITPM (typical) | OTPM (typical) |
|---|---|---|---|---|
| Start | $500 | 50 | 40,000 | 8,000 |
| Build | $1,000 | 1,000 | 400,000 | 80,000 |
| Scale | $200,000 | 4,000 | 2,000,000 | 400,000 |
| Custom | Negotiated | Negotiated | Negotiated | Negotiated |
Key characteristics:
- Separate input and output token limits. Anthropic splits TPM into ITPM (input tokens per minute) and OTPM (output tokens per minute), giving you clearer visibility into which dimension you're constrained by.
- Cache-aware ITPM. Only uncached input tokens and cache-creation tokens count toward ITPM.
cache_read_input_tokensdo not. With an 80% cache hit rate, your effective throughput is 5x the nominal ITPM. This is a significant advantage for workloads with large system prompts or shared context. - Token bucket algorithm. Capacity refills continuously rather than resetting at fixed intervals. This means short bursts are tolerated as long as your average rate stays under the limit.
- Acceleration limits. Even within your tier, a sudden spike in traffic can trigger 429 errors. Anthropic recommends ramping up gradually.
- Workspace-level customization. You can set per-workspace limits below your org's tier cap for cost control.
Exception: Claude Haiku 3.5 counts
cache_read_input_tokenstoward ITPM. All other models exempt cached reads.
The cache-aware approach means that applications using prompt caching effectively get much higher throughput than the raw numbers suggest.
Source: Anthropic Rate Limits documentation, retrieved June 30, 2026.
DeepSeek: Concurrency-Based, No RPM/TPM Caps
DeepSeek takes a fundamentally different approach: no RPM or TPM limits at all. Instead, they enforce concurrency caps — the maximum number of simultaneous in-flight requests.
Concurrency limits
| Model | Concurrency limit |
|---|---|
| deepseek-v4-pro | 500 |
| deepseek-v4-flash | 2,500 |
Key characteristics:
- No RPM or TPM. You can send as many requests as you want per minute, as long as you don't exceed concurrent connections.
- Connection = in-flight request. A request counts toward concurrency from the moment it's sent until the response completes. Streaming responses hold a connection for the entire duration.
- Account-level, not key-level. All API keys under one account share the concurrency pool.
- Graceful degradation. When servers are under load, DeepSeek doesn't reject requests — it slows them down. You'll receive keep-alive signals (empty lines for non-streaming,
: keep-aliveSSE comments for streaming) while waiting. - 10-minute timeout. If inference hasn't started after 10 minutes, the connection is closed.
- Free capacity expansion. If 500/2,500 concurrent connections aren't enough, you can request higher limits at no extra cost through a Feishu form. DeepSeek sizes the increase based on your actual usage.
The concurrency model is conceptually simpler than RPM/TPM tiers, but it requires different client-side handling. You need to track how many requests are in flight rather than counting requests per minute.
user_id isolation
DeepSeek supports per-user isolation via the user_id parameter:
response = client.chat.completions.create(
model="deepseek-v4-pro",
messages=[{"role": "user", "content": "Hello!"}],
extra_body={"user_id": "your_user_id"}
)
For accounts with expanded concurrency, each user_id gets its own sub-limit (500 for V4 Pro, 2,500 for V4 Flash), preventing one heavy user from starving others.
Source: DeepSeek Rate Limit & Isolation, retrieved June 30, 2026.
DashScope (Alibaba Cloud): Per-Model Limits with Self-Service Expansion
DashScope applies rate limits at the account level, per model. There's no formal tier system — instead, you get default limits that you can expand through the console.
Default limits (representative models)
| Model | Default RPM | Default TPM |
|---|---|---|
| qwen-plus (latest) | 1,200 | 2,000,000 |
| qwen-max (latest) | 500 | 500,000 |
| qwen-turbo (latest) | 1,200 | 2,000,000 |
| qwen3.7-max | 500 | 500,000 |
| Dated snapshots | Lower than stable/latest | Lower than stable/latest |
Key characteristics:
- Account-level aggregation. All RAM users, workspaces, and API keys under one Alibaba Cloud account share the same quota per model.
- Per-second enforcement. In addition to RPM and TPM, DashScope enforces RPS (RPM/60) and TPS (TPM/60). A burst of 100 requests in one second can trigger limiting even if you're under RPM for the minute.
- Stable > snapshot limits. Using the
latestor stable model alias gives you higher limits than pinning to a dated snapshot likeqwen-plus-2025-07-14. - Self-service expansion. You can increase temporary TPM quotas directly in the Model Studio console. Increases take effect immediately and last 30 days.
- Batch API bypass. DashScope's Batch API is not subject to real-time rate limits — useful for offline processing.
The per-model design means you're less likely to hit limits from a single model, but you need to track limits separately for each model you use. There's no single "account limit" that applies across all models.
Source: Alibaba Cloud Model Studio Rate Limiting, retrieved June 30, 2026.
SiliconFlow: Usage-Level Tiers with Free Model Fixed Limits
SiliconFlow uses a tiered system based on monthly RMB spending, with separate handling for free and paid models.
Usage level qualification
| Level | Monthly spend (RMB) |
|---|---|
| L0 | < ¥50 |
| L1 | ≥ ¥50 |
| L2 | ≥ ¥500 |
| L3 | ≥ ¥2,000 |
| L4 | ≥ ¥10,000 |
Rate limits by model type
| Model category | Metrics | Typical range |
|---|---|---|
| Chat (language models) | RPM, TPM | RPM: 1,000–10,000; TPM: 50,000–5,000,000 |
| Embedding (vector models) | RPM, TPM | RPM: 2,000–10,000; TPM: 500,000–10,000,000 |
| Reranker | RPM, TPM | RPM: 2,000; TPM: 500,000 |
| Image generation | IPM, IPD | IPM: 2+; IPD: 400+ |
Key characteristics:
- Free models: fixed limits. Free model rate limits don't change with your usage level. They're static and relatively low.
- Paid models: level-dependent. Higher monthly spend unlocks higher RPM and TPM across paid models. The same model available in both free and paid tiers (e.g.,
Qwen/Qwen2.5-7B-Instructvs.Pro/Qwen/Qwen2.5-7B-Instruct) has different limits. - Account-level, per-model. Like DashScope, limits apply per model per account. Exceeding the limit on one model doesn't affect others.
- Auto-upgrade. When your monthly spend crosses a threshold, you're upgraded to the next level immediately.
SiliconFlow is most interesting for its free-tier models, where the fixed rate limits can be a bottleneck for production use. For paid models, the limits are generally generous enough for most workloads at L1+.
Source: SiliconFlow Rate Limits, retrieved June 30, 2026.
Decision Tree: When Rate Limits Should Drive Provider Selection
Rate limits should influence your provider choice in these scenarios:
-
High-concurrency real-time applications (chatbots, coding assistants): DeepSeek's concurrency model or DashScope's high default RPM are better fits than OpenAI Tier 1.
-
Large-context workloads with repeated prompts: Anthropic's cache-aware ITPM gives you 5x+ effective throughput if you cache system prompts. OpenAI also supports prompt caching but counts all tokens toward TPM.
-
Batch/offline processing: DashScope's Batch API and OpenAI's Batch API both bypass real-time rate limits. DeepSeek's lack of RPM caps also works well for batch workflows.
-
Budget-constrained startups: SiliconFlow's free models have fixed but usable limits. DeepSeek's free capacity expansion means you can scale without spending more.
-
Enterprise with predictable high volume: Anthropic Custom tier and OpenAI Tier 5 offer the highest limits, but require significant spend history. DashScope's self-service expansion can be faster to get.
The fallback routing angle
Rate limits are a primary reason to configure multi-provider fallback routing. When Provider A returns 429, your application should automatically retry through Provider B. TheRouter supports provider/model routing and fallback when live product paths support it — configuring a priority chain means rate-limit errors on one provider trigger automatic failover to the next.
This is especially effective when combining providers with different limit models: if OpenAI rate-limits you on RPM, a DeepSeek fallback (which has no RPM cap) can absorb the overflow.
Handling 429 Errors: Provider-Specific Strategies
Every provider returns HTTP 429 when you exceed limits, but the recovery mechanics differ:
| Provider | 429 behavior | Recovery | Retry header |
|---|---|---|---|
| OpenAI | Immediate rejection | Continuous refill (token bucket) | retry-after |
| Anthropic | Immediate rejection | Continuous refill (token bucket) | retry-after |
| DeepSeek | Rejection only on concurrency overflow | Instant (when a connection frees up) | Standard HTTP |
| DashScope | Rejection on RPM, TPM, or RPS | Usually within 1 minute | Error code in body |
| SiliconFlow | Rejection on RPM, TPM, RPD, or TPD | Depends on which metric (minute vs. day) | Standard HTTP |
Best practices across all providers:
import time
from openai import OpenAI, RateLimitError
client = OpenAI(base_url="https://your-provider.com/v1", api_key="...")
def call_with_backoff(messages, max_retries=5):
for attempt in range(max_retries):
try:
return client.chat.completions.create(
model="your-model",
messages=messages
)
except RateLimitError as e:
wait = min(2 ** attempt, 60)
print(f"Rate limited, waiting {wait}s...")
time.sleep(wait)
raise Exception("Max retries exceeded")
FAQ
Q: Which provider has the highest rate limits out of the box?
DeepSeek has no RPM or TPM limits at all — only concurrency caps of 500 (V4 Pro) and 2,500 (V4 Flash). For RPM-based providers, DashScope offers up to 1,200 RPM on Qwen-Plus and Qwen-Turbo by default.
Q: Can I increase rate limits without upgrading to enterprise?
Yes. DeepSeek offers free concurrency expansion on request. DashScope has self-service temporary TPM increases in the console. OpenAI auto-upgrades as you spend more. Anthropic requires contacting sales for Custom tier.
Q: Do cached tokens count toward rate limits?
It depends. Anthropic excludes cache_read_input_tokens from ITPM for most models — a major advantage for cached workloads. OpenAI and DashScope count all tokens. DeepSeek has no token-based limits at all.
Q: How do rate limits affect multi-provider routing?
Rate limits are a primary trigger for fallback routing. When one provider returns 429, your routing layer should retry through an alternative provider. Combining providers with different limit models (e.g., OpenAI RPM + DeepSeek concurrency) gives you broader effective capacity. TheRouter supports provider/model routing and fallback when live product paths support it.
Q: Which provider is best for high-volume batch processing?
DashScope and OpenAI both offer dedicated Batch APIs that bypass real-time rate limits. DeepSeek's concurrency model also works well for batch workflows since there's no RPM cap.
Q: How do Chinese provider rate limits compare to Western providers?
Chinese providers (DashScope, SiliconFlow) generally offer higher default RPM than Western providers at equivalent spend levels. DashScope's 1,200 RPM default on Qwen-Plus exceeds OpenAI's Tier 1 limits for comparable models. SiliconFlow's paid tiers offer up to 10,000 RPM for language models.
Related Resources
- LLM API Fallback Routing Guide — how to configure multi-provider fallback to absorb rate-limit errors
- OpenAI Prompt Caching Cost Optimization Guide — how caching affects both cost and effective rate limits
- DeepSeek API Complete Guide — full DeepSeek API walkthrough including concurrency management
- Aliyun Bailian API Guide — DashScope setup and configuration
- SiliconFlow Free Models Routing Guide — SiliconFlow free tier and routing
- Anthropic Claude API Complete Guide — Claude API setup including rate-limit tier management
- OpenAI provider page — OpenAI models available through TheRouter
- Anthropic provider page — Anthropic models available through TheRouter
- DeepSeek provider page — DeepSeek models available through TheRouter