Rate Limits
Rate limits
A two-layer guard that protects the platform and your account. Below: default caps, what to do when you hit one, and how to request more.
Default quotas
| Dimension | Starter | After top-up | Enterprise |
|---|---|---|---|
| RPM (requests / minute) | 60 | 600 | custom |
| TPM (tokens / minute) | 40k | 400k | custom |
| Concurrency | 5 | 50 | custom |
| Concurrent video tasks | 2 | 10 | custom |
Top up to lift the cap
Your first ¥10 top-up instantly bumps you to the "after top-up" tier — no application needed.
Response headers
Every successful response includes quota info:
httpHTTP/1.1 200 OK X-RateLimit-Limit-Requests: 600 X-RateLimit-Remaining-Requests: 587 X-RateLimit-Reset-Requests: 38s X-RateLimit-Limit-Tokens: 400000 X-RateLimit-Remaining-Tokens: 389234 X-RateLimit-Reset-Tokens: 12s
On 429 you get Retry-After:
httpHTTP/1.1 429 Too Many Requests Retry-After: 12 { "error": { "type": "rate_limit_error", "code": "rate_limit_exceeded", "message": "Rate limit reached. Please retry after 12s." } }
Handling 429
- First: read
Retry-Afterand wait the number of seconds it says. - If absent: exponential back-off
1s → 2s → 4swith ±20% jitter. - Don't hammer: never retry inside the catch immediately — that only extends the 429 window.
- Prevention: cap client-side concurrency 20% below the platform quota to stay clear of the ceiling.
- Horizontal scaling: spread traffic across multiple API keys — they share the same quota, so this does NOT bypass rate limits, but it makes auditing which key burns the most easier.
Enterprise quota lift
For workloads expecting RPM > 1000, TPM > 1M, or concurrency > 100, email [email protected] with:
- expected peak RPM / TPM
- which models you'll mostly use (different models have different upstream quotas)
- whether you need dedicated routing / private deployment / SLA 99.95%+
We typically reply within one business day.