Ino Get Model Download Config

Modern models are a shopping list: a diffusion backbone, one or two text encoders, and a VAE, each living in its own HuggingFace repo. Ino Get Model Download Config exists because that list is annoying to manage by hand - it takes a single model config JSON string (the kind Ino Get Model Config produces) and splits it into the four separate download configs that actually fetch each component.

It's part of the Ino Nodes pack from nobandegani, and it's the glue between the pack's config layer and its download layer. One config in, four focused configs out.

What it does

You feed it one input, config - a model config JSON string. Under the hood it parses that string and pulls out the four component blocks that live inside a full model config:

• unet - the diffusion model download config.
• clip1 - the first text encoder.
• clip2 - the second text encoder (Flux and SDXL-style dual-encoder setups have both; single-encoder models just have an empty one).
• vae - the autoencoder download config.

Plus success for reporting. Each of those outputs is itself a JSON string containing everything a downloader needs - repo_id, filename, subfolder, model_type - ready to hand straight to Ino Hugging Face Download Model or Ino Handle Download And Load Model.

Why split at all? Because you often don't want all four at once. Maybe the UNet is already on disk and you only need the CLIP. Maybe you're downloading the VAE to a different folder. Splitting gives you per-component control instead of one monolithic download, which also means each piece can be verified (or re-downloaded) independently.

Where it fits

The typical Ino workflow: Ino Get Model Config → pick a preset → its model_config goes both here (to get the component download configs) and into Ino Get Sampler Config (to get the sampling settings). From here, each component config feeds a download node, and the downloaded paths feed the load nodes. It's a lot of strings flying around, but each one is doing one job, and the pattern means you never retype a repo ID.

The honest note: this node is a pure splitter. If the config you feed it isn't a well-formed model config with unet/clip1/clip2/vae keys, success comes back false and you get empty strings out - garbage in, empty out. Feed it configs from the pack's own config nodes and it behaves.

Installing it

It ships with the whole Ino Nodes pack. ComfyUI Manager: search "ComfyUI Ino Nodes", install, restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/nobandegani/ComfyUI-InoNodes.git
cd comfyui_ino_nodes
pip install -r requirements.txt

Restart after. Pack-wide caveats apply: it's built on ComfyUI's V3 schema (README wants v0.18.1+), and requirements.txt installs inopyutils, the helper library every node imports.

Common issues

Empty or failed outputs almost always mean the input string wasn't a model config JSON - check that you're feeding it the model_config output from Ino Get Model Config, not a single-component download config. And when only one encoder matters (Flux's T5 is huge; maybe you only need CLIP-L), you can safely ignore the other output. Search "Ino Get Model Download Config" in the node menu.