Anymatix Fetcher

If you only understand one node in this pack, make it this one, because almost everything else in anymatix-comfy-nodes is a loader waiting for this node's output. Anymatix - the desktop app this pack exists to serve - ships workflows where a card says this checkpoint, this LoRA, this VAE, addressed by URL rather than by a dropdown. AnymatixFetcher is the download half of that promise: give it a URL, it pulls the file down into the right model directory, verifies it, and hands you back the local path as a plain STRING.

It also works fine without the Anymatix app, and that's the honest pitch: if you've ever opened a workflow that references a model you don't have, or you want one node to grab a file from Hugging Face mid-graph instead of a terminal dance, this is a tidy way to do it.

How it works

The name is a lie in one direction: it doesn't fetch anything over an API, and you need no key for most sources. It's a downloader with an unusually careful one. The fetcher takes your URL plus a type, and the type decides which folder the file lands in - checkpoint goes to models/checkpoints, lora to models/loras, text_encoders, controlnet, clip_vision, audio_encoder, and a dozen more. It respects your extra_model_paths.yaml, so if your models live on a second drive, it finds them there rather than forcing everything into the default tree.

The careful part is what happens around the download:

• Interrupted transfers resume, and bytes accumulate in a .part file that only gets its real name once the size matches what the server declared - so a half-finished download can never be mistaken for a working model.
• It hashes what it pulls (SHA-256) and reuses a model it already holds under a different URL, so two cards pointing at the same weights don't waste your bandwidth twice. There's even a sha256://… URI form that resolves straight to a local file.
• When the server supports Range requests, it fetches in parallel byte ranges (aiohttp/aiofiles), which turns one fat checkpoint into several quick streams.

One subtlety that bites people: fetchers are marked OUTPUT_NODE, meaning ComfyUI always executes them even when nothing wires into their output. That's deliberate. A URL-addressed workflow can compile into a graph where the download node ends up orphaned - and if ComfyUI skipped it, your "load" node would hunt for a file that never arrived. So the fetcher runs no matter what; if it already holds the file it returns in milliseconds, and the only real cost is paid when a download was needed anyway.

The inputs that matter

There's exactly one input widget, and it's structured rather than a bare text box:

• url - a URL plus a type dropdown telling the node which model category this is (checkpoint, lora, vae, and so on), with an optional auth field you can leave empty for public files.

Output and wiring

One STRING output - the absolute path to the downloaded file. That's the whole contract: feed it into the pack's path-taking loaders like AnymatixCheckpointLoader or AnymatixLoraLoader, which read a path instead of a dropdown precisely because the file may not have existed when the graph was written.

Install

Standard for this pack - ComfyUI Manager (search "anymatix-comfy-nodes"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/Anymatix/anymatix-comfy-nodes

then restart ComfyUI. Its requirements (numpy, Pillow, opencv, aiohttp for the parallel downloads) install with the pack.

Issues to expect

First run needs network, obviously - and if you run ComfyUI with --listen, remember this pack registers HTTP routes on your server (logs, a model listing, delete endpoints). They're read-only or restricted to ComfyUI's own model roots, but "restricted" isn't "authenticated." Also, the heartbeat dead-man's switch people worry about only arms when ANYMATIX_HEARTBEAT_PORT is set, which the Anymatix launcher does and your ComfyUI doesn't. If a download fails, the error usually names the problem honestly: wrong type gets you a list of valid ones, and a typo'd URL fails at the HTTP layer, not mysteriously.