Nodes/RES4LYF/ConditioningDownsample (T5)
ComfyUI Node Runs on cloud

ConditioningDownsample (T5)

Trim a bloated T5 conditioning down for speed

By ClownsharkBatwing·Created 2 years ago·Updated 18 days ago· 1,222
ConditioningDownsample (T5)
  • conditioning
  • conditioning
token_limit128

A chunk of the current model lineup - Flux, SD3.5, HiDream, Chroma, AuraFlow - conditions on a T5-XXL text encoder, and T5 sequences can run long. Every extra token in that conditioning means more compute in every cross-attention operation, at every sampling step. ConditioningDownsample (T5) compresses the T5 side of your conditioning down to a target token count, trading some conditioning precision for speed and lower memory pressure.

How it works

You hand it a T5-based conditioning and a token_limit, and it downsamples the sequence to fit that limit before it ever reaches the sampler. This is a different problem from the classic CLIP 77-token cutoff (that's what this pack's ConditioningTruncate and ConditioningZeroAndTruncate handle, and it's specifically about SD3.5's CLIP path degrading past 77 tokens). This node is a general performance lever for T5-conditioned models, not a correctness fix for a known bug - you're deliberately choosing to carry less conditioning information in exchange for a faster or lighter run.

The inputs and outputs that matter

  • conditioning (CONDITIONING) - the T5-based conditioning you want compressed.
  • token_limit (INT, default 128, range 1–16384) - the target token count after downsampling. Lower means faster and lighter, but with less of the original prompt's detail carried through.

Output: conditioning (CONDITIONING), ready to wire straight into your sampler.

Worth being clear about what you're spending to get that speed back: a T5 encoder's whole advantage over the old CLIP-only setups is that it's a real language model, capable of following long, detailed, natural-language prompts instead of just tag soup. Downsampling the sequence trims exactly the capacity that made T5 conditioning worth adopting in the first place. That's not a reason to avoid this node - it's a reason to use it deliberately, on prompts where you've already established the extra length wasn't buying you much, rather than reaching for it reflexively on every generation.

How to install it

Via ComfyUI Manager, search "RES4LYF". Or:

cd ComfyUI/custom_nodes
git clone https://github.com/ClownsharkBatwing/RES4LYF/
cd RES4LYF
pip install -r requirements.txt

then restart.

Common issues & troubleshooting

There's no universally "safe" token_limit - it depends on how long and detailed your prompt actually is and how much fidelity you're willing to trade. Treat the default of 128 as a starting point, not a validated number, and compare a downsampled run against the untouched conditioning before trusting it in a production workflow.

Don't confuse this with the SD3.5 truncation nodes. ConditioningTruncate and ConditioningZeroAndTruncate exist because SD3.5's CLIP component actively degrades past 77 tokens - that's a specific bug workaround, not a speed lever, and this node doesn't do that job. If you're on SD3.5 chasing the quality-cliff problem, use those instead.

If prompt adherence drops noticeably after adding this node, that's expected behavior, not a malfunction - you asked it to throw away tokens. If the loss is unacceptable, raise token_limit rather than assuming something's broken.

CategoryRES4LYF/conditioning

Inputs (2)

NameTypeDefaultDescription
conditioningCONDITIONING
token_limitINT1281–16384

Outputs (1)

NameTypeDescription
conditioningCONDITIONING