☁️BizyAir CLIP Vision Encode

Most nodes in this pack lock you into an all-BizyAir chain - the moment you touch a BIZYAIR_MODEL or BIZYAIR_CONDITIONING wire, everything upstream and downstream has to be BizyAir too. This one's the exception, and it's worth knowing which BizyAir node breaks that rule. clip_vision is typed plain CLIP_VISION, image is plain IMAGE, and the output is plain CLIP_VISION_OUTPUT - every type here is stock ComfyUI. That means you can drop a completely ordinary "Load CLIP Vision" node in front of it and feed the output into a completely ordinary downstream node (an IPAdapter-style node, an unCLIP conditioning node, whatever your workflow calls for) without anything else in the graph needing to be BizyAir-flavored.

What it does: takes an image and a CLIP vision model and produces a CLIP_VISION_OUTPUT - a vision embedding capturing what's in the image at a semantic level, as opposed to its spatial structure. This is the building block behind image-prompting techniques: instead of describing a reference image in words, you encode it and hand the embedding to a node that knows what to do with it (style/subject transfer, image variation, anything that conditions on "generate something like this picture" rather than "generate something that matches this text"). It's the same job the stock CLIPVisionEncode node does - this is BizyAir routing the actual encode through their cloud rather than running it on your own GPU, while keeping the interface identical to the node everyone already knows.

Inputs that matter: just the two required ones. clip_vision - load this from whatever CLIP vision checkpoint your downstream node expects; get this wrong (mismatched vision encoder) and you'll get an embedding that doesn't mean what the downstream node thinks it means, silently. image - the reference image you're encoding, straightforward.

Output: CLIP_VISION_OUTPUT. Where it goes depends entirely on what you're building - this node produces the embedding, it doesn't consume it. Since the type is standard, whatever consumes CLIP_VISION_OUTPUT elsewhere in ComfyUI (stock or third-party) will accept it fine.

Install: the usual three routes - search "BizyAir" in ComfyUI Manager and install, git clone https://github.com/siliconflow/BizyAir.git into custom_nodes and restart, or comfy node install bizyair on the Comfy CLI. All three install the whole pack; there's no way to grab just this node. And even though its wire types are ordinary, this node is still a BizyAir node under the hood - it still routes through SiliconFlow's API to do the actual encoding, so you still need a registered BizyAir account with your API key set for it to run. The README says it plainly: set your key the first time, before anything else.

Where to expect friction: because this node's inputs and outputs look completely normal, it's easy to forget it's a cloud node at all until it fails - if it stalls or errors with no obvious graph problem, that's the API key/authentication check to make first, same as every other BizyAir node, even though nothing about its wiring hints at that dependency. Beyond that, the usual CLIP vision gotcha applies regardless of vendor: make sure the vision checkpoint you're loading actually matches what your downstream consumer (IPAdapter, unCLIP, etc.) was built against - a mismatched vision model is a much more common cause of "this does nothing" than anything specific to BizyAir.