# Strange problem with huggingface-cli **URL:** \ **Category:** 🤗Hub\ **Created:** [June 20, 2025, 11:46am UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083 "2025-06-20T11:46:59Z")\ **Posts on this page:** 19\ **Page:** 1

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 11:46am UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/1 "2025-06-20T11:46:59Z")

since yesterday I have some strange issues with huggingface-cli usually when I download the file I can stop and resume download at any time today my downloads stop around 95% and when I restart it, they start from 0% it happened on two files, I tried clearing .cache 3 times already any hints? ---

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 20, 2025, 1:08pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/2 "2025-06-20T13:08:33Z")

I think Xet is currently being adjusted. It might be related to that… > > > Whenever some error happens and i run same code, it starts from 0 > > It is XET ena…bled repo and hf xet installed > > I really need to have resume feature > > my entire code > > > \`\`\` > from huggingface\_hub import snapshot\_download > import os > import argparse > > def download\_models(target\_dir=None): > """ > Download models from HuggingFace hub to specified directory > > Args: > target\_dir (str, optional): Target directory for downloads. > If None, uses current working directory > """ > # Set repo ID > repo\_id = "MonsterMMORPG/Kohya\_Train" > > # Use provided target dir or default to current working directory > download\_dir = target\_dir if target\_dir else os.getcwd() > > # Create target directory if it doesn't exist > os.makedirs(download\_dir, exist\_ok=True) > > try: > snapshot\_download( > local\_dir=download\_dir, > repo\_id=repo\_id > ) > print(f"\\nDOWNLOAD COMPLETED to: {download\_dir}") > print("Check folder content for downloaded files") > > except Exception as e: > print(f"Error occurred during download: {str(e)}") > > if \_\_name\_\_ == "\_\_main\_\_": > parser = argparse.ArgumentParser(description='Download models from HuggingFace hub') > parser.add\_argument('--dir', type=str, help='Target directory for downloads', default=None) > > args = parser.parse\_args() > download\_models(args.dir) > \`\`\` ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 2:21pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/3 "2025-06-20T14:21:34Z")

thank you, so the problem is not on my side 🙂 ---

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 20, 2025, 2:28pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/4 "2025-06-20T14:28:54Z")

Yeah, probably. If you updated the library beforehand, there may be bugs caused by the library upgrade, but if not, I think it’s either a server issue or, in rare cases, a network problem.😆 ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 2:35pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/5 "2025-06-20T14:35:20Z")

I tried pip install --upgrade huggingface\_hub but it was updated already ---

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 20, 2025, 2:37pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/6 "2025-06-20T14:37:07Z")

Perhaps ```auto pip install -U huggingface_hub[hf_xet] ``` is better now for faster uploading / downloading with Xet. ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 2:40pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/7 "2025-06-20T14:40:43Z")

> [@John6666](#): > > `pip install -U huggingface_hub[hf_xet]` Requirement already satisfied: huggingface\_hub[hf\_xet] in ./.pyenv/versions/3.12.3/lib/python3.12/site-packages (0.33.0) is there any other way to download models? looks like I can’t download anything, should I use firefox again? ---

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 20, 2025, 2:45pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/8 "2025-06-20T14:45:46Z")

> is there any other way to download models? Oh… I believe the following method will cause a fallback to the normal connection. However, this will only work if the issue is caused by a bug in the library implementation or a misconfiguration on the library side. Simply, if it’s the server’s fault, the only solution is for HF to fix the server settings! ```auto pip uninstall hf_xet hf_transfer ``` ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 2:48pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/9 "2025-06-20T14:48:34Z")

I pressed ENTER few times: ```auto huggingface-cli download --local-dir ~/models/ mradermacher/Skywork-SWE-32B-GGUF Skywork-SWE-32B.Q8_0.gguf Downloading 'Skywork-SWE-32B.Q8_0.gguf' to '/home/jacek/models/.cache/huggingface/download/2Lnqyho0STxoIp7LIkr5NuMXlbA=.c34f43512c7d00ceed0d8d283c1c0a177927f96b8090cd691e3c4e1b6d5e3570.incomplete' (resume from 14416789809/34820885376) Skywork-SWE-32B.Q8_0.gguf: 4%|██████▍ | 1.22G/34.8G [07:00<55:20:19, 169kB/s] Skywork-SWE-32B.Q8_0.gguf: 4%|██████▋ | 1.28G/34.8G [17:35<60:32:08, 154kB/s] Skywork-SWE-32B.Q8_0.gguf: 4%|███████▍ | 1.42G/34.8G [20:50<18:06:15, 512kB/s] Skywork-SWE-32B.Q8_0.gguf: 4%|███████▉ | 1.51G/34.8G [26:30<28:56:31, 320kB/s] ``` ---

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 20, 2025, 3:01pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/10 "2025-06-20T15:01:10Z")

Hmm… Is it being resumed…? 🤔 ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 3:11pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/11 "2025-06-20T15:11:12Z")

no, it’s always from 0, my point is that it’s very slow, but we will see I will wait few hours 🙂 ---

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 20, 2025, 3:18pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/12 "2025-06-20T15:18:29Z")

Hmm… Last resort? > **[GitHub - aria2/aria2: aria2 is a lightweight multi-protocol &...](https://github.com/aria2/aria2)** > > aria2 is a lightweight multi-protocol & multi-source, cross platform download utility operated in command-line. It supports HTTP/HTTPS, FTP, SFTP, BitTorrent and Metalink. ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 5:57pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/13 "2025-06-20T17:57:28Z")

and it’s dead (forever?) ```auto Skywork-SWE-32B.Q8_0.gguf: 4%|██████▍ | 1.22G/34.8G [07:00<55:20:19, 169kB/s] Skywork-SWE-32B.Q8_0.gguf: 4%|██████▋ | 1.28G/34.8G [17:35<60:32:08, 154kB/s] Skywork-SWE-32B.Q8_0.gguf: 4%|███████▍ | 1.42G/34.8G [20:50<18:06:15, 512kB/s] Skywork-SWE-32B.Q8_0.gguf: 68%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▌ | 23.6G/34.8G [2:04:34<39:12, 4.75MB/s] Skywork-SWE-32B.Q8_0.gguf: 68%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▌ | 23.6G/34.8G [2:04:51<39:12, 4.75MB/s] Skywork-SWE-32B.Q8_0.gguf: 96%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▉ | 33.3G/34.8G [2:33:21<01:57, 13.1MB/s] ``` ---

**Author:** ![jsulz](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/jsulz/32/28279_2.png) [@jsulz](https://discuss.huggingface.co/u/jsulz)\ **Post date:** [June 20, 2025, 7:12pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/14 "2025-06-20T19:12:48Z")

Hi @jacek2024 thanks for the report and for following up on the GitHub issue as well. Just a few questions to help troubleshoot this a bit more; could you answer a few questions/provide some more details: - Provide the output of `pip freeze` - Which repository you are downloading from? From the looks of the screenshots it is [mradermacher/Skywork-SWE-32B-GGUF · Hugging Face](https://huggingface.co/mradermacher/Skywork-SWE-32B-GGUF) is that correct? - What is the full command you are using? - Any details about the target environment (most notably what operating system you’re using any any information about network speeds and disk type) - Do you have any `HF_XET` environment variables set? (`env | grep HF_XET` should output them if they exist) As a quick test, you might try to fall back to a HTTP download. You can do this through: `export HF_HUB_DISABLE_XET=1` And then rerunning your download commands. This might help unblock your current download while we troubleshoot the issue. ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 7:25pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/15 "2025-06-20T19:25:18Z")

I tried to download 3 different models, same behaviour, it stops after 90% something and then freezes forever. I tried to download tiny model instead and it worked. Now I am trying with this: ```auto pip uninstall hf_xet hf_transfer ``` command is the same: ```auto huggingface-cli download --local-dir ~/models/ mradermacher/Skywork-SWE-32B-GGUF Skywork-SWE-32B.Q8_0.gguf Downloading 'Skywork-SWE-32B.Q8_0.gguf' to '/home/jacek/models/.cache/huggingface/download/2Lnqyho0STxoIp7LIkr5NuMXlbA=.c34f43512c7d00ceed0d8d283c1c0a177927f96b8090cd691e3c4e1b6d5e3570.incomplete' Xet Storage is enabled for this repo, but the 'hf_xet' package is not installed. Falling back to regular HTTP download. For better performance, install the package with: `pip install huggingface_hub[hf_xet]` or `pip install hf_xet` Skywork-SWE-32B.Q8_0.gguf: 2%|███▋ | 703M/34.8G [03:08<4:11:16, 2.26MB/s] ``` ---

**Author:** ![jsulz](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/jsulz/32/28279_2.png) [@jsulz](https://discuss.huggingface.co/u/jsulz)\ **Post date:** [June 20, 2025, 7:46pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/16 "2025-06-20T19:46:45Z")

Thanks for the command! Sorry, should’ve seen that was provided earlier; my apologies. Few additional details that would be helpful: - `pip freeze` output - Environment info about where you are downloading to (i.e., what operating system you’re using any any information about network speeds and disk type) - Do you have any `HF_XET` environment variables set? - When the download progress stops, is there any network or CPU activity? From your last comment, I’m wondering is if the issue is the chunk cache in the `xet` directory (present under the `huggingface` cache). If you clear the chunk cache (`rm -rf ~//xet` where `` is the location of the Hugging Face cache) and then run `export HF_XET_CHUNK_CACHE_SIZE_BYTES=0` that may help. And of course, let me know if you are able to download via HTTP - thank you! 😄 ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 8:00pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/17 "2025-06-20T20:00:54Z")

