Sloyd: Text to Image

Let's be straight about what this node is for. If you want a beautiful Flux or SDXL image, you already have thirty nodes that do that better, locally, for free. Sloyd: Text to Image is the odd node out in a 3D pack - it exists so you can generate references for the 3D nodes, or quickly draft an asset-style image, without leaving the graph. It's the "get me a front view of a chair" button.

What it does

POSTs your prompt to Sloyd's text-to-image endpoint, polls the job every two seconds, and downloads the result to ComfyUI/output/sloyd/. The IMAGE it hands you is a normal ComfyUI image - same tensor type everything else uses - so it feeds Save Image, Preview Image, an upscaler, or a 3D node downstream.

That last option is the interesting one. Sloyd's own example workflows lean on this pattern: generate a reference in the pack, then push it through Image to 3D or use it as a sketch source. One account, one credential, one output folder.

Inputs

• prompt - up to 4096 characters, defaulting to "a cute robot mascot, flat vector art". That default is telling: the endpoint is tuned toward assets, icons, props, and concept art rather than photorealism. Prompts naming the deliverable ("flat vector art", "product photo, white background", "game icon") land better than prompts naming a mood.
• seed - and you should read the tooltip once, because it's counterintuitive. Sloyd has no seed parameter, so this does not make results reproducible. It exists purely to bust ComfyUI's result cache. Leave it at 0 and re-running an unchanged graph costs nothing; change it and you buy a fresh generation. The widget also defaults to fixed rather than randomize deliberately, so a queued workflow doesn't silently re-bill itself on every run.
• timeout_seconds - 900 by default, 60–3600. The poll checks for interruption, so Cancel stops the node instead of freezing your queue.

Outputs

• image - an IMAGE. Wire it into anything.
• sloyd_job - the typed handle carrying the job id and the credentials that made it. Chained Sloyd nodes (like Retexture, if you're building a pipeline) accept it directly.
• image_path - the file relative to ComfyUI/output, e.g. sloyd/<job_id>.png. This is what you'd hand to an external script.
• job_id - the raw Sloyd identifier.

Install

ComfyUI Manager → search Sloyd, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Sloydai/comfyui-sloyd
pip install -r comfyui-sloyd/requirements.txt

Restart. requests is the only dependency listed, and there are no model downloads at all - nothing runs locally. Then Settings → Sloyd: paste a Client ID and a Client Secret from the Sloyd dashboard. It's a pair of values, not one key, the secret is displayed once, and you need billing set up first (prepaid, minimum $12). Docker or headless? SLOYD_CLIENT_ID / SLOYD_CLIENT_SECRET environment variables do the same job without touching the settings route.

The cost conversation

Every run costs credits, charged when the job starts and refunded automatically if it fails. That's the trade against local generation, where the marginal image is free. The reason the caching behaviour matters so much here is exactly this: an API node that re-bills on every queue is annoying, and the fixed default is the author making that call for you. Your mental model should be "changing a widget re-runs the node; changing nothing doesn't".

A 402 tells you the exact shortfall and starts nothing. A 429 means five jobs are already running on that key - the node retries with backoff (5s, 10s, 20s… up to ten minutes) rather than failing your run, so a big batch just takes a while.

And the standing caveat for every API-wrapper node in ComfyUI: your prompt and any image you send leaves your machine and is processed under Sloyd's terms. That's a category tradeoff, not a bug, but it's the one people forget when they wire a cloud node into an otherwise local graph.