Unsloth Connectivity

Here's the thing that trips people up first: Unsloth Connectivity generates nothing. It writes no text, sees no image, and doesn't touch an API on its own. It's a config node - a bundle of "where's the server, what's the key, which model, how long do we keep it warm" that gets handed to Unsloth Generate through its single connection output. Ignore it and the Generate node refuses to run.

So what's it for? You've got a local LLM you want inside the graph rather than in a side chat window: rewriting a rough idea into a structured prompt, captioning an image for a LoRA dataset, or seeding an img2img prompt from a reference. That whole category of tool node comes down to one question - does it run one process or two? - and this pack is firmly the two-process kind. Unsloth Desktop (free, open source, Mac/Windows/Linux, beta) is a separate app that runs and trains models on your own hardware, serving what it loads through llama-server on an OpenAI-compatible endpoint, with keys that look like sk-unsloth-…. This node is ComfyUI's side of that handshake.

If you've used the Ollama nodes, the shape will be familiar - Connectivity, Options, Generate - and that's deliberate. The keep-alive semantics are borrowed from Ollama too, because Unsloth doesn't have any.

The inputs you actually set

Four of the five fields matter, and one of them will waste your afternoon if you skip it.

url defaults to http://127.0.0.1:8888, which is the tooltip's "local instance on its default port." Treat that as a hint, not a promise - Unsloth's own docs say the server typically boots on 8000 or 8888. Use whatever the app printed to its console when the model loaded.

api_key is required, full stop. Unsloth → your avatar → Settings → API → create a key. The OpenAI API rejects requests without it, and Unsloth only shows the value once, so paste it somewhere sane before you close that dialog.

model is an enum that starts empty - there's nothing to pick until you hit the 🔄 Reconnect button under the node. That button asks Unsloth for the models downloaded on disk (incomplete downloads filtered out), falling back to the loaded-models list if that call fails. So you'll only ever see GGUFs you've actually got, not the catalog Unsloth could download. It also fires automatically when you edit url or api_key, so you rarely press it twice.

keep_alive plus keep_alive_unit (minutes or hours, default 5 minutes) is where this node earns its keep. Unsloth has no per-request keep-alive parameter, so the pack emulates Ollama's behaviour client-side: a background heartbeat pings the active model with a one-token request every 30 seconds to stop the server idling it out, and when the grace period expires it calls Unsloth's unload endpoint. -1 keeps the model resident indefinitely, 0 unloads it the moment the response lands, and any N unloads N minutes/hours after your last generation. The heartbeat is keyed per server URL and follows whichever model you generated with last - which is fine, because Unsloth only has one model active at a time anyway.

Install

No dependencies to fight with, which is rare and nice. ComfyUI Manager → Install Custom Nodes → search Unsloth Desktop Nodes (registry id dever/dever-unsloth) → Install → restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/DeverStyle/comfyui-dever-unsloth.git

Then restart ComfyUI. The pack's requirements.txt is literally the sentence "No new dependencies" - it uses requests, PIL and numpy, all already in your ComfyUI environment.

You also need Unsloth Desktop itself, running, with Settings → "Model auto-switch (OpenAI API)" enabled. With that on, a chat request can name any downloaded GGUF and Unsloth loads it in-request. Without it, asking for a model that isn't currently loaded returns a 400 and the node tells you exactly that.

Common issues

Empty dropdown. Server not running, wrong port, or a key Unsloth has forgotten about. Check the port first.

401. Key missing or wrong - recreate it in Settings → API.

400 about the model. Auto-switch is off, or the GGUF in the widget isn't downloaded on this machine. That second case shows up a lot when you open someone else's shared workflow: the model name is saved in the workflow JSON like any widget value, and nothing re-resolves it for you.

A generation that hangs around five minutes and dies. The client gives up after 300 seconds, and a big model cold-loading counts toward that. Either let the model load once in the Unsloth UI, or lean on keep-alive so you don't pay for it every run.

One honest note on keep-alive: -1 is great for iterating and terrible for sharing a GPU with a diffusion model. Five to ten minutes is the sane middle - long enough for a run of prompt experiments, short enough that Unsloth lets go when you go back to Flux.