Ino Show Model Config
Take a model config JSON apart, wire by wire
- name
- type
- unet
- weight_type
- use_dual_clip
- use_flux_encoder
- use_flux_guidance
- guidance
- use_negative_prompt
- clip1
- clip2
- vae
- use_cfg
- cfg
- sampler_name
- scheduler_name
- steps
- denoise
- tags
- description
- lora_compatible
This pack treats a whole model as a single JSON object - the sampler settings and where to find the UNET, CLIPs, and VAE. That's convenient until you need one field from that blob wired into something else. Ino Show Model Config is the node that tears the config apart: feed it the JSON, and it spits out every field as its own output you can connect elsewhere.
It's a debugging and plumbing tool, not a generator. You'll reach for it when a config has flowed through the graph - from a InoGetModelConfig lookup, or edited by InoUpdateModelConfig - and you want to inspect it or break it into individual values.
What it outputs
Feed it config (the JSON string, multiline) and you get 21 outputs, one per field. The ones a beginner actually cares about, in rough order:
nameandtype- what the model is called and its architecture family (e.g.flux).sampler_name,scheduler_name,steps,denoise,cfg,guidance- the sampling parameters that will drive generation.use_dual_clip,use_flux_encoder,use_flux_guidance,use_negative_prompt,use_cfg- the boolean toggles that change how conditioning is built, which matter specifically for Flux-style models.unet,clip1,clip2,vae- the model download descriptors, emitted as strings.tags,description,lora_compatible,weight_type- metadata.
The enabled toggle is the pack-wide master switch; off means empty outputs and no work.
How it works
The mechanism is dead simple and it's worth knowing because it explains the failure mode. The node parses the config string into a dict, then reads each known key and emits it as a typed output (strings, booleans, ints, floats). If the JSON won't parse - bad string, missing field, wrong shape - it returns all-empty outputs and logs a failure to the console. There's no partial success here; it's all or nothing.
One quirk: unet, clip1, clip2, and vae are objects inside the config (they describe the download source), but they come out of this node as strings. Don't expect a structured value on those four wires - expect the serialized descriptor. If you need a field out of one of those, you'll pull it from the string or use a JSON getter downstream.
Installing Ino Nodes
Install the pack once, get every node. ComfyUI Manager: search "ComfyUI Ino Nodes", install, restart. Terminal:
cd ComfyUI/custom_nodes
git clone https://github.com/nobandegani/ComfyUI-InoNodes.git
cd comfyui_ino_nodes
pip install -r requirements.txt
The pack is V3-schema and depends on inopyutils (pinned in requirements.txt) - make sure pip installs it into the same environment that runs ComfyUI. No model files needed.
Where people get burned
The all-or-nothing behavior catches people: connect a config that's missing a key and you get silence, not an error you can read. If a wire downstream suddenly has nothing on it, check the console log first - it'll say "string_to_dict failed" and the puzzle is solved. Also note this is not an output node - it's a passthrough/plumbing node, so it's meant to sit mid-graph, not at the end.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| enabled | BOOLEAN | true | — |
| config | STRING | — |
Outputs (21)
| Name | Type | Description |
|---|---|---|
| name | STRING | — |
| type | STRING | — |
| unet | STRING | — |
| weight_type | STRING | — |
| use_dual_clip | BOOLEAN | — |
| use_flux_encoder | BOOLEAN | — |
| use_flux_guidance | BOOLEAN | — |
| guidance | FLOAT | — |
| use_negative_prompt | BOOLEAN | — |
| clip1 | STRING | — |
| clip2 | STRING | — |
| vae | STRING | — |
| use_cfg | BOOLEAN | — |
| cfg | INT | — |
| sampler_name | STRING | — |
| scheduler_name | STRING | — |
| steps | INT | — |
| denoise | INT | — |
| tags | STRING | — |
| description | STRING | — |
| lora_compatible | STRING | — |