结果回退丨API

API nodes fail. The rate limit hits, the key expires, the provider is down at 2am - and your whole batch stalls because one cloud call hiccuped. QING_ModelFallback is the QING pack's answer: it takes a primary result and a secondary result, along with a boolean saying whether each is "ok," and returns whichever is usable. It's a fallback switch (external-api-nodes territory) shaped specifically for LLM/API plumbing.

How it works

Inputs are primary_result and secondary_result (both any-typed - text, images, whatever the API node returns), primary_ok and secondary_ok (booleans), and strategy with three options:

• 优先主路 (prefer primary) - primary wins if it's ok, else secondary if it's ok.
• 自动回退 (auto fallback, default) - same result, explicitly framed as "try primary, fall back to secondary."
• 尽力而为 (best effort) - same selection; the difference is in the status reporting (it marks a secondary pick as "ok" rather than "fallback").

Outputs: result (the chosen value), provider_used (STRING - "primary" or "secondary"), and status (STRING - "ok" / "fallback", or an error string if both fail).

Where you'd reach for it

The intended wiring is: two API nodes - say QwenLanguageAPI plus a GLMLanguageAPI or a cheap qwen-turbo - each feeding this node. The upstream API nodes in the pack report their own success/failure (their outputs carry status info), and you map that into primary_ok / secondary_ok. If the flagship model is rate-limited, the graph silently uses the backup instead of crashing the whole workflow. The same shape works for any "try A, else B" need - image models, prompt enhancers, anything where one provider failing shouldn't kill the batch.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/GAO-SHIQING/ComfyUI-QING
cd ComfyUI-QING
python install_dependencies.py

Restart ComfyUI after. Pure logic, no extra dependencies. Manager: search "ComfyUI-QING." (The README's clone URL has a GAOSHI-QING typo; the repo is GAO-SHIQING/ComfyUI-QING.)

Things to know

The most important thing: nobody detects failure for you. This node has no idea whether the API actually succeeded - it only knows what you tell it through the _ok booleans. If you wire primary_ok to a hardcoded true, it will happily pass through an empty or error string as if it were a fine result. Some upstream nodes expose an ok/status output you can convert; otherwise you'll want a HasValue-style check or a string compare on the result before it reaches this node. Both-fail behavior is also worth handling: result comes back None and status becomes an error string, so route status to a log node rather than assuming a result always appears. It's a valve, not a watchdog - wire it right and it's genuinely the thing that keeps a long batch alive.