I use Linux, Ubuntu, fast nvme drives I was downloading models with huggingface-cli many, many times before, so I am not doing anything new I was removing whole .cache to clear the previous file I don’t see any XET env ```auto $ pip freeze aiohappyeyeballs==2.6.1 aiohttp==3.12.13 aiosignal==1.3.2 annotated-types==0.7.0 anyio==4.9.0 attrs==25.3.0 certifi==2025.6.15 charset-normalizer==3.4.2 datasets==3.6.0 dill==0.3.8 distro==1.9.0 filelock==3.18.0 frozenlist==1.7.0 fsspec==2025.3.0 h11==0.16.0 httpcore==1.0.9 httpx==0.28.1 huggingface-hub==0.33.0 idna==3.10 jiter==0.10.0 multidict==6.5.0 multiprocess==0.70.16 numpy==2.3.0 openai==1.88.0 packaging==25.0 pandas==2.3.0 propcache==0.3.2 pyarrow==20.0.0 pydantic==2.11.7 pydantic_core==2.33.2 python-dateutil==2.9.0.post0 pytz==2025.2 PyYAML==6.0.2 requests==2.32.4 six==1.17.0 sniffio==1.3.1 toml==0.10.2 tqdm==4.67.1 typing-inspection==0.4.1 typing_extensions==4.14.0 tzdata==2025.2 urllib3==2.5.0 xxhash==3.5.0 yarl==1.20.1 ``` ---

