TIPO Single Operation

This is the power-user version of TIPO. The plain TIPO node picks a generation strategy for you based on your tag_length/nl_length settings and just runs it. TIPO Single Operation instead makes you name the exact conversion you want the model to run - tags into a longer form, a natural-language description condensed back down to tags, and a couple of two-hop combinations in between. If you already know precisely what transformation you're after, this is the node that lets you say so directly instead of hoping the defaults land there.

What "operation" actually controls

Swap TIPO's format field for an operation enum, and the options tell you exactly what's on offer: None, long_to_tag, short_to_tag, short_to_tag_to_long, tag_to_long, tag_to_long_to_short, tag_to_short, tag_to_short_to_long. Read them as <source>_to_<target> - tag_to_long takes your seed tags and expands them into a long-form generation; long_to_tag goes the other way, condensing a long description down into tags. The two-hop ones (tag_to_short_to_long, short_to_tag_to_long) route through an intermediate length on the way to the target, which is presumably there for cases where a direct jump produces worse results than stepping through a middle length first. None, the default, behaves like a plain generation without forcing one of these specific conversions.

This is genuinely the low-traffic, deep-end node of the pack - if the whole "operation" concept doesn't obviously map to a problem you have, you almost certainly want the plain TIPO node instead, which is documented in its own article.

The inputs and outputs that matter

The required fields are identical to TIPO minus format, plus operation: tags, nl_prompt, ban_tags, tipo_model, width, height, temperature, top_p, min_p, top_k, tag_length, nl_length, seed, device. Same model dropdown (100M–500M, some GGUF-quantized), same sampling knobs, same recommendation from the README to keep tag_length/nl_length at short or long rather than the extremes.

The outputs are where this node diverges from plain TIPO: full_output and addon_output, both typed LIST - not ready-to-use prompt strings. This node hands you raw structured generation results, not a formatted prompt. To turn them into something you can actually plug into a CLIP Text Encode node, wire them into TIPOFormat, which applies a template and gives you back the same four string outputs (prompt, user_prompt, unformatted_prompt, unformatted_user_prompt) that the all-in-one TIPO node produces directly.

Installing it

Same pack, same install as every node here. ComfyUI Manager: search "TIPO-extension." Or:

cd ComfyUI/custom_nodes
git clone https://github.com/KohakuBlueleaf/z-tipo-extension

Restart, find it under utils/promptgen. Model weights download from Hugging Face on first use of a given tipo_model choice, same as the plain TIPO node - no separate weights for this one.

Common issues

The one people actually hit: expecting this node to behave like plain TIPO and connecting full_output/addon_output straight to a text field. It won't work - those are LIST outputs and ComfyUI's type system will refuse the connection. You need TIPOFormat between this node and anything expecting a string.

Beyond that, most of what applies to TIPO applies here too, since it's the same underlying model and sampling settings: stick to short/long for the length fields per the README's own guidance, keep temperature near the 0.5 default if output looks incoherent, and pick a GGUF model entry if you're CPU-only or tight on VRAM. Given how rarely this node shows up in searches, the honest advice is: reach for it only once you've hit a concrete limitation with plain TIPO and know which specific conversion you need - otherwise you're adding graph complexity (this node plus a TIPOFormat node) for no benefit over the one-node version.