ConditionTextMulti

ConditionTextMulti is four independent CLIPTextEncode calls squeezed into a single node - four text fields in, four separate CONDITIONING outputs out, all sharing one CLIP input. If you find yourself placing three or four CLIPTextEncode nodes side by side for a workflow that needs several distinct conditionings - regional prompting, a few different style variants you're comparing, multiple ControlNet or IP-Adapter stages each wanting their own text - this collapses that into one node and one CLIP wire instead of a small forest of duplicated nodes.

How it works

It's mechanically nothing fancier than four CLIPTextEncode nodes wearing a trench coat. Each of the four text fields - first, second, third, fourth - gets encoded independently against the same CLIP model you feed in, and each produces its own CONDITIONING output. There's no interaction between the four; changing first has zero effect on what second encodes to. Leave any of them blank and it just encodes an empty string, which CLIP handles fine - you'll get a neutral, unconditioned CONDITIONING out of that slot rather than an error.

The inputs and outputs that matter

• clip - required, shared across all four encodes.
• first, second, third, fourth - all optional, all single-line text fields, all default to empty. Fill in only as many as you actually need; the rest just pass through as empty-string conditionings you can leave unwired downstream.

Five outputs: CLIP (passthrough, so you can chain into another text node afterward without a second wire back to your checkpoint), and first/second/third/fourth, each a CONDITIONING wired to whatever you're using it for - different KSamplers, different regions of a masked composite, or a quick four-way comparison batch.

How to install it

• ComfyUI Manager: search "ComfyUI-Chibi-Nodes", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/chibiace/ComfyUI-Chibi-Nodes/, restart.

No models or extra dependencies - it's a thin wrapper over ComfyUI's own CLIP encoding, so whatever text encoder your checkpoint uses is what this node uses too. It appears under Chibi-Nodes/Text after install.

Keep the pack's own framing in mind: the README calls these "experimental nodes" and admits version 2 came "with more bugs." For something this mechanically simple - four parallel encode calls - that's a low-stakes admission, but it's the reason you won't find much beyond the schema itself documenting exact behavior.

Common issues

The single-line fields are the main practical limit - none of the four text inputs are set to multiline, so this node is built for short phrases per slot (a style tag, a short descriptor), not long paragraph prompts. If you need a longer prompt in one of the four slots, write it in a Textbox node and feed the STRING output in rather than fighting a cramped inline widget.

The other thing to watch: because all four outputs always exist regardless of whether you filled in the corresponding text field, it's easy to accidentally wire an empty-string CONDITIONING into a sampler and wonder why that branch is producing generic, unguided output. If one of your four results looks conditioning-free, check that you actually typed something into that specific field before assuming the node itself is broken.