How does the hub handles http error 429?

🤗Hub
1

Hi !

I have trouble trying to experiment with mistralai/Mistral-Small-3.1-24B-Instruct-2503 because any attempt to use it in python code or downloading, either with git clone or huggingface hub CLI throws error codes 429.

I had the issue last thursday, friday, and this monday. I do not face the same issues with other models.

I’m really scrapping my head there so I would like a complete explanation about how and when does HF hub returns that code :
Here are a few questions that came to my mind trying to understand what is going on :

  1. Is the issue on MY side or could the repo itself for the model be rate limited ?
  2. Is the error code used ONLY for rate limits or also when trying to access gated repos without an access token for an account allowed on that model ?
  3. How many failed attempts (e.g. bad token configuration, attempts before getting correct access to a gated repo, etc. ) would trigger that error ?
  4. How long does it takes to revert ? Is there any way to check if its lifted without risking to delay it / get it renewed for another cycle ?
  5. Does it reset when switching from “anonymous” usage (for non gated repos) to using my access token for gated repos. (which would be either a rate limit on the IP or the account ?)
  6. I’m experimenting on a cloud VM, Could I be “poisoned” by rates limits being applied to another VM in the same host network ?

And Lastly… Is it possible that hugging face returns this code because some repos/models requires pro account or enterprise hub ?

2

1

It’s probably because too many requests were made from your IP address or token in a short period of time. I think it’s a restriction on endpoints, including models and various APIs.

2

I’ve only seen 429 (Too Many Requests) on Hugging Face. If it’s Gated, it’s 401, and the rest are mostly 403, 500, 503, and 404. There are also sites that write lies as disguises for server error codes, but HF is not very strange in that regard.

3

It happens quite a few times. If you make a bug in the program and make it loop, it happens quite easily…

4

In my case, it was 24 hours.

5

I think it’s possible to have both token-based and IP-based restrictions. If it’s a token-based restriction, you could get around it by using a different account.
In my case, it was a token-based restriction.

6

Unless it’s particularly malicious, I don’t think there are any restrictions on IP or hostname ranges…

last

I’ve never heard of it…

3

Thanks for your answer ! It was in fact linked to my 6th question… And IPV6

I got the same error with a docker pull which led me in a rabbit hole where I found that some services (including docker hub and hugging face hub) are using rate limit methods intended only for IPv4 and so, are de facto blocking / only checking the first half of IPv6 adresses so it is entire ranges that are blocked at a time…

So as a workaround I can just disable IPV6 in ubuntu /etc/sysctl.conf…