Padding Removal
Cleaning up T5 padding tokens for Chroma
- conditioning
- CONDITIONING
This is the smallest, plainest node in ComfyUI_FluxMod's Chroma corner - one input, one output, no tooltip, no widgets. It takes a CONDITIONING and returns a CONDITIONING. Same caveat as this pack's other Chroma nodes applies: the README marks the whole Chroma section deprecated in favor of ComfyUI's native Chroma support, so treat this as legacy plumbing you might meet in an older workflow rather than something to reach for by default.
What it's for is grounded in Chroma's own architecture. Chroma isn't a plain Flux checkpoint - it's LodestoneRock's heavy rework of Flux Schnell, and one of the three documented changes from stock Flux is how it handles T5's padding tokens: Chroma masks them explicitly, "for fidelity and training stability," rather than letting them sit in the conditioning the way stock Flux does. T5 pads every prompt out to a fixed sequence length, and short prompts end up with a long tail of pad tokens attached to their conditioning. This node's name and position in the pipeline line up with exactly that: stripping or masking that padding out of the conditioning before it reaches the Chroma model, matching how the model was actually trained.
What it does
No inputs beyond conditioning, no options to tune. You drop it between your text encode step and the sampler - right where you'd otherwise wire conditioning straight through. Because there's nothing to configure, there's also nothing to get wrong here beyond forgetting to include it at all.
How to install it
Via ComfyUI Manager: search "ComfyUI_FluxMod," install, restart. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/lodestone-rock/ComfyUI_FluxMod.git
Restart ComfyUI and refresh your browser. This particular node needs nothing extra beyond a working T5 text encode step feeding it - no model downloads of its own.
Common issues & troubleshooting
You're using ComfyUI's official native Chroma workflow and don't see this node anywhere. That's expected and fine - the built-in Chroma implementation handles the T5 padding question internally, so there's nothing for you to wire manually. This node only matters if you're specifically working from an older FluxMod-based Chroma graph.
Unsure whether you actually need it in your graph. If your workflow already uses ComfyUI's stock UNETLoader plus the official Chroma example, don't add this - it belongs to the deprecated FluxMod-based path, not the current one. If you inherited a workflow that already has it wired in between your CLIP text encode and your sampler, leave it where it is rather than second-guessing it.
Prompts feel off or inconsistent on Chroma even with this node in place. That's more likely the model's well-documented appetite for verbose, descriptive prompting than anything to do with padding handling - short, tag-style prompts are the more common cause of unreliable Chroma output.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| conditioning | CONDITIONING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CONDITIONING | CONDITIONING | — |