☁️BizyAir ReActor 🌌 Options

The plain BizyAir_reactor node bakes its face-selection and detection settings directly into itself - every instance of that node has its own copy of input_faces_index, detect_gender_input, and so on. That's fine for a single swap. It gets tedious the moment your workflow needs several swaps sharing the same rules (same face-ordering convention, same gender filter) - you'd otherwise be re-entering identical values on every node. This node exists to break those settings out into one reusable bundle, wired into BizyAir_ReActorPlusOpt nodes instead of duplicated across them.

The inputs that matter

• input_faces_order / source_faces_order - six choices each: left-right, right-left, top-bottom, bottom-top, small-large, large-small (default). This decides how detected faces get numbered when there's more than one in an image, which matters directly for the next field.
• input_faces_index / source_faces_index - which face, by that ordering, actually gets used. Default "0", the first face under whatever ordering you picked.
• detect_gender_input / detect_gender_source - no / female / male. A filter, not a guarantee - it restricts which detected faces are eligible before the ordering and index selection apply.
• console_log_level - 0/1/2, controlling how much the swap operation logs. Mostly useful if you're debugging why a swap picked the face it did.

Output: a single OPTIONS bundle, built specifically to plug into BizyAir_ReActorPlusOpt's options input - it doesn't connect to the plain BizyAir_reactor node, which has no socket for it.

Installing it

ComfyUI Manager: search BizyAir, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/siliconflow/BizyAir.git

Set your BizyAir API key on first use.

Where people get burned

The main point of confusion is expecting this node to do something on its own - it doesn't touch an image, doesn't run a swap, doesn't have an image input at all. It's purely a settings container, and its output is useless unless something downstream actually reads it. If you're not also using ReActorPlusOpt, you don't need this node; the plain BizyAir_reactor node has the same fields built directly into it.

The second trap is the ordering-versus-index interaction, which isn't specific to this node but is easy to get backward here since the two live on separate fields: _order decides how faces get numbered (spatially, by position), and _index decides which of those numbered faces gets picked. Change the photo's composition - a face that moves from left to right in a new source image - and an index that worked before can silently point at a different face after, if you're using a positional ordering like left-right. If a swap that used to grab the right person starts grabbing someone else after you change source images, check whether the ordering convention actually matches the new composition before assuming the index itself is wrong.