Relay API Settings

Every node in the ComfyUI-relayapi pack is a passenger; this one drives. RelayAPISettings is the hub that holds your API key, your relay station, your model, and your endpoint format, and hands them to the generators as a single info output. Wire it once, and RelayImageGenerator, RelayVideoGenerator, RelaySoundGenerator and RelayTextGenerator all work off the same configuration.

Here's the mental model that makes the pack click. "Relay API" is the 中转站 (relay station) ecosystem: Chinese resellers like RunningHub, yunwu, t8star and bltcy who buy access to closed models - Grok, Veo, Gemini, GPT Image, Suno - and resell it to you as a single OpenAI-style key. This pack doesn't call Google or xAI directly. It calls whichever relay you point it at, and the relay fronts the closed model. The Settings node is where you tell it who to call, with what key, and using which of that relay's endpoint formats.

How it works

The magic is boring: Settings builds a JSON string and passes it down the info wire. Pick a task_type (image / video / sound / text) and the front-end JS reshuffles the dropdowns - platform narrows to what that task can use, api_format narrows to what that platform supports, and model narrows to what that format can take. Because api_format is named after the endpoint path (v1beta/models, v1/images, v1/chat/completions, runninghub-/openapi/v2, suno/submit…), the model list is always exactly the set that endpoint will accept. No guessing, no "model not found" at runtime.

The apikey field is a masked password box - the front-end hides it with bullet characters and keeps the real value out of the serialized workflow. Your key and any custom endpoints or models are persisted locally in relay_config.json inside the pack's folder, per-node, so re-opening a workflow doesn't wipe them. Don't commit that file anywhere public; it contains a live credential.

The inputs that actually matter

• task_type / platform / api_format / model - set them in order and the dropdowns keep you honest. The defaults (image / banana-pro / runninghub-/openapi/v2) are a reasonable place to start but you'll change them for every job.
• api_base - the relay's base URL, chosen from five built-ins (RunningHub and its LLM endpoint, yunwu, t8star, bltcy). Your key must belong to this relay; mixing them is the #1 cause of the "Expecting value" JSON errors the README warns about.
• apikey - the relay's key, not a Google or OpenAI key.
• custom_api_base / custom_model - type an address or model name to add it to the dropdowns; type delete:name to remove it.

The single output, info (STRING), feeds the info input on any generator node. That's the whole wiring: Settings → info → generator.

Installing the pack

cd ComfyUI/custom_nodes
git clone https://github.com/flywhale-666/ComfyUI-relayapi

…or search "ComfyUI-relayapi" in ComfyUI Manager, then restart. No pip dependencies beyond what ComfyUI bundles, no model downloads.

Gotchas

Two things bite beginners. First: the relay ecosystem is unregulated and reseller-specific - an api_format that works on RunningHub may not exist on yunwu, and the "current group upstream saturated" error is the relay telling you its backend is congested, not that you broke something. Second: the pack deliberately removed the "force re-run every time" behavior, so Settings only fires downstream when one of its inputs actually changes - that means a seed-fixed generator can hit ComfyUI's cache instead of burning another paid API call. That's a feature, though it surprises people who expect every queue click to re-bill. Read a fresh relay pack's source before trusting it with a key - this whole category holds credentials and phones home by design, and it's exactly the shape that's been abused once before.