Load CogVideoX-Fun Model

Before Wan ate local video generation, CogVideoX (from Tsinghua's THUDM) was the model people were excited about. LoadCogVideoXFunModel is the entry point for its "Fun" variant - Alibaba's PAI team took THUDM's CogVideoX architecture and retrained it with extra capabilities (start/end-frame prediction, pose and control conditioning) that the original never shipped. This is genuinely the original product here: the repo now called VideoX-Fun started life as CogVideoX-Fun, and Wan-Fun got bolted on later once Wan overtook CogVideoX as the community's model of choice. If you're new to local video gen in 2026, there's a decent chance you don't need this one at all - CogVideoX has been superseded and most workflows target Wan now - but if you're loading old CogVideoX-Fun checkpoints or specifically want its I2V-with-added-motion-noise behavior, this is the loader.

How it works

Same shape as every loader in this pack: pick a checkpoint, VideoX-Fun instantiates the transformer + VAE + text encoder, applies your memory strategy, and outputs one cogvideoxfun_model bundle that the CogVideoXFun sampler nodes expect. Note the output name - it's cogvideoxfun_model, not funmodels like the Wan loaders. It's still the same FunModels type under the hood, but the port name is different, so double-check you're wiring it into a CogVideoXFun sampler and not accidentally a Wan one.

The inputs that matter

• model - nine checkpoints across three generations: the original CogVideoX-Fun-2b/5b-InP, the retrained V1.1 line (2b/5b, each with InP, Pose, and Control variants), and CogVideoX-Fun-V1.5-5b-InP. Default is CogVideoX-Fun-V1.1-2b-InP, the lightweight pick. Per the README's model zoo, the 2b tier runs about 13GB and the 5b tier about 20GB.
• model_type - Inpaint or Control. In this pack's vocabulary "Inpaint" doesn't mean masked photoshop-style inpainting; it means the start/end-frame image-to-video training regime. Control means it expects a conditioning video (Canny, Pose, Depth, etc.).
• GPU_memory_mode - the same four-way tradeoff as the Wan loaders: model_full_load (fastest, most VRAM), model_cpu_offload (recommended default), model_cpu_offload_and_qfloat8 (adds fp8 quantization for more headroom), sequential_cpu_offload (slowest, least VRAM).
• precision - fp16 or bf16.

Output: cogvideoxfun_model, into a CogVideoXFun*Sampler node.

Installing it

Search ComfyUI Manager for VideoX-Fun; if it's not showing up (this pack hasn't always been reliably indexed there), install manually:

cd ComfyUI/custom_nodes
git clone https://github.com/aigc-apps/VideoX-Fun
pip install -r VideoX-Fun/requirements.txt

Restart ComfyUI. Then grab the full HuggingFace repo for whichever checkpoint you picked - the whole folder, not a single file - and place it under ComfyUI/models/Fun_Models/<exact-name>/, matching the dropdown string precisely.

Common issues

You picked the wrong model_type for the checkpoint. -InP checkpoints are Inpaint type, -Pose and -Control checkpoints are Control type. Mismatching these is a common source of a load that "works" but produces garbage - the node loads the weights fine, it's the conditioning pipeline that's wrong for that checkpoint.

The dropdown is empty. Same folder-naming trap as every loader in this pack: the checkpoint folder under Fun_Models/ has to match the dropdown string exactly, and it needs to be the complete HF repo, not just the safetensors.

Should you even use this over Wan? Honestly, probably not for new work. The wider community moved to Wan 2.1/2.2 because it's a stronger model across the board - better motion, better prompt adherence, a much bigger LoRA ecosystem. CogVideoX-Fun is worth reaching for if you have an existing workflow built on it, you're doing V1.1's Pose-conditioned generation specifically, or you just want a lighter model (the 2b tier is noticeably cheaper to run than any Wan checkpoint). For everything else, LoadWan2_2FunModel or LoadWan2_2Model is where the active development and community knowledge is.