AutoTrain 429 Apocalypse: Token Verification Meltdown on Windows 11

🤗AutoTrain
1

Greetings from the edge of the galaxy—or at least from my Windows 11 rig, where I’m battling an AutoTrain crisis worthy of a sci-fi blockbuster. I’m armed with a write token, PowerShell wizardry, and a dream of training models without the universe imploding, but alas, your API is throwing a 429 Too Many Requests tantrum, followed by a melodramatic “Invalid token” sob story. I’m pretty sure I didn’t sign up for this level of intergalactic drama, so let’s unpack this mess.

Here’s the saga in all its glory: I’m running autotrain app—stock settings, no tweaks, straight out of the box—via PowerShell on Windows 11, because I’m a rebel who believes in defaults until they betray me. I’ve set my shiny write token (yes, WRITE, not some lowly read-only peasant token) using every trick in the book:
$env:HF_TOKEN = “hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” for the session, because I’m a PowerShell poet.

[System.Environment]::SetEnvironmentVariable(“HF_TOKEN”, “hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”, [System.EnvironmentVariableTarget]::User) for the long haul, because I’m committed.

I’ve checked it with $env:HF_TOKEN, and it’s there, gleaming like a supernova. huggingface-cli whoami even salutes back with my username, proving the token’s legit. So far, so epic, right? WRONG. Cue the error logs from March 21, 2025 (yes, I’m timestamping this like a time traveler):
ERROR | 2025-03-21 06:23:14 | autotrain.app.utils:token_verification:138 - Failed to request /api/whoami-v2 - 429
ERROR | 2025-03-21 06:23:14 | autotrain.app.ui_routes:user_authentication:343 - Failed to verify token: Invalid token (/api/whoami-v2). Please login with a write token.
INFO: 127.0.0.1:54419 - “GET /ui/accelerators HTTP/1.1” 401 Unauthorized

Translation: Your API is screaming “429 TOO MANY REQUESTS” like an overworked galactic bouncer, then slapping me with a “401 Unauthorized” because apparently my VIP pass (aka my write token) isn’t VIP enough. The /ui/accelerators endpoint just shrugs and locks me out. Rude.

Now, here’s the kicker: if this 429 madness is because of too many requests to /api/whoami-v2, I’m not the one spamming it. I’m just chilling here, sipping coffee, while your AutoTrain app—on its default settings—decides to go full-on DDoS mode on your own API. I didn’t write the code, folks; I’m just the hapless astronaut trying to launch this rocket. If it’s pinging your servers like a hyperactive droid on a sugar rush, that’s on your software, not me manually hammering the endpoint. I’m innocent, I swear—my fingers are nowhere near an F5 key!

So, noble Hugging Face guardians, what’s the deal? Is this a rate-limit apocalypse I need to wait out (and if so, how long—hours? Days? Until the heat death of the universe?)? Is AutoTrain’s default behavior secretly a stress test for your API? Or did I miss a sacred PowerShell incantation to make this work? I’m running the latest autotrain-advanced (updated via pip install -U autotrain-advanced, because I’m thorough), and the API status page (https://status.huggingface.co/) looks green, so I’m leaning toward “your app is overzealous” as the culprit.

1 Like
2

Spaces, or perhaps both the server-side handling of HF_HOME / HF_TOKEN and the handling of HF_TOKEN in the huggingface_hub library have changed significantly recently. Personally, I think that’s probably the real culprit…:thinking:
However, it would probably be more reliable to start with a report of the specific problem symptoms.

3

Thanks for reaching out, but no. The struggle is that on local hardware, mine at least, Autotrain Advanced will spam their servers so much with your write token that they will rate limit you for just using the script. (Funny thing here is that I don’t need to write anything to their servers… they force the issue and documentation is very poor.) I am going to dig around in their scripts and see if I can just rip those bits out and anything that pushes to their servers. (customer support is nearly impossible to get on this platform.)

Cheers

1 Like
4

Possible solution: On local hardware, use a config file, and set push_to_hub: false.

1 Like
5

is there anyway to still use the UI with push to hub is false?

I did set the HF_TOKEN with the write token, but it doesn’t work. Same issue. It used to work one month before

1 Like
6

Not from the webui, no.

1 Like
7

I’m able to reduce the rate to that endpoint to prevent the 429 error code.

The below changes will help to only call the auth every 5 minutes

In utils.py,

At the top

import time

# Cache to store token verification results
_token_cache = {}

In def token_verification(token):

Add this at the top of the method:

# Check if the token is in the cache and not expired
    current_time = time.time()
    if token in _token_cache:
        cached_data, timestamp = _token_cache[token]
        if current_time - timestamp < 300:  # 5 minutes = 300 seconds
            logger.info("Using cached token verification result.")
            print('Use cached token')
            return cached_data

Add this at the end of the method

    # Cache the result with the current timestamp
    _token_cache[token] = (user_info, current_time)

    return user_info

right before

    return user_info
2 Likes
8

Perhaps +1 from Posts.