BMAB Flux Integrator

Every BMAB workflow needs one of these - or its sibling, BMAB Integrator - as the very first node, because this is where BMAB's whole pipeline design starts. Downstream, every sampler and detailer node in this pack (KSampler, Face Detailer, Zoom Out, and the rest) takes and returns a single bind wire instead of separate model/clip/vae/seed connections at every node. This node is what creates that bind in the first place: hand it your model, clip, vae, prompt, and a couple of Flux-specific settings, and it packages the whole thing into one bundle that flows through the rest of your graph.

Why Flux gets its own Integrator

BMAB Flux Integrator is the leaner of the two entry points, and the gaps tell you something real about how Flux differs from SD1.5/SDXL. Its sibling, BMAB Integrator, has a stop_at_clip_layer field (that's CLIP skip) and token_normalization/weight_interpretation fields (prompt-weighting-syntax dialects, the (word:1.2)-style emphasis conventions). This node has none of that, and there's a real reason: Flux is prompted through T5, not CLIP, and CLIP-skip and classic prompt-weighting syntax are CLIP-era conventions that don't have anything to attach to on an LLM-class text encoder. There's also no negative_prompt field here - Flux's guidance-distilled sampling generally makes negative prompts inert by default, so BMAB doesn't ask for one on this node the way it does on the SD1.5/SDXL Integrator.

What Flux does need that the other Integrator doesn't have is guidance (default 3.5) - Flux's own guidance-scale parameter, standing in for classic CFG on a guidance-distilled model. 3.5 is a reasonable, commonly-used starting point; push it up for stronger prompt adherence at some cost to naturalness, down for looser, more organic output.

The rest of the required inputs

model, clip, and vae are exactly what they sound like - your Flux checkpoint's three components, from whatever loader you're using upstream. context is a required input of BMAB's own CONTEXT type; the README doesn't document its producer beyond the type itself, so wherever it's coming from in your graph, make sure something upstream actually emits a CONTEXT before wiring this node - it's not optional. prompt is your text prompt, single field (no negative, as above).

The optional inputs

seed_in takes a SEED-typed value - this is where BMAB Seed Generator plugs in, if you want one seed governing your whole pipeline rather than an implicit default. latent lets you start from an existing latent instead of Flux generating one internally. image lets you seed the pipeline with an existing image (useful for img2img-style Flux workflows through BMAB).

Output is a single bind - nothing else. Everything downstream - BMAB KSampler, the detailer nodes, Zoom Out, Square - takes that one wire from here on.

Installing it

ComfyUI Manager: search comfyui_bmab, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/portu-sim/comfyui_bmab.git
cd comfyui_bmab
pip install -r requirements.txt

plus comfyui_controlnet_aux and ComfyUI_IPAdapter_plus, the two companion packs the README asks for regardless of which BMAB node you're using.

Where people get stuck

The most common miss is treating this like an ordinary model loader and being confused when nothing downstream works without a bind connection - every BMAB sampler and detailer node expects that bind, not the raw model/clip/vae you might be used to wiring individually elsewhere in ComfyUI. The second is the context input: it's required and easy to overlook since it's not one of the "obvious" fields like model or prompt, and there's no default fallback documented if you leave it unconnected.