Nodes/ComfyUI-YogurtNodes/Provider: Magnific
ComfyUI Node

Provider: Magnific

One Key, Two Upscale Nodes, a Long Wait

By yogurt7771·Created 2 years ago·Updated 6 days ago· 3
Provider: Magnific
    • provider
    ◄api_key►
    ◄base_url►
    ◄task_timeout900►
    ◄proxy_url►
    ◄timeout0►

    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 magnific in api_key.json, then MAGNIFIC_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, 0 means 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.

    CategoryYogurtNodes/LLM/Providers

    Inputs (5)

    NameTypeDefaultDescription
    api_keySTRINGLeave empty to use 'magnific' from api_key.json, then the MAGNIFIC_API_KEY environment variable.
    base_urlSTRINGAPI base URL; leave empty for the default endpoint.
    task_timeoutINT90030–7200Maximum time to wait for the upscale task.
    proxy_urlSTRINGProxy URL, e.g. http://127.0.0.1:7890 or socks5://127.0.0.1:1080.
    timeoutINT00–3600Request timeout in seconds; 0 means no limit.

    Outputs (1)

    NameTypeDescription
    providerYOGURT_LLM_PROVIDER—