💬 LM Studio Chat

The name is a small lie, but a harmless one. 💬 LM Studio Chat doesn't run a language model inside ComfyUI - it's an OpenAI-compatible client that talks to LM Studio, the desktop LLM app you already have running. Give it a model, type a prompt, and the assistant's reply comes back as a string you can wire anywhere. No API key. No cloud. Nothing leaves your machine.

That makes it the LM Studio flavor of a very standard trick. The whole "LLM inside the graph" genre - prompt enhancers that rewrite your rough idea before it hits the text encoder, captioners that describe an image for LoRA training - splits into two camps: nodes that load a GGUF directly, and nodes that talk to an external server like Ollama or LM Studio. This pack is firmly the second camp, and honestly the community's been running that pattern for a while: LM Studio serving a local model on port 1234, a ComfyUI text-gen node hitting it. This node is that, packaged.

How it works

At its core it's a POST to http://127.0.0.1:1234/v1/chat/completions - the OpenAI-compatible endpoint LM Studio's local server exposes. The node builds a messages array (optional system prompt, then your user prompt), sends it with streaming off, and hands back the assistant's text. That's the whole mechanism, which is why the setup is so light: no requirements.txt, no model downloads, just a running LM Studio server and the pack.

The two outputs are where beginners should look. response (STRING) is the model's text - feed it into a ShowText node to read it, or pipe it straight into a CLIP Text Encode as your polished prompt. raw_json (JSON) is the full API response formatted as JSON, handy when you want to log the exchange or pull out metadata.

Inputs that matter: model comes from the Ⓜ️ LM Studio Loader - that's how the chat knows which model to hit. prompt is your actual question or rough idea. system_prompt sets the model's instructions ("you are a prompt engineer for Flux, output 150 words, no preamble"). params is where the ⚙️ Model Params node plugs in temperature and friends - optional, the chat has sane defaults without it. One worth knowing about: unload_after_chat defaults to true, and it does what it says - after the reply it asks LM Studio to unload the model so your VRAM is free for the diffusion pass. That's the automatic unload/reload behavior the good local-LLM nodes converged on. Flip it off (or set keep_in_memory in the loader) if you're chaining several calls and want the model resident.

Install

ComfyUI Manager, search "comfyui-lmstudio-simple", or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/huagusam/comfyui-lmstudio-simple

Restart ComfyUI. No extra dependencies - the pack uses the Python stdlib plus PIL/numpy, both of which ship with ComfyUI. The real prerequisite is LM Studio itself: grab a GGUF model in the app (Q5/Q8 if it fits; the lower quants are for when it doesn't), then start the local server. It's 127.0.0.1:1234 by default, overridable with the LM_STUDIO_URL env var.

Where people get burned

The big one: the server isn't running. If the node returns the literal text "Error: Server not running", LM Studio's server is down - open LM Studio, find the Server/Developer settings, and start it. Related miss: some versions need CORS enabled for external clients to reach the server, so tick that too. Second: the first call after a reboot is slow. LM Studio loads a model on demand, so the first chat hangs while it pulls the GGUF into VRAM; subsequent calls are snappy. And if your loader's dropdown shows "Type model ID manually", the pack couldn't find the lms CLI - that one's covered in the Loader article.

This is a single-commit personal project (v1.0.0), so treat it as a handy utility, not infrastructure - and remember it's arbitrary Python with full OS access, like every custom node. Read the source once before you trust it with anything sensitive.