DreamX Creator Complete Loader

Four loaders in this pack, all pointing at the same model root. DreamX Creator Complete Loader is all four of them in a trench coat, and for 95% of graphs it's the one you want: it takes model_root and dtype and hands you model, clip, vae and audio_vae on four outputs.

The shipped example workflow uses it. That's usually the argument that matters most - the pack's examples/dreamx_creator_ui.json opens with this node and nothing else at the top of the graph.

What you get

• model - the 7B joint generator as a MODEL. Goes to DreamX AV Flow Shifts, then DreamX Multimodal Guider, then SamplerCustomAdvanced.
• clip - a CLIP-compatible facade around the UMT5-XXL text encoder, straight into two CLIP Text Encode nodes.
• vae - the Wan 2.2 48-channel video VAE, for encoding the first frame and decoding the video latents.
• audio_vae - the CreatorDACVAE handle, for DreamX Audio VAE Decode. It's a custom DREAMX_AUDIO_VAE type, so it only fits that node.

The dtype combo is bfloat16 / float16 / float32, defaulting to bfloat16 - with one deliberate exception. The audio VAE is loaded in float32 no matter what you pick, because the released Creator audio decoder runs in fp32 and the pack's source says so in a comment. So there's no way to accidentally break the audio path by "optimising" the bundle's dtype. Good design, that.

model_root defaults to auto: the repo's own checkpoints/ directory first, then ComfyUI/models/dreamx_creator/. You can paste a path instead, but auto is right if you followed the install instructions.

Why the four separate loaders exist

Not to make you type more. Two real reasons. First, the DreamX Causal Refiner Loader is a different model entirely (a 5B causal SR-DiT) and pairs with its own UMT5 and Wan VAE, so the refiner workflow loads its pieces individually rather than pulling half a bundle it doesn't need. Second, in a hand-built graph you may want to control what gets offloaded and when - the bundle moves all four models into ComfyUI's management at once, and on a 24 GB card that's the whole budget.

Prefer the bundle for the generation pass. Prefer the individual loaders when you're sequencing two heavy phases on one card.

What loading actually does

The bundle resolves and validates the model root first. That means all 14 required files have to be present - creator/video_model shards and configs, creator/audio_model, creator/cross_attn_weights.safetensors, the audio VAE, wan2.2_ti2v_5b/Wan2.2_VAE.pth, the UMT5 encoder and its tokenizer files, and the refiner's sr_dit_5b.pt plus latent_upsampler_flash.pt. It checks them before loading a single weight, so a bad download fails in seconds with a file list instead of after 50 GB of disk churn.

The pickle-backed official checkpoints (the Wan VAE, the UMT5 encoder file, the SR-DiT) are SHA-256 verified against the pack's model_manifest.json before they're loaded tensor-only. If your file is truncated or isn't the file the pack expects, you get a size or hash mismatch error and a refusal. That's the pack being careful about torch.load on a checkpoint it didn't produce.

Install

ComfyUI Manager → DreamX Creator T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-DreamX-Creator-T8.git
cd Comfyui-DreamX-Creator-T8
python -m pip install -r requirements.txt

Weights, ~54 GB, separate:

python -m pip install -U huggingface_hub
hf download t8star/DreamX-Creator-Comfy --local-dir ComfyUI/models/dreamx_creator
python scripts\verify_models.py

Run the verifier. It's the cheap way to find out your download stopped early, and the pack ships it precisely because 50 GB downloads are a coin flip.

Common issues

Everything loads, then the sampler OOMs. All four models are resident at once and the image phase hasn't started. That's the bundle's honest cost. Lower target_spatial_tokens, or split the graph with the individual loaders.

Hash mismatch on a file that looks fine. The manifest is strict about size and digest. Re-download the specific file rather than the whole bundle if you can.

You're at 24 GB and things spill instead of erroring out. On Windows this is WDDM quietly moving CUDA allocations into shared system RAM, and you get a slow, weird run rather than a clean failure. The refiner loader's defaults exist for exactly this reason - see that article.