zhenzhen-image-g-v2.5-official（Flare/Sunburst）

Same model family as the lowprice node next door, different door. This one is the "official" routing of zhenzhen-image-g-v2.5, and the giveaway is the control panel: quality, output_format, output_compression, background, moderation, n up to four. That's roughly the shape of the first-party image API, exposed through the reseller. The lowprice node deliberately doesn't give you any of it.

The dropdown at the top is model, with two entries - zhenzhen-image-g-v2.5-flare and zhenzhen-image-g-v2.5-sunburst. These are the two codenames the vendor sells this model under, and no, there's no public documentation explaining the difference. The honest answer is that you should run the same prompt through both once and pick the one you prefer; anyone claiming to know which is "officially better" is reading tea leaves. Both are the same API call with a different model string in the payload.

How it works

Async job, same as the rest of the domestic channel: uploads references, submits, polls, downloads, hands back an IMAGE. Nothing strikes, no weights load, no VRAM is touched.

Look at the payload logic and there are three modes:

• A ratio like 16:9 sends size: "16:9" plus resolution: "1k" | "2k" | "4k" - a normal preset render.
• custom ignores resolution entirely and parses custom_size instead, a WIDTHxHEIGHT string. Multiples of 16, no side over 3840, aspect ratio inside 1:3–3:1, and total pixels between 655,360 and 8,294,400, or it refuses before spending anything.
• preserve_reference sends resolution and nothing for size - the output keeps the reference image's framing. Great for "re-render this shot at 2k" without the aspect drifting.

Eighteen options in that dropdown and the default is auto, which is the right default: let the service decide from the prompt.

The rest of the panel

quality runs auto, low, medium, high, xhigh, max. On this route quality isn't decoration - it's a spend multiplier, so leave it on auto until you have a reason.

n is 1 to 4 images per call, returned as a batch on image. All frames have to match dimensions to form that batch, so mixing sizes in one call isn't a thing.

output_format is png, jpeg or webp, and output_compression (0–100) is only actually sent for jpeg and webp - silently irrelevant on PNG. background is auto, transparent or opaque, and transparent with jpeg is a hard error, which is sensible: JPEG has no alpha. If you want cutouts, PNG or WebP it is.

moderation defaults to low here rather than auto - the opposite of the GPT node in this pack, and a fair guess at what the vendor's customers want.

Then image1–image16 references (one more slot than the lowprice node, and they're submitted in wired order), api_config for the Settings node, skip_error, and seed, which is ComfyUI cache control only and never leaves your machine.

Outputs

image, image_url, task_id, response. The task_id is the important one on this channel: when ComfyUI throws a timeout, the job may well have completed on the server, and this ID is how you find it in the site's async task list and download the file manually. Unsuccessful upstream tasks are generally refunded, so a visible ID is also how you tell "genuinely failed" from "my node stopped waiting".

Install

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-zhenzhen

or ComfyUI Manager → search Comfyui-zhenzhen. Restart. Dependencies come from the pack's requirements.txt and are unremarkable - requests, Pillow, numpy, torch, aiohttp, opencv, openai - and there are no model weights to fetch, because there is no local model.

To make it run you need a T8Zhenzhen_API_Settings node with your key, its api_config output wired to this node's input. The Settings node's base-url selector has three positions; the domestic shop is the default.

Where people get burned

Empty key: the node tells you, in the error, which node it wants connected. Not charged but also not useful: 429 and 500 from upstream, which is the provider being busy, not your workflow - rerun. Real trap: a custom_size that isn't a multiple of 16, or a tall thin 9:21 request that lands outside the ratio clamp; both fail validation rather than producing a cropped surprise.

And one expectation to set. This pack has almost no English-language community presence - I searched the corpus for the author, the pack and the model names and found essentially nothing - so no thread will tell you which of Flare and Sunburst is better, or what xhigh costs versus high. Treat the two model strings as an A/B test you run yourself, and read the response JSON when you want to know what was actually sent.