Ino Handle Download Model

Here's the pattern that makes ComfyUI-InoNodes' model system feel like magic the first time you see it: a workflow carries around a JSON config describing a model - where it's hosted, what type it is, where it should land - and when it's time to actually get the file, a single node reads that config and dispatches to the right downloader. That node is Ino Handle Download Model. You don't pick the downloader; the config's host field does.

It's the central dispatcher in the pack's InoModelHelper family. The flow is: build a config (with Ino Create Model File Config or a catalog node like Ino Get Video Model Download Config) → hand it here → get back the path to the downloaded file.

The input

Just two: enabled (the pack's standard toggle) and config - a JSON string, default "{}". The config must contain at least a host field, and it can carry model_type, model_subfolder, repo_id, filename, subfolder, repo_type, revision, and the rest.

Outputs: success, msg, model_type, abs_path, and rel_path - everything a loader node needs to pick the file up.

How it works

It parses the config, looks at host, and routes:

• s3 → the S3 download node (needs S3 credentials via env vars or config).
• hf → the HuggingFace single-file download node.
• civitai → the Civitai download node (may want a CIVITAI_TOKEN).

Any other host value returns success: false with "unknown host". Invalid JSON gets the same graceful failure - no crash, just a message. The dispatched downloader does the actual work, and this node passes its result straight through, so you get one consistent output shape no matter which backend ran.

That delegation is the whole point. You can swap a model's host from HF to S3 by editing the config (or the node that builds it) and never rewire the graph. The rest of the pipeline doesn't care where the file came from - it just sees the abs_path.

Where it fits

• Model pipelines. Build configs from the catalog (Ino Get Video Model Download Config, image-model equivalents), feed them here, and the pack auto-downloads to models/<type>/<subfolder>/.
• Host-agnostic workflows. Design once against "a config," run it against HF, S3, or Civitai by changing data, not wiring.
• Download-and-load chains. Hand abs_path to the pack's Ino Handle Download And Load Model or a specific loader to go from config to loaded model in one run.

Gotchas

The dispatch is only as smart as the config - if host is wrong or missing, you get a clean failure, and if the config's repo_id/filename semantics don't match the host (see the "depends on the host" tooltips on Ino Create Model File Config), the underlying downloader will fail in host-specific ways. Also remember the skip-if-present behavior inherited from the downloaders: if the target file already exists, you'll get a "model validated" success without re-downloading - which is usually what you want, and occasionally surprising if you expected a refresh.

Installation

Part of ComfyUI-InoNodes:

• ComfyUI Manager: search "ComfyUI Ino Nodes", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/nobandegani/comfyui_ino_nodes && cd comfyui_ino_nodes && pip install -r requirements.txt, restart.

Python 3.10+, ComfyUI 0.18.1+ (V3 schema). No models at install. Credentials are per-backend: S3 env vars for S3, CIVITAI_TOKEN for Civitai, and optional HF tokens for gated repos.