**Author:**  [@RDTvlokip](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FRDTvlokip)%5C
**Post date:** [September 15, 2026, 11:13am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdownload-resume-possibility%2F180468%2F2 "2026-09-15T11:13:07Z")
This is a known pain point with the newer Xet-backed transfer path specifically, there’s an open issue where `hf download` on Xet-backed repos can exit with status 0 even when it didn’t actually finish, leaving `.incomplete` blobs behind and no real resume happening. Two things worth trying:
`HF_HUB_DISABLE_XET=1 hf download ` forces the older plain HTTP range-request path instead of Xet, that one does properly resume from existing bytes on retry, just slower per-connection.
If that’s still flaky, the community `hfd` script (curl+aria2c wrapper, see the padeoe gist on GitHub) is more robust for big downloads, it does integrity-aware resume, re-fetching only files that are missing or the wrong size rather than restarting the whole transfer, and lets you cap thread count if your connection can’t handle many parallel streams.
---
**Author:**  [@automacellulare](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fautomacellulare)%5C
**Post date:** [September 15, 2026, 3:07pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdownload-resume-possibility%2F180468%2F3 "2026-09-15T15:07:44Z")
all of these appear to be not a real solution.
I mean if I’ve to dowload a model like the antirez’s q2 gguf of deepseek v4.1 flash that is a 366GB file is impossible to launch the download from the files card of the model because of a “400 bad request” on the huggingface site; and if you try the ds4 download script if the connection fails I’ve to start it again from beginning.
I’m now trying after I changed the \_ETAG\_RETRY\_TIMEOUT parameter in the file\_download.py ov the python venv of hf-cli, and I hope it will work because I’m trying 3 days in a row to download a single model.
About the hfd scipt how do this work when the direct access to the download link through the files section of a model give a “400 Bad Request”?
---
**Author:**  [@RDTvlokip](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FRDTvlokip)%5C
**Post date:** [September 15, 2026, 3:22pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdownload-resume-possibility%2F180468%2F4 "2026-09-15T15:22:07Z")
Found it, that’s a known bug specific to very large single files (this exact issue is tracked upstream, xet-core #592): the “CAS Bridge” that serves browser/website downloads and `blob/main` links breaks with a 400 on files past a certain size (people are hitting it on 300-600GB GGUF quants specifically), it only affects the website/CAS-bridge path, not the Xet client itself. So that 400 isn’t fixable from your end, it’s a server-side limit on that particular delivery path.
For a file that size the reliable path is the Xet-native client, `hf download --include "*.gguf"` (or the specific filename) uses the Xet protocol directly rather than going through the broken CAS bridge, that’s what’s confirmed working around this bug in the linked issue. On the `hfd` question, it won’t help here either since it also just wraps HTTP/curl requests to the same CAS-bridge links, so it’ll hit the same 400. Stick with `hf download` (Xet-enabled, which is default now) rather than any browser/curl/aria2c approach for this specific file, and if it still drops mid-transfer, that’s the separate resume bug from before, worth watching xet-core#592 for a fix on the 400 itself since it’s still open.
---
**Author:**  [@automacellulare](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fautomacellulare)%5C
**Post date:** [September 15, 2026, 3:54pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdownload-resume-possibility%2F180468%2F5 "2026-09-15T15:54:09Z")
I see but the “server side problem + poor connection that makes hf download fail on timeout for CAS check” ends up as a fatal combo right on my back…
At least if the server side error was solved I could even use and rely on JDownloader to easily resume the downlod fails because of the connection fails.
I mean I think it looks link there is something wrong in the site and/or hub architecture if just 2 miserable problems alone turn into a fatal error by the customer side when they appear togheter.
---
**Author:**  [@RDTvlokip](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FRDTvlokip)%5C
**Post date:** [September 15, 2026, 4:03pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdownload-resume-possibility%2F180468%2F6 "2026-09-15T16:03:36Z")
Yeah, fair, and that’s a real gap, not you doing anything wrong. Right now there isn’t a single working path for a file that size on a bad connection: Xet client is the only thing that gets past the 400, but it doesn’t reliably resume on your connection; the website link would resume fine with JDownloader, but it’s blocked by the CAS bridge bug at this size. Two separate bugs that happen to cancel out each other’s workaround, which is exactly the “architecture problem” you’re describing.
Only thing left worth trying on your end: split the download into smaller chunks via `hf_hub_download` with explicit byte ranges if the model repo exposes it, or check if antirez/the quantizer split the GGUF into multiple smaller part files elsewhere (some large quants get split specifically to dodge this bridge limit), that’d let you use JDownloader on each part instead of one 366GB stream. Otherwise this really is on HF to fix xet-core#592, worth adding your case to that issue thread since more reports with concrete repro (repo name, file, connection type) helps it get prioritized.
---
**Author:**  [@automacellulare](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fautomacellulare)%5C
**Post date:** [September 17, 2026, 7:08am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdownload-resume-possibility%2F180468%2F7 "2026-09-17T07:08:52Z")
I solve it by running this command trying to escape timeout and retry limits:
export HF\_HUB\_ETAG\_TIMEOUT=300
export HF\_HUB\_DOWNLOAD\_TIMEOUT=600
export HF\_XET\_CLIENT\_CONNECT\_TIMEOUT=90
export HF\_XET\_CLIENT\_READ\_TIMEOUT=600
export HF\_XET\_CLIENT\_RETRY\_BASE\_DELAY=5
export HF\_XET\_CLIENT\_RETRY\_MAX\_ATTEMPTS=100000
export HF\_XET\_CLIENT\_RETRY\_MAX\_DURATION=36000
hf download antirez/deepseek-v4.1-flash-gguf DeepSeek-V4.1-Flash-Q2.gguf
Hope it can help someone, but much more I hope someone in hf could place himself and point to really make the xet work properly.
---
**Author:**  [@system](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fsystem)%5C
**Post date:** [September 17, 2026, 7:09pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdownload-resume-possibility%2F180468%2F8 "2026-09-17T19:09:43Z")
Closed on September 17, 2026, 7:09pm UTC
This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.