LLM Output Parser

The idea here is nice and it fits the whole spirit of the pack. If Z-Image's encoder is a language model, why not have another language model write the prompt? Point a local LLM node (LM Studio, Ollama, whatever ComfyUI-side wrapper you use) at a scene idea, have it emit structured JSON or YAML with separate fields for the user prompt, system prompt, thinking, and assistant content - then LLMOutputParser splits that blob into the exact strings the Z-Image encoder wants. It's the glue between "LLM that generates prompts" and "LLM that encodes them."

It's a utility node, not a headliner, and it currently has basically zero search traffic - but if you're building an automated pipeline where one model designs the prompt and Z-Image renders it, this is the adapter that makes the handoff clean instead of you writing string-munging nodes by hand.

How it works

You feed it a chunk of text - ideally structured JSON or YAML from an upstream LLM - and it parses out named fields. It's forgiving about the messy reality of LLM output: it strips code fences (the ```json wrappers models love to add), handles nested keys, and can carry multi-turn conversation state. If parsing fails and you've left the fallback on, it just passes the raw text straight through as the user prompt rather than erroring your whole graph. That last part matters, because local LLMs do not reliably emit clean JSON.

The inputs and outputs that matter

• text_input (required) - the raw output from your LLM node.
• parse_mode (default auto) - auto sniffs the format; json and yaml force it; passthrough skips parsing entirely and treats the whole thing as the prompt.
• The *_key fields (user_prompt_key, system_prompt_key, thinking_key, assistant_key) - tell the parser which JSON/YAML keys map to which encoder field, so you can match whatever schema your LLM was told to produce.
• fallback_to_passthrough (default on) - the safety net; leave it on unless you specifically want a hard failure on malformed input.

Outputs mirror the encoder's inputs one-for-one: user_prompt, system_prompt, thinking_content, assistant_content - wire each into the matching field on ZImageTextEncoder. You also get raw_text (the unparsed original), parse_status (did it parse, and how), and a conversation object for chaining into multi-turn workflows.

How to install it

ComfyUI Manager: search ComfyUI-QwenImageWanBridge, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/fblissjr/ComfyUI-QwenImageWanBridge

then restart. This node has no model of its own - but the pipeline it's built for assumes you've got a separate LLM node in your graph producing the text, plus the usual Z-Image checkpoint and Qwen3-4B encoder downstream.

Common issues & troubleshooting

JSON keys showing up as text in your image. Classic failure mode - an LLM wraps values in quotes and the key names leak into the encoded prompt. Turn on strip_quotes, or use the pack's PromptKeyFilter helper, which exists for exactly this. Keep an eye on parse_status to see what the parser actually extracted.

It's just passing everything through as the user prompt. Parsing failed and the fallback caught it. Check that your LLM is actually emitting valid JSON/YAML and that your *_key names match the keys it used. If your model is chatty and wraps output in prose, tell it in its system prompt to return only the structured block.

The generated prompt is too long and drifts. LLMs love to be verbose, and Z-Image's attention gets loose past ~75-100 effective tokens. Instruct the upstream model to keep the user prompt to a few strong concepts rather than a paragraph - a rich prompt isn't the same as a good one here.