Universal MOSS-Image Loader

You dropped a MOSS-Image file into a UNETLoader and got told the model type isn't supported - probably before any weights reached VRAM. Then you went hunting for a clip_type entry called moss and didn't find one. That's not a missing feature. It's the whole reason this node exists.

Universal MOSS-Image Loader (UniversalMOSSLoader) is a typed loader. It doesn't hand you a MODEL/CLIP/VAE. It hands you MOSS's own component types, which only MOSS's own sampler and text-encode nodes accept.

Why a separate node at all

Core ComfyUI has no MOSS implementation and no MOSS CLIP type. The moss-image-t8 integration that actually runs MOSS ships its own typed descriptors - its own DiT, text-encoder and VAE loaders - returning MOSS_IMAGE_DIT, MOSS_IMAGE_TE and MOSS_IMAGE_VAE, not MODEL, CLIP and VAE.

The tempting shortcut is to fake it: invent a moss entry in the CLIP type enum, add a wildcard socket, ship. Zoltar358 refused, and the reasoning holds - a fictional CLIP type cannot make an incompatible checkpoint compatible.

So the pack does two things. The universal loader recognizes MOSS filenames and stops you before weight allocation with a message pointing at the typed route; inactive hidden selectors are ignored, so a stale hidden MOSS path won't trip it. And this node is the route that message points at.

How it works

UniversalMOSSLoader is an adapter, not a loader implementation. It looks up MOSSOfficialDiffusionLoader, MOSSOfficialTextEncoderLoader and MOSSOfficialVAELoader in ComfyUI's node registry and checks each still returns the socket type it expects and still has a load(). If the integration is missing, the node still registers - the rest of the pack keeps working and ComfyUI boots - but executing it names the missing loader.

The inputs

Only five, and three are file pickers whose contents come from the MOSS dependency itself - when it ships new selectors, this node inherits them.

• diffusion_model_name - the DiT, as an independently exported Base or SFT component.
• text_encoder_name - the Qwen3.5-9B encoder, with its local tokenizer sidecars present.
• vae_name - the explicit FLUX.2 VAE component package.
• device - auto, cuda or cpu. Leave it on auto unless you're deliberately offloading the encoder.
• precision - bf16 or fp32. bf16 is the default and right for any modern card.

Device and precision are forwarded to the dependency, which keeps its own component validation, integrity hashing and cache-invalidation checks - a bad download still fails as a bad download.

The outputs, and where they go

Four, and the wiring isn't negotiable:

• model (MOSS_IMAGE_DIT) → MOSSOfficialSampler's dit.
• model_name (STRING) → filename minus extension, for a filename prefix or note node.
• text_encoder (MOSS_IMAGE_TE) → MOSSOfficialTextEncode's text_encoder.
• vae (MOSS_IMAGE_VAE) → MOSSOfficialVAEDecode's vae.

Do not connect these to KSampler, CLIP Text Encode or VAE Decode. The sockets won't offer it - different types - but people force it with a converter node anyway and then wonder why the output is garbage.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Zoltar358-ComfyUI/ComfyUI-Universal-Model-Loader.git

Restart ComfyUI and hard-refresh the browser. The pack has no pip dependencies (dependencies = []), so nothing gets pip-installed and nothing can conflict with your other packs.

MOSS itself is a second install: you need the moss-image-t8 integration providing those three MOSSOfficial*Loader classes. Without it this node registers but errors on execution. To verify a setup, the pack's script hashes existing local component packages without downloading anything:

/path/to/ComfyUI/.venv/bin/python tests/moss_integration.py /path/to/ComfyUI /path/to/shared/models

Troubleshooting

"Requires the moss-image-t8 integration." Those loader classes aren't registered. Install or enable that pack and restart - a browser refresh alone won't do it.

It rejects your quantized single-file download. Raw and pruned INT8 files aren't supported by this adapter, and neither are ConvRot or all-in-one bundles. Their presence on disk doesn't imply compatibility. This is the most common way to arrive at this node and the most common reason it says no.

Don't route MOSS through the universal loader. If you pick a MOSS file there it fails early on purpose. Right-click that node → Add MOSS-Image loader (typed). That adds this node beside it and copies your filename selections verbatim. What it does not do: convert files, validate compatibility, or reconnect incompatible sockets. Copied choices you got wrong are still wrong, and you fix them by hand.

Everything looks loaded and nothing generates. Worth saying plainly: the author's verification stops at descriptor loading - metadata, manifests, weight integrity, INT8 rejection. That's not an image-generation claim. Expect to be the one debugging it.

Should you reach for it

If you're running MOSS-Image, you need it - it's the only sane bridge between independently exported components and a typed MOSS graph, and the alternative people reach for (forcing types through converter nodes) doesn't work. If you're not running MOSS, don't install the pack for this node.