Lora Loader From HF

Lora Loader From HF does one thing ComfyUI's built-in LoraLoader won't: it pulls a LoRA straight off Hugging Face by repo name and filename, so you never touch your models/loras folder. Someone drops a link in a Discord server, you type ostris/ikea-instructions-lora-sdxl into a box, and the node does the rest. It's the same two-wire drop-in shape as the stock loader - MODEL and CLIP in, MODEL and CLIP out - just with the weight fetched from the hub instead of a file picker.

How it works

Under the hood it's three ComfyUI functions you already trust, chained behind a Hugging Face download. On each run the node calls hf_hub_download(repo_name, filename), loads the weights with load_torch_file(safe_load=True), and hands them to load_lora_for_models with your two strengths. The interesting part is the caching: the node keeps the last (repo, filename, weights) trio in memory, so re-running the same combo doesn't re-download or re-parse the file - instant on the second run. And if both strengths are set to 0, it short-circuits and passes your model through untouched, without even hitting the network.

Files land in ComfyUI/models/hf_cache_dir/, a folder the pack registers when ComfyUI starts. That's the one genuinely confusing bit: you'll never see your LoRA in the loras folder, it's in the HF cache layout (blobs and snapshots), and it only downloads on the first run of any new repo+file pair.

The inputs that matter

The pack's own README is honest about these, and the schema agrees:

• repo_name - owner/name on Hugging Face, e.g. ostris/ikea-instructions-lora-sdxl. The default is the string lora_name, which is a placeholder, not a real repo.
• filename - the exact file name inside that repo. This is where beginners get burned: the default is also lora_name. Leave it, and hf_hub_download goes looking for a file called lora_name in a repo called lora_name and errors out.
• api_token - empty for public repos. Only needed for gated or private ones (grab a token from your HF account → Settings → Access Tokens).
• strength_model and strength_clip - default 1.0, can go negative, same semantics as any LoRA loader. The classic recipe is a strong model strength with a weaker or zero CLIP strength if the clip weights fight your prompt.

Outputs are MODEL and CLIP, wired exactly like a normal LoraLoader: between your checkpoint loader and the sampler, both feeds.

Installation

The pack ships two nodes, so this installs them both:

cd ComfyUI/custom_nodes
git clone https://github.com/olduvai-jp/ComfyUI-HfLoader
pip install huggingface-hub

Then restart ComfyUI. That pip install huggingface-hub line is the whole dependency story - requirements.txt contains nothing else. ComfyUI Manager users can just search "ComfyUI-HfLoader" and skip the terminal entirely.

Where people get stuck

The single-file thing is the trap nobody warns you about. This node loads exactly one file, so the LoRA repo needs to ship a flat .safetensors (or .pt). A lot of HF repos store LoRAs in diffusers format - a subfolder with adapter_config.json and split weights - and those won't load here because there's no config to tell ComfyUI how to stitch them together. If the repo page shows a single weights file at the root, you're good. If you see a folder structure, find a different repo or use your local loader.

Also worth knowing: it needs network on first load, it's gated-repo-hostile until you paste a token, and the in-memory cache means loading a different LoRA in a different node instance does nothing for this one. Swap the repo+file and the old weights get dropped cleanly, so that part you don't have to worry about. For a tiny pack by an author with no community footprint, it's remarkably usable - it's just picky about what counts as "a file."