API Node for Stream Response LLMs

This is the node the pack actually wants you to use for LLM calls. It's the current-generation streaming chat node - "API Node for Stream Response LLMs" - and it's the one the README lists first under text generation. It does two things the older LLM nodes in the pack don't: it can see images, and it treats the system prompt as properly optional. If you're wiring an LLM into a workflow for prompt rewriting, captioning, or prompt extraction, this is your starting point.

How it works

It's a thin, honest wrapper around chat.completions.create() with stream=True, using the OpenAI SDK against whatever api_url/api_key you provide. The response chunks are accumulated into one LLM RESPONSE string - you don't get partial updates, you get the whole answer when the stream ends, which is the right behavior for a node graph.

The vision part is where it earns its keep. If you connect an images input, it:

• normalizes and downscales the tensors,
• encodes each to PNG base64,
• attaches them as image_url content items in the user message.

So a batch of images becomes a batch of inline images in one API call, all in a single IMAGE input. The tooltip suggests using an "Any Image Batch" node to feed multiple images - a reference to the batch-joining nodes other packs ship.

Two details that show this node was built against real providers:

• enable_thinking is a combo - true, false, or none. Only true/false append the enable_thinking field to the request body (a DashScope/Qwen-style extension for reasoning models); none means don't send it at all. So it's provider-safe by default.
• temperature of 0.0 isn't sent - anything above 0 goes through. Zero means "let the API use its default," not "be maximally deterministic."

The inputs and outputs that matter

• prompt - required, and it's a wired input (forceInput), so text has to come from another node rather than being typed.
• model - gpt-4o-mini by default; any model your endpoint serves.
• api_url / api_key - defaults point at https://api.tu-zi.com/v1, a third-party aggregator. Change these to your provider before anything else.
• temperature, seed - standard.
• enable_thinking - true/false/none.
• system_prompt (optional, wired) - only included if non-empty.
• images (optional IMAGE) - the vision input.

Single output: LLM RESPONSE (STRING). Wire it into a text display, the RegText cleanup node, or a CLIP encoder.

Installing it

One node in AhBumm/ComfyUI_BillBum_APIset_Nodes. ComfyUI Manager → search "billbum" → install "Customizable API Call Nodes by BillBum", or:

cd ComfyUI/custom_nodes
git clone https://github.com/AhBumm/ComfyUI_BillBum_APIset_Nodes.git
cd ComfyUI_BillBum_APIset_Nodes
pip install -r requirements.txt

Restart ComfyUI. Dependencies are just the API stack (openai, pillow, requests, tenacity, tiktoken).

Common issues

• The default endpoint is a placeholder. api.tu-zi.com is the author's own aggregator default; it's not the thing you should be pointing at unless you have an account. Swap api_url and api_key - most setup pain with this pack is just forgetting to do that.
• Vision needs a vision model. The images are sent as image_url content regardless of the model you pick; a text-only model will either ignore them or error. Pick a VLM if you're feeding images.
• Both prompt and images empty = an error, raised on purpose ("Prompt and images cannot both be empty"). Don't leave both dangling.
• The response is the full stream. For long reasoning-model answers that means a long wait and a big string. That's expected - ComfyUI has no concept of live-updating text.

Between this and the pack's Vision/LLM companions, this is the one to build on. It has the fewest surprises and the most useful feature (vision) of any LLM node here.