|
| 1 | +# Hub Rate limits |
| 2 | + |
| 3 | +To protect our platform's integrity and make sure we are able to scale our service to as many AI community members as possible, we enforce rate limits on all requests made to the HF Hub. |
| 4 | + |
| 5 | +We define different rate limits for distinct classes of requests. We distinguish three main buckets: |
| 6 | + |
| 7 | +- **Hub APIs** |
| 8 | + - e.g. model or dataset search, repo creation, user management, etc. Note: all those endpoints are documented in [Hub API Endpoints](./api). |
| 9 | +- **Resolvers** |
| 10 | + - They're all the URLs that contain a `/resolve/` segment in their path, which serve user-generated content from the Hub. Concretely, those are the URLs that are constructed by open source libraries (transformers, datasets, vLLM, llama.cpp, …) or AI applications (LM Studio, Jan, ollama, …) to download model/dataset files from HF. |
| 11 | + - Because they are very heavily used by the community, and because we optimize our infrastructure to serve them with high efficiency, rate limits for Resolvers are the highest ones. |
| 12 | +- **Pages** |
| 13 | + - All the Web pages we host on huggingface.co. Usually Web browsing is browsing made by humans hence rate limits don't need to be as high as programmatic endpoints like the two former buckets. |
| 14 | + |
| 15 | +> [!TIP] |
| 16 | +> All values are defined over 5-minute windows, which allows for some level of "burstiness" from an application or developer's point of view. |
| 17 | +
|
| 18 | +If you, your organization, or your application need higher rate limits, we encourage you to upgrade your account to PRO, Team, or Enterprise. We prioritize support requests from PRO, Team, and Enterprise customers – see built-in limits in [Rate limit Tiers](#rate-limit-tiers). |
| 19 | + |
| 20 | +## Billing dashboard |
| 21 | + |
| 22 | +At any point in time, you can check your rate limit status on your (or your org)'s Billing page: https://huggingface.co/settings/billing |
| 23 | + |
| 24 | + |
| 25 | + |
| 26 | +On the right side, you will see three gauges, one for each bucket of Rate limiting. |
| 27 | + |
| 28 | +Each bucket presents the number of current (last 5 minutes) requests, and the number of allowed requests based on your user account or organization plan. |
| 29 | + |
| 30 | +Note: You can use the context switcher to easily switch between your user account and your orgs. |
| 31 | + |
| 32 | +## HTTP Headers |
| 33 | + |
| 34 | +Whenever you or your organization hits a rate limit, you will receive a **429** `Too Many Requests` HTTP error. |
| 35 | + |
| 36 | +We implement the mechanism described in the IETF draft titled “RateLimit HTTP header fields for HTTP” (also known as `draft-ietf-httpapi-ratelimit-headers`). |
| 37 | + |
| 38 | +The goal is to define standardized HTTP headers that servers can use to advertise quota / rate-limit policies and communicate current usage / limits to clients so that they can avoid being throttled. |
| 39 | + |
| 40 | +Precisely, we implement the following headers: |
| 41 | + |
| 42 | +| Header | Purpose / Meaning | |
| 43 | +| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | |
| 44 | +| **RateLimit-Policy** | Carries the rate limit policy itself (e.g. “100 requests per 5 minutes”). It’s informative; shows what policy the client is subject to. | |
| 45 | +| **RateLimit-Limit** | The total allowed rate limit for the current window. “How many requests (of this type) you’re allowed.” | |
| 46 | +| **RateLimit-Remaining** | How many requests of this type you have left in the current window. | |
| 47 | +| **RateLimit-Reset** | Number of seconds until the rate limit window resets (or until quota is refreshed). Uses a “delta-seconds” format to reduce clock sync issues. | |
| 48 | + |
| 49 | +## Rate limit Tiers |
| 50 | + |
| 51 | +Here are the current rate limiting values (in September '25) based on your plan: |
| 52 | + |
| 53 | +| Plan | API | Resolvers | Pages | |
| 54 | +| ------------------------------- | ------ | --------- | ----- | |
| 55 | +| Anonymous user (per IP address) | 500 \* | 3,000 \* | 100 \* | |
| 56 | +| Free user | 1,000 \* | 5,000 \* | 200 \* | |
| 57 | +| PRO user | 2,500 | 12,000 | 400 | |
| 58 | +| Team organization | 3,000 | 15,000 | 400 | |
| 59 | +| Enterprise organization | 6,000 | 30,000 | 600 | |
| 60 | +| Enterprise Plus organization | 10,000 | 50,000 | 1,000 | |
| 61 | +| Academia Hub organization | 2,500 | 12,000 | 400 | |
| 62 | + |
| 63 | +\* Subject to change over time depending on platform health 🤞 |
| 64 | + |
| 65 | +## What if I get rate-limited |
| 66 | + |
| 67 | +First, make sure you are always passing a `HF_TOKEN`, and it gets passed downstream to all libraries or applications you might be using that downloads _stuff_ from the Hub. |
| 68 | + |
| 69 | +This is the number one reason users get rate limited and is a very easy fix. |
| 70 | + |
| 71 | +If you're sure you're passing a `HF_TOKEN`, you can: |
| 72 | +- spread out your requests over longer periods of time |
| 73 | +- replace Hub API calls with Resolver calls, whenever possible (Resolver rate limits are much higher and much more optimized). |
| 74 | +- upgrade to PRO, Team, or Enterprise. |
| 75 | + |
| 76 | +## Granular user action Rate limits |
| 77 | + |
| 78 | +In addition to those main classes of rate limits, we enforce limits on certain specific kinds of user actions, like: |
| 79 | + |
| 80 | +- repo creation |
| 81 | +- repo commits |
| 82 | +- discussions and comments |
| 83 | +- moderation actions |
| 84 | +- etc. |
| 85 | + |
| 86 | +We don't currently document the rate limits for those specific actions, given they tend to change over time more often. If you get quota errors, we encourage you to upgrade your account to PRO, Team, or Enterprise. |
| 87 | +Feel free to get in touch with us via the support team. |
0 commit comments