BitDance Text Encode

In a normal ComfyUI workflow, text encoding is the cheap little node at the top of the graph - a CLIP model hums for a second and spits out conditioning. Not here. In BitDance, "text encoding" means running your prompt through a 14-billion-parameter Qwen3 language model, the same one the loader warned you about. That's the entire point of the architecture: the LLM acts as the brain that plans the image, and a tiny binary diffusion head just renders the plans. So BitDance Text Encode is where you spend the first big chunk of your VRAM budget, and where you get some of the best prompt understanding you've seen from a local model.

The node takes your text_encoder (from BitDance Loader) plus two multiline prompt boxes - positive_prompt and negative_prompt - and returns three outputs: positive and negative (BITDANCE_TEXT_EMBEDS, which you wire straight into BitDance Sampler), plus a positive_prompt string passthrough you can reuse elsewhere in your graph.

The inputs a beginner actually sets

The two prompt boxes are it. The rest are optional plumbing for VRAM management, and the defaults are right:

• force_offload (default false) - when true, the text encoder is offloaded to RAM after encoding. BitDance's old OOM crash was exactly this: the 14B LLM and the main model trying to share the card at once. If you're on 16–24 GB, it's worth flipping on.
• model_to_offload - feed it the loader's bitdance_model and the node will push the main model out of the way while the LLM encodes, then restore it. This is the "swap the big weights so they don't collide" move.
• use_disk_cache (default false) - writes the encoded embeddings to disk. If you re-run the same prompt, the encode step is skipped. This is the exact feature the Cached variant turns on by default.
• device - gpu or cpu. Encoding on CPU is a last resort for tiny cards; it's slow but it frees VRAM for sampling.

The mechanism, briefly

Your prompt is tokenized with the bundled BitDance tokenizer and embedded by the Qwen3 LLM. Those embeddings get prepended to the image-start tokens during sampling - so the LLM's "plan" conditions every visual token the model types out. That's why BitDance follows long, descriptive prompts so well and why prompt structure matters more than it does with, say, SDXL.

Gotchas

Two things catch people. First, the first encode is slow - you're loading and running a 14B model, so give it a minute and don't assume it froze. Second, if you change only the negative prompt, the whole 14B pass runs again unless you've cached. That's precisely why the README's recommended workflow reaches for BitDance Text Encode Cached instead. Use this plain node when you're iterating on a fresh prompt and want zero cache surprises; use the Cached variant once you've settled on wording and just want speed on reruns.

Install both at once: ComfyUI Manager → search "Comfyui-bitdance", or git clone https://github.com/aistudynow/Comfyui-bitdance into custom_nodes, pip install -r requirements.txt, restart.