FunPack CLIP Loader

If you've tried to run LTX-2.x in stock ComfyUI, you know the drill: the text encoder isn't one file, it's two - a Gemma 3 12B encoder plus a separate "connector" bridge - and the built-in CLIP loaders don't always play nice with that shape. The FunPack CLIP Loader is that problem's answer. It's the text-encoder loader from ComfyUI-FunPack, DigitalGarbage's solo-built suite of LTX-2 / MiniMax H3 tooling, and it's designed around the two cases people actually hit: LTX-2.3's Gemma3 + connector pair, and LTX-2.5's newer single-file Gemma4.

The pitch is simple: one loader that handles almost any text encoder family, in almost any shape, with GGUF quantized encoders mixed right in. Stock loaders are hardwired to an architecture; this one just asks which family it's for.

How it works

Instead of one filename, clip_list is a dynamic slot list - you click + Add slot for each encoder file, in load order. That's the whole mechanism: one slot for LTX-2.5 (Gemma4 is a single file), two for LTX-2.3 (Gemma3 then its connector, in that order). Each slot is a dropdown over everything in ComfyUI/models/text_encoders, plus any .gguf files.

The type dropdown tells the loader which model family the encoder belongs to - the default ltxv covers all of LTX-2's point releases, minimax is for MiniMax H3, and there are 35 options total (stable_diffusion, flux, sd3, hunyuan_video, cosmos, and friends), so it doubles as a universal CLIP loader if you keep it installed.

The clever bit is GGUF handling. The loader detects a GGUF container by extension or by file magic, so even a renamed file is caught. If any slot is GGUF, it loads every encoder as a raw state dict and assembles them via load_text_encoder_state_dicts - which is what lets a quantized GGUF Gemma sit next to a .safetensors connector, the normal LTX-2.3 setup. No need for a separate GGUF node pack; the gguf Python package ships in FunPack's requirements.

The inputs that matter

• clip_list - the slots. This is the one beginners trip on: the order and count are dictated by your model's encoder shape, not vibes. Empty list → the node refuses to run.
• type - encoder family. ltxv for anything LTX-2, minimax for H3. Wrong family means the weights bind wrong, so match your checkpoint.
• device - default or cpu. Pinning it to cpu keeps the whole encoder off the GPU: slower prompt encoding, but a big chunk of VRAM back for the diffusion model. With Gemma 3 being a ~22GB fp16 monster, this is a legit OOM escape hatch, not a curiosity.

Outputs: CLIP, which wires straight into your conditioning node (or FunPack's own conditioning/Studio), and a status string that reports what loaded, in what order, and any GGUF quirks it noticed (like "named .safetensors but is a GGUF container"). Worth piping to a text display while you're setting up - it tells you the truth about your files.

Installing it

Install the pack once - the loaders all ship together:

cd ComfyUI/custom_nodes
git clone https://github.com/olivv-cs/ComfyUI-FunPack

then restart ComfyUI. Easier: ComfyUI Manager → Custom Nodes Manager → search ComfyUI-FunPack → Install, or comfy node install ComfyUI-FunPack if you use comfy-cli. The same codebase also lives at digital-garbage/ComfyUI-FunPack; it's the same hobby project, one maintainer, so don't expect enterprise polish. Then put your encoder files in ComfyUI/models/text_encoders - Gemma4 for LTX-2.5, or Gemma3 + connector for 2.3, plus GGUF quant versions if you want them.

Troubleshooting

• "Add at least one text encoder file." - the list is empty; click + Add slot.
• OOM during encoding - the classic LTX-2 trap. Grab a GGUF-quantized Gemma (the dropdown lists them) or set device to cpu.
• Wonky UI in a plain workflow - since v4.0.0 FunPack targets its own Cutting Room editor and the maintainer says node compatibility with the regular frontend isn't guaranteed or tested. The loader still works in a stock graph; just don't expect the slots to render as prettily.
• Encoder conflicts - FunPack expects transformers >= 5.0.0; if you're on an older env, pip install -r requirements.txt before blaming the node.