**Author:** ![jacek2024](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jacek2024](https://discuss.huggingface.co/u/jacek2024)\ **Post date:** [June 20, 2025, 11:12pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/18 "2025-06-20T23:12:40Z")

Looks like everything works after uninstalling xet. I successfully downloaded 3 big models. What’s the point of this xet thing? What kind of “performance” I am losing? 🙂 ---

**Author:** ![jsulz](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/jsulz/32/28279_2.png) [@jsulz](https://discuss.huggingface.co/u/jsulz)\ **Post date:** [June 23, 2025, 4:03pm UTC](https://discuss.huggingface.co/t/strange-problem-with-huggingface-cli/160083/19 "2025-06-23T16:03:13Z")

Glad to hear that worked! The primary benefit of Xet is faster uploads and downloads - you can see some of how this works on the infrastructure side [here](https://huggingface.co/blog/rearchitecting-uploads-and-downloads). On the client side it’s aided by providing `huggingface_hub` a tight integration with the [xet-core](https://github.com/huggingface/xet-core) Rust library that should provide some performance boosts on the download side especially - that’s `hf-xet`. Obviously, in this case, something’s up! Just trying to figure out what the issue was here so we can make sure to address this in the future; few additional questions if you wouldn’t mind: - Are the NVMe drives you’re writing to local disks? - What specific models in the repo were causing you problems? - Did the downloads for these models stop at the same place each time? - You mentioned you were clearing the `.cache` directory each time - were you using the `huggingface-cli delete cache` command to do this?