iz chat cfg

iz chat cfg looks like filler - nine widgets and one output - and it is actually the half of the pack that does the loading. iz chat cannot say a word until a CLIP object has been handed to it, and this is the only node that hands it over. Its single output, cfg, is what you wire into the chat node's cfg input. Forget it and the chat's send button politely tells you the model isn't loaded.

What it's really doing

get_cfg() calls the pack's api module and stores the actual CLIP object in a module-level global, then returns the eight settings as an ordinary dict tagged IZ_CHAT_CFG. So the wire between the two nodes isn't carrying a model at all - it carries a dict, and the model travels by side effect through Python globals.

That has consequences you'll feel. The model only exists once the workflow has run, it's gone after a ComfyUI restart, and if you drop two iz chat cfg nodes into one workflow the last one to execute wins for everything downstream. Swapping encoders means re-running the graph, not just rewiring it.

The frontend is also reading four of these widgets directly, live, when you press send: max_length, max_image_mp, seed and token_limit are sent with the request or used to draw the token bar. The sampling parameters - temperature, top_k, top_p, repetition_penalty - are only cached server-side on workflow run. In practice: change temperature and you must re-run the workflow before the chat notices; change max_length and the next message already uses it.

The inputs a beginner actually touches

clip is the point of the node: a text-generation-capable encoder from CLIPLoader. The pack's own simple workflow loads a 4B abliterated Qwen3-VL int8 file with the loader type set to krea2 - copy that pairing if you're guessing. That same Qwen3-VL family is the community's default local captioner and an increasingly common image-model encoder, so if you already run Krea 2 you probably have the file already, as its text encoder.

max_length (512) is the cap that matters - maximum tokens generated per reply. A chat answer wants maybe 512; reading an image and writing a detailed caption wants 1024+. It's the one people under-set and then blame the model for truncating.

temperature (0.7) with top_p (0.95) and top_k (64) are the usual sampling trio, and the defaults are sane for conversation. Drop temperature to ~0.3–0.5 when you're using this as a prompt rewriter and want obedient, repeatable wording instead of creative drift.

repetition_penalty (1.05) is your escape hatch when the model starts looping. Nudge it to 1.1–1.2. Much above that and it starts avoiding words it should be using.

max_image_mp (1.0) is a downscale ceiling: any image larger than this gets resized before it reaches the vision tower. One megapixel is plenty for "what's in this picture"; raise it toward 2 if you need the model to read small text or fine detail, and accept the extra time and VRAM.

token_limit (4096) is the one to not think about. Its own tooltip says "statistical only, does not block anything" - it's the denominator on the chat UI's token bar, so it's about watching your context, not limiting it.

seed (777) does what seeds do. The chat's ⟳ regenerate button can roll a fresh random seed when you want a different answer to the same question, which is the whole reason it's here.

Output and install

cfg goes into iz chat's cfg input. Nothing else in the ecosystem consumes IZ_CHAT_CFG.

cd ComfyUI/custom_nodes
git clone https://github.com/IZmake/iz_chat.git

Then restart ComfyUI. requirements.txt is empty and pyproject.toml lists no dependencies, so there's no pip step and no install script. The only download you need is the model file itself - the encoder goes in ComfyUI/models/text_encoders, and on a restart the workflow has to be run once more before the chat will talk.

Traps

The big one is the global cache combined with ComfyUI's queue. Two workflows open, or one workflow with two cfg nodes, and the CLIP that ends up in memory is whichever ran last - including across browser tabs, because the cache lives in the server process, not the graph. If your chat starts answering in the wrong model's style, re-run the workflow containing the cfg node you actually want.

The second is VRAM. Nothing here unloads or rotates the encoder the way dedicated prompt-enhancer nodes do, so a big vision model stays referenced alongside your diffusion model. If sampling gets slow after a long chat session, that's why: restart, or drop to a 4B.