YK-ComfyUI-HybridI2I-OSS

Here's the first thing to know about YK_HybridI2I_OSS: the name is mostly true, but it's not a "node that generates images" in the way you're used to. It doesn't load a checkpoint, it doesn't sample anything, and it needs zero VRAM. It's an API-wrapper node - a dispatcher that uploads your reference images, fires them at up to three paid cloud backends, and hands the returned image back to your graph like a local sampler made it. If you've used a ComfyUI API node for Nano Banana or Veo, the shape is familiar; the batch plumbing and failover logic are the whole point here.

What it actually does

This is a batch img2img node built for a production pipeline, not for playing around. The README's framing is unambiguous: up to 10 groups of jobs (A–J), each with up to 3 reference images and its own prompt, sent through a fixed fallback strategy - 社区版 (RunningHub community) → 全能Xinbao (a reseller proxying gemini-3-pro-image-preview) → 官方PRO版 (RunningHub official PRO). Each mode has its own attempt count; set one to 0 and it's skipped. First success wins, and the surviving image is uploaded to Aliyun OSS, where a callback_url POST eventually tells your backend "the batch is done, here are the paths." The sample callback URL in the README points at the author's own service - this is a tool written for one specific Chinese workflow that happens to be public.

The three backends, in plain terms

• Community + Official PRO both use your runninghub_api_key against runninghub.cn's open API (/openapi/v2/rhart-image-n-pro/edit and the -official variant). The node submits a task, polls /task/openapi/status every 3 seconds up to max_wait_time (30–600s), then pulls the result URL. RunningHub is a real, current cloud GPU/ComfyUI platform - the English community knows it as a cheaper, China-side alternative to Runpod.
• 全能Xinbao is a one-shot generateContent POST to xinbaoapi.dpdns.org with its own Bearer key - a Gemini-image reseller. ("Xinbao" ≈ "all-in-one treasure chest.") Resellers exist for cost, region, and billing friction, and the vendor's moderation follows the model, not the node.

You need at least one mode with attempts ≥ 1, or it refuses to run. And here's the gotcha most people will trip on: the seed input does nothing. The source draws a fresh random.randint for every attempt and never forwards your widget seed. Set it, ignore it, whatever - you're paying per call, and reproducibility isn't what this node sells.

Inputs and outputs that matter

The required inputs that actually run the show: the three attempt-count ints (this is the failover strategy), the two API keys, image_hosting (ImgBB or 阿里云 OSS) plus its key/OSS credentials, resolution (1K–8K), aspect_ratio, max_wait_time, global_concurrent_tasks (1–10 groups in parallel), and callback_url.

The optional inputs are per-group: image_A_a/b/c, prompt_1, batch_count_1, and so on through J. Multi-line prompts are the sneaky one - each line becomes a variant, and once you have more than one line, batch_count is ignored entirely.

Outputs: 输出_1 through 输出_10 (one IMAGE per group), 所有成功图像 (all real successes concatenated into one batch), and 上传图片URLs (a STRING of each group's reference-image URLs). Failed groups come back as a 64×64 black placeholder, which 所有成功图像 filters out - so wire that output if you only want the wins.

Install and the OSS trap

ComfyUI Manager → search YK-ComfyUI-HybridI2I-OSS, or:

cd ComfyUI/custom_nodes
git clone https://github.com/ds-fae/YK-ComfyUI-HybridI2I-OSS.git
pip install oss2 requests Pillow

Then restart. No model files, no heavy deps beyond oss2. The README is honest about the network requirements: your machine must reach runninghub.cn and xinbaoapi.dpdns.org, which rules this out behind some corporate firewalls.

The trap: image_hosting only controls where your reference images go. Result images always upload to Aliyun OSS - the code calls upload_to_aliyun_oss unconditionally on success. So even if you pick ImgBB to dodge OSS, you still need complete AK/SK/bucket/endpoint to get any real output, and the bucket needs public-read. The endpoint auto-completes to .aliyuncs.com, which is a small mercy. Failures log to the ComfyUI console - a 64×64 result means "everything tried and died," so read that console before touching the workflow.

Is it for you?

Honestly? If you're not on the China stack - RunningHub credits, Aliyun OSS, a callback endpoint - this node is a lot of ceremony for images you could get from one reseller directly. It's also new: a single-maintainer, 0-impression pack at version 4.0.2 with no community track record. Two habits to keep: your keys live in the node's widget values, which get saved into workflow JSON - don't commit that; and API-wrapper nodes are the category that already shipped malware once, so glance at the source before trusting it. But if you run batch img2img against cloud APIs for a living, the failover logic is the rare thing that does exactly what its README claims.