Skip to main content
To ensure fair distribution of resources and prevent malicious attacks, we currently apply rate limits based on the cumulative recharge amount of each account. The specific limits are shown in the table below.
  • To prevent abuse, you need to recharge at least $1 to start using, and when your cumulative recharge reaches $5, you will receive a $5 voucher.

​
Explanation of Rate Limits Concepts

  • Concurrency: The maximum number of requests from you that we can process at the same time.
  • RPM: Requests per minute, which means the maximum number of requests you can send to us in one minute.
  • TPM: Tokens per minute, which means the maximum number of tokens you can interact with us in one minute.
  • TPD: Tokens per day, which means the maximum number of tokens you can interact with us in one day.
  • Web Search QPS: The maximum number of requests per second you can send to the web search endpoints (/v1/tools/search, /v1/tools/search_pro). This quota is independent of the other columns: it neither consumes nor is consumed by your RPM, TPM, TPD, or concurrency quotas.
For more details, please refer to the Rate Limits section.

​
Web Search Rate Limits

The web search endpoints (/v1/tools/search and /v1/tools/search_pro) are rate limited by the “Web Search QPS” column in the table above, with the following rules:
  • Web Search QPS is independent of the other rate limits in the table: calling the search endpoints only consumes search QPS quota, not RPM, TPM, TPD, or concurrency quota; conversely, usage of chat and other endpoints never consumes search QPS.
  • The two search endpoints are counted independently and do not consume each other’s quota. For example, a Tier1 account can call /v1/tools/search 3 times per second and, at the same time, /v1/tools/search_pro 3 times per second.
  • When a limit is exceeded, the endpoint returns HTTP 429 with X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset response headers, which you can use to back off and retry.
For endpoint pricing, see WebSearch Pricing.

​
Why Do We Implement Rate Limits?

Rate limits are a common practice for API interfaces, and there are several reasons for it:
  • They help prevent abuse or misuse of the API. For example, malicious actors might try to overwhelm the API with a large number of requests, attempting to overload it or cause service disruptions. By setting rate limits, we can guard against such behavior.
  • Rate limits ensure fair access to the API for everyone. If one person or organization sends too many requests, it could slow down the API for everyone else. By limiting the number of requests a single user can send, we ensure that as many people as possible can use the API without experiencing slowdowns.
  • Rate limits help us manage the overall load on our cluster. A sudden surge in requests to the API could put pressure on the servers and lead to performance issues. By setting rate limits, we can maintain a smooth and consistent experience for all users.

​
Special Notes

  • We will do our best to ensure normal usage for users, but when the cluster load reaches its capacity limit, we may take temporary measures to adjust the rate limits.
  • Vouchers do not count towards the cumulative recharge total.
  • When the system detects abnormal activity on an account, a risk-control rate-limiting policy is triggered. Once triggered, the restriction cannot be lifted.