Multi Prompt Text Encode

This is the pack's headliner and the node you'll actually use. One prompt per line, and each line becomes one item in a single batched conditioning - so latent batch item 1 draws prompt 1, item 2 draws prompt 2, and so on, all inside one sampler execution. The README is emphatic about what this is not: it's not queue automation, not N jobs fired off in sequence. It's one pass that renders N different images. Think prompt A/B sheets, scene-variant grids, a row of character concepts - the thing you'd otherwise do by re-running the graph and screenshotting.

You might think that's a crowded space - Endless Nodes and friends have shipped multiprompt batching for various backbones - but this pack keeps it boring and portable: pure conditioning math, no per-model special cases. Which is exactly why it slots into any workflow, including the official Krea 2 FP8 one the README walks through.

How it works

The mechanism is straightforward and grounded in the source. The node splits the multiline prompts text on line breaks, strips whitespace, skips empty lines (both defaults on), then enforces a cap: max_prompts, default 9, adjustable up to 4096. Each line gets tokenized and encoded with the connected CLIP object, then all the results are stacked by the same machinery its sibling Conditioning Batch Stack uses: concatenate along the batch dimension, pad the sequence length up to the longest prompt, and stack the attention_mask metadata with the padded tokens masked off. For models like Krea 2 - whose conditioning tensor is shaped (B, seq, 12*2560) - that batch-first layout means differently-lengthed prompts stack cleanly with no manual fiddling.

Inputs and outputs that matter

You only really touch three things. clip (CLIP) is the model's text encoder. prompts is a multiline text box - one prompt per line. And max_prompts caps how many lines it'll accept; if you're building a grid bigger than nine, bump it.

The three outputs are the clever part:

• conditioning (CONDITIONING) → KSampler positive. This is your batched prompt.
• batch_size (INT) → EmptyLatentImage.batch_size. Wire it in (convert that widget to an input) and the latent batch always matches your prompt count. That's not a convenience, it's a bug-preventer.
• prompt_list_text (STRING) → the cleaned, stripped prompt list. Handy for a filename or label node so each image in the grid gets named after the line that made it.

The README's minimal Krea 2 workflow keeps the normal model, VAE, and sampler; it just swaps the positive encoder for this node, sends batch_size to EmptyLatentImage, and keeps the negative as a shared batch-1 ConditioningZeroOut (which broadcasts through the sampler path). Three prompts → batch size 3 → three images in one run.

Install and the gotchas

Install is the standard two routes - ComfyUI Manager, search "multi prompt batch", or:

cd ComfyUI/custom_nodes
git clone https://github.com/JousiaPiha/comfyui-multiprompt-batch

Restart, and the nodes appear under conditioning/multi prompt batch. The pack itself has zero dependencies beyond torch - no requirements.txt, no model files. The models are a separate matter: on Krea 2 you need its standalone Qwen3-VL text encoder and Qwen-Image VAE files, which new users routinely miss (a good reason to grab the ready-made FP8 workflow rather than assembling it blind).

The failures are all honest ones. clip wired to a checkpoint with no text encoder produces the node's own "clip input is invalid: None" error - load the right CLIP. More than max_prompts lines raises, as does an all-empty prompt list, so the node refuses to guess. And if the sampler throws a shape error, count lines versus latent batch size - the two must match, which is why the batch_size output exists. Respect those limits and it's the closest thing to "type a list, get a grid" that ComfyUI ships without a queue.