Combine Flux2 Fun Controls (experimental)

Single-control Flux2 Fun got boring, so here's the multi-control node. Gen2_CombineFlux2FunControls takes two complete control setups - control branch, context, strength, start/end - and bundles them into one FLUX2_FUN_CONTROL_GROUP you feed to Gen2_ApplyFlux2FunControl's optional control_group input. Think "stack two ControlNets" from the SDXL days: a canny edge pass to lock composition plus a depth pass for layout, each with its own weight and its own active window.

What it does under the hood

The inputs are two parallel halves, _a and _b, and each half is a full mini-configuration:

• model_a / model_b - the FLUX2_FUN_MODEL outputs from two Gen2_LoadFlux2FunControlNet nodes. Yes, that means loading the same 2602 checkpoint twice into two branches, which is why the loader validates so hard - you're paying for two copies in memory.
• context_a / context_b - two Gen2_PrepareFlux2FunControl outputs, one per condition.
• strength_a / strength_b (0–4, default 1), start_a/start_b and end_a/end_b (0–1, default 0 and 1) - per-control strength and schedule, mirroring the Apply node's own sliders.
• existing_group (optional) - a previous FLUX2_FUN_CONTROL_GROUP to append to, so you can chain more than two controls if you're feeling brave.

The mechanics matter here: the node builds a deterministic, immutable control group - it doesn't fuse or blend the two control nets into one weight, it bundles their descriptors in fixed order, and each descriptor carries its own strength and schedule. The Apply node downstream handles applying them as a group. "Deterministic" isn't a buzzword - it means the same inputs always produce the same group, which is what you want when you're debugging which of the two controls is causing the artifact.

The honest warning

The node's own display name says it: (experimental). The README spells out why - multi-control stays experimental until the complete GPU matrix passes. That's a real caveat, not cover-your-ass boilerplate: the single-control path is validated, the multi-control path is where the implementation is young and the author isn't claiming parity yet. If you're building a production workflow, do your reliability testing on the single-control chain first, then add Combine once you've confirmed the basics hold on your hardware. It's also worth saying plainly: the community rule that stacking conditions gets unpredictable fast (add one at a time, keep a fixed seed) applies here too.

Install

ComfyUI Manager: search ComfyUI-gen2. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/petmycat/ComfyUI-gen2.git
cd ComfyUI-gen2
pip install -r requirements.txt

Restart, and confirm you're on ComfyUI v0.28.0+. Same prerequisites as the rest of the Flux2 Fun section: the 2602 checkpoint in models/controlnet, the Flux.2 Dev stack, no extra Python packages beyond the pack's shared requirements.txt.

The practical takeaway

Use this node when you genuinely need two simultaneous spatial conditions on a Flux.2 Dev image and you've already confirmed single control works on your card. Watch your VRAM - two control branches on top of the 56B Dev stack is a lot of card. And when results get weird, toggle one half's strength to 0 to isolate which branch is misbehaving; the immutable group makes that a clean experiment instead of a teardown.