Load Lora From HuggingFace (with Token)

This is the standard "apply a LoRA to your model and CLIP" node, except instead of picking a file out of your local models/loras folder, you point it at a HuggingFace repo and it fetches the file at run time - and this variant carries your HuggingFace access token along so it can reach repos that aren't public.

What it's for

The plain LoadLoraFromHF node (covered separately) does the same job for public repos. This one exists because a meaningful chunk of HuggingFace content is gated: you have to be logged in, and often you have to click through a license acceptance, before the repo will even list its files to you. Gated is the norm rather than the exception for a lot of current base models - Flux Dev is the textbook example, sitting behind a form that collects your details and can be revoked at will. If the LoRA (or its base model's ecosystem) requires that kind of access, the plain HF loader will 404 on you and this is the one you actually need.

It's also the right tool if you've forked a private repo for your own LoRAs and want to load straight from HuggingFace instead of syncing files down manually - handy in an executor/API context where there's no persistent local disk to keep populated between runs.

How it works

Same mechanics as ComfyUI's built-in LoRA loader under the hood: it patches the diffusion model and the CLIP text encoder with the LoRA's weight deltas, scaled by two independent strength values. What's different is where the file comes from - instead of a dropdown of what's already on disk, you give it a repo name and a filename, plus a token, and the node resolves and downloads that specific file before applying it.

The inputs and outputs that matter

• model (MODEL) and clip (CLIP) - the diffusion model and CLIP the LoRA gets applied to. Standard sockets, same as any LoRA loader.
• repo (STRING) - the HuggingFace repository name, in user/repo form, per the node's own tooltip.
• file_name (STRING) - the exact filename inside that repo you want, per the tooltip. Get this wrong (wrong path, wrong extension) and the fetch fails.
• hf_token (STRING) - your HuggingFace access token, "for accessing private repositories" in the node's own words. Generate one from your HuggingFace account settings with at least read scope, and for gated repos make sure you've actually clicked "Agree" on the repo's license page first - the token alone doesn't bypass a gate you haven't accepted.
• strength_model and strength_clip (both FLOAT, default 1, range -100 to 100) - how hard the LoRA pushes the model and the text encoder respectively. The old rule of thumb from the SDXL era was 0.5–0.8; that doesn't generalize to every current architecture, some newer character LoRAs are published with a recommended weight of 1.0 or higher, since dropping it costs likeness. Check what the LoRA's own page says rather than defaulting to 0.7 out of habit.
• Outputs: MODEL and CLIP, feed straight into your KSampler and CLIPTextEncode nodes like any other LoRA-loader output.

How to install it

• ComfyUI Manager - search "comfyui-model-dynamic-loader," install, restart.
• Manual -

  cd ComfyUI/custom_nodes
  git clone https://github.com/jax-explorer/comfyui-model-dynamic-loader
  

  then restart. The README lists no extra dependencies or bundled model downloads - everything is fetched on demand at run time based on what you type into repo and file_name, so there's nothing to pre-download for the install itself.

Common issues & troubleshooting

401 or 403 on a repo you swear you have access to. Check three things in order: did you actually click through the license acceptance on the repo's HuggingFace page (a token doesn't skip that step), does the token have at least read scope, and is it the right account's token if you're a member of an org that owns the repo.

Wrong architecture, wrong results. LoRAs are locked to the base model family they were trained on - a LoRA trained for one architecture does nothing useful loaded against a different one, even though nothing here stops you from trying. Match the LoRA to the checkpoint it was built for.

Your token is sitting in the workflow file in plain text. Worth knowing before you share a workflow JSON or paste it into a template: hf_token is an ordinary STRING widget, and whatever you type into it gets saved into the workflow like any other field. Don't publish or hand off a workflow with a real token still in that box - clear it first.