LLM settings · central (one place for every call)

The problem this node exists to kill

A run makes up to three LLM calls - the song request, the Cover Studio plan, the rewrite of its score - and each chat node used to carry its own copy of the same ~28 settings. Changing your provider meant editing it three times, and two copies disagreeing failed in ways that were hard to spot in the log.

LLM settings · central holds them once and hands them out as one JSON string. Wire its single output into the llm_config_json input of every chat node and you edit the model in one place.

Where it sits in the wider picture

The toolkit runs its text layer inside ComfyUI - a GGUF on your own card, or LM Studio, Ollama, llama.cpp, vLLM or a cloud provider if you'd rather not spend the VRAM. That's the in-graph-GGUF side of a long-standing split with the external-Ollama-server pattern: one process instead of two, with a chat model and a song model sharing memory. And the job isn't chat - ~11.6k tokens of prompt in, four sections out - so small and obedient beats large and clever.

How the handoff actually works

The node derives its widget list from the chat node rather than copying it, so the two can never offer different models. It packs what you set into a tagged payload, and the receiving chat node merges it field by field: its own widget value first, then whatever the config carries on top. Anything the config omits keeps the local value, so an older graph keeps working. An unreadable payload - an empty socket, text from an older release - is ignored with a log line instead of stopping the run.

One surprise: ComfyUI checks widgets before executing, when a linked input doesn't exist yet, so the chat node treats a connection as the decision - a stale model name in its own dropdown no longer refuses the queue. Disconnect it and it validates its own value again.

The inputs that matter

model - the GGUF. The dropdown lists files already in ComfyUI/models/llm plus catalog entries you don't have yet, each with a size and a 1–5 star rating; the stored value stays the plain file name, so a saved workflow keeps loading after the download. Default: Qwen_Qwen3.5-9B-Q4_K_M.gguf (6.2 GiB).

n_ctx (37376) and max_tokens (24576) are a pair, not two knobs. The context holds prompt, answer and any thinking, so a response cap larger than n_ctx minus the prompt gets cut by the runtime, silently.

backend picks the mode - In ComfyUI (GGUF), Local app / server, Cloud service - and fields belonging to the other modes hide themselves. Cloud adds cloud_provider, server_url, remote_model, remote_max_tokens (4096) and request_timeout (120 s). Keys arrive through the node's own Set API key button: credential_id is a session reference only, and permanent_key decides whether the key is stored on this machine, bound to that exact API address. It never enters the workflow either way.

thinking defaults to off: reasoning is skipped where the backend supports it, and any <think> block is stripped off the answer, logged separately - the parsed sections only ever see clean text. Leave it off; a reasoner leaking scratch-work into a structured prompt wrecks the output.

Then n_gpu_layers (-1 offloads as much as possible), split_mode / tensor_split / main_gpu for multi-GPU, chat_format (auto picks a template per model family) and auto_download.

Output is a single STRING, llm_config_json.

Install

ComfyUI Manager (registry name comfyui-minimax-music-production-toolkit, searched as "Music Production Toolkit"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/jplenio/ComfyUI-MiniMax-Music-Production-Toolkit
cd ComfyUI-MiniMax-Music-Production-Toolkit
python -m pip install -r requirements.txt

Use the Python environment that runs ComfyUI, then restart. The GGUF path additionally needs python -m pip install llama-cpp-python - not in requirements.txt, because no single wheel fits every CUDA, ROCm and CPU setup; the server and cloud modes need none of it. A selected GGUF fetches itself into ComfyUI/models/llm while auto_download is on.

Where people get burned

Changing n_ctx or n_gpu_layers reloads the model. Both are part of its cache identity, so tweaking them mid-session costs a full reload.

Architecture support, not VRAM, is usually the blocker. The Qwen 3.5/3.8 GGUFs use Gated DeltaNet and need a recent llama-cpp-python; older builds refuse them. Llama-3.1 and Mistral-Nemo are plain llama and load anywhere; Gemma 4 needs gemma4, LFM2.5 needs lfm2/lfm2moe.

"External LLM model is missing" means the example filename isn't a bundled dependency. Put a GGUF in ComfyUI/models/llm or configure a URL in models_config.json - the model-check node only reports, it never starts these downloads.

An answer that stops mid-sentence is the max_tokens/n_ctx pair, not a crash. Raise both by the same amount.

The honest take

With a single chat node you'd never touch, this earns nothing - the connection is optional everywhere. It pays off when three calls share one provider, one key and one model, or when a cloud key should live in one place. Nothing glamorous; it just deletes a class of "why did two calls use different models?" bugs.