Provider: Magnific
One Key, Two Upscale Nodes, a Long Wait
- provider
Magnific's API is a task API, and this node is where that fact becomes your problem. Submit an image, get a job ID, poll until the result lands. The provider node is the thing that holds the key and - more importantly - decides how long the pack will sit and wait for that job before giving up.
Wire it into Magnific Creative Upscale or Magnific Precision Upscale. Both default to this provider when nothing is connected; connecting it is how you make the configuration visible, add a proxy, or raise the wait ceiling.
The fields
- api_key - blank falls back to
magnificinapi_key.json, thenMAGNIFIC_API_KEY. The failure message names both places. - base_url - empty uses the default endpoint; set it if Magnific hands you something regional or you're going through a gateway.
- task_timeout - default 900 seconds, range 30–7200. This is the one that matters. It's the ceiling on the whole upscale job, not on a single HTTP request.
- proxy_url -
http://127.0.0.1:7890,socks5://127.0.0.1:1080, etc. - timeout - per-request network timeout,
0means no limit.
Output: one provider socket.
The two-timeout distinction, again
People conflate these constantly, so: timeout is "how long before a single HTTP call is considered dead," task_timeout is "how long am I willing to wait for an upscale job to complete." A 16x creative upscale of a large source with high creativity can genuinely run for minutes, and at busy times the queue adds more. If jobs are dying with a wait-shaped error, raise task_timeout - putting timeout to 0 does nothing for a job that's still legitimately running.
The ceiling is generous for a reason. Magnific is one of the few paid services the upscaling community still names in the same breath as the good open models - SUPIR was marketed as the free answer to it, and Comfy Org's own 2026 upscaling handbook recommended it by name. It's also the service whose whole pitch is invented detail, which is the expensive part.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/yogurt7771/ComfyUI-YogurtNodes
cd ComfyUI-YogurtNodes
pip install -r requirements.txt
ComfyUI Manager: search "YogurtNodes" and restart. On the canvas, node names carry a " (Yogurt Nodes)" suffix, so this one shows as "Provider: Magnific (Yogurt Nodes)".
Key file, custom_nodes/ComfyUI-YogurtNodes/yogurt_nodes/llm/api_key.json:
{ "magnific": "your-api-key", "magnific_base_url": "https://api.magnific.com" }
Keep the file out of workflow shares - keys typed into node widgets get saved into the workflow JSON and travel with it.
Is this worth wiring at all?
Honest answer: for a single-key setup, no. Leave the provider socket empty and the two upscale nodes will use Magnific with the same key from the same file. Connect this node when you need one of three things - a proxy, a longer task_timeout, or a visible record in the graph of where your images are being sent. That last one is not decorative. This node is the place where "my images leave the machine and go to a paid service" becomes a box you can point at.
For the money question, compare before you commit: the local upscaling ladder got genuinely good, and paying per image to enlarge an AI render you could ESRGAN locally in two seconds is a waste (the KB's upscaling.md has the whole picture, including where local still can't compete - heavily degraded sources and photos with real grain). The context to keep in your head: the community's paid-vs-free argument in this space is loud and old, and Magnific is the brand that argument was fought over - SUPIR and clarity-upscaler both launched as the free answer to it.
Bruises
Auth errors after a card change. Magnific returns service-shaped errors for a dead key; if a run that worked yesterday fails today, check the key before you check the workflow.
max_wait/task_timeout confusion with the other relay providers. GRSAI has max_wait_seconds; Topaz's provider has its own task_timeout; this one is task_timeout too but with a different ceiling range. They're not interchangeable, and if you're moving between relays, read the fields instead of assuming.
Setting a short timeout "to fail fast." You'll fail, sure - mid-job, with a possibly-billed run behind you. Long waits are the nature of paid upscaling.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| api_key | STRING | Leave empty to use 'magnific' from api_key.json, then the MAGNIFIC_API_KEY environment variable. | |
| base_url | STRING | API base URL; leave empty for the default endpoint. | |
| task_timeout | INT | 90030–7200 | Maximum time to wait for the upscale task. |
| proxy_url | STRING | Proxy URL, e.g. http://127.0.0.1:7890 or socks5://127.0.0.1:1080. | |
| timeout | INT | 00–3600 | Request timeout in seconds; 0 means no limit. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| provider | YOGURT_LLM_PROVIDER | — |