Nodes/ComfyUI OpenAI API/OpenAI API - Max Completion Tokens
ComfyUI Node

OpenAI API - Max Completion Tokens

The one-number fix when your model rejects max_tokens

By hekmon·Created 2 years ago·Updated 4 days ago· 51
OpenAI API - Max Completion Tokens
  • other_options
  • Options
◄max_completion_tokens512►

This node does exactly one thing: it carries a number into a chat completion request under the key max_completion_tokens instead of max_tokens. That's it. No model, no API call, no output text. It's plumbing - and it's the plumbing you need the day your favorite workflow dies with an HTTP 400 telling you max_tokens isn't supported.

Why the distinction exists at all

If you wire an LLM into ComfyUI to rewrite a rough idea into a structured prompt, or a vision model to caption an image before img2img, you're leaning on an API or local-server call rather than a sampler (llm-in-comfyui.md). The cheap offline option is an 8B abliterated model on your own card; the expensive one is a frontier model over the wire. Both speak the same chat-completions dialect, which is why one small pack serves both.

That dialect drifted. Older servers - Ollama, plenty of vLLM builds, anything written against the 2023 API - understand max_tokens and nothing else. Then OpenAI's reasoning-era chat models stopped accepting max_tokens and began rejecting the request outright, demanding max_completion_tokens instead. Same concept (an upper bound on generated tokens), new field name. You can only use the one your server knows about.

Hence two nodes instead of a dropdown: the author mirrors the API rather than hiding it. You pick based on what you're talking to.

How it works

The options nodes in this pack are a little chain of dict builders. This one takes its max_completion_tokens integer, copies whatever payload arrived on its optional other_options input, stamps max_completion_tokens on top of the copy, and hands the merged dict out as an Options value. Chain five of them and you get one dict with five keys.

The OpenAI API - Chat Completion node then unpacks that dict: known keys (seed, temperature, max_tokens, max_completion_tokens, top_p, frequency_penalty, presence_penalty, use_developer_role) get promoted into typed arguments, and anything left over is forwarded as extra_body. The source is blunt about conflicts - both token limits set means ValueError: max_tokens and max_completion_tokens cannot both be set, thrown before anything hits the network.

The inputs that matter

Max Completion Tokens is the only real input. Default 512, minimum 1, maximum one million - that ceiling looks silly until you read the comment in the source: ComfyUI clamps an unset INT max to 2048 and the author wanted room for long outputs. This widget also has no control_after_generate dropdown, unlike a seed, so it won't quietly randomize out from under you.

Options (the optional input, displayed as just "Options") is where you daisy-chain other option nodes. When two nodes in the chain set the same key, the one closer to the Chat Completion node wins, because the copy-then-overwrite happens in order.

Options is also the single output, type OAIAPI_OPTIONS, and it wires into the options input of OpenAI API - Chat Completion - directly, or through your Temperature/Top P/Extra Body nodes on the way.

Installing it

No models, no downloads. In ComfyUI Manager search for OpenAI API and install it (the registry publisher is hekmon), or:

cd ComfyUI/custom_nodes
git clone https://github.com/hekmon/comfyui-openai-api
pip install -r comfyui-openai-api/requirements.txt

Then restart ComfyUI. The only real dependency is the openai Python package; numpy and Pillow are already ComfyUI's own.

Set your key as an environment variable before launching, never in a widget:

export OPENAI_API_KEY=sk-...    # Linux/macOS; setx on Windows, -e in Docker

The client reads it at execution time, and if it's absent it falls back to a - placeholder so keyless servers (vLLM, some Ollama setups) just work. Since this is a node that carries a credential and phones home by design, give it the suspicion you'd give any API pack - this ecosystem has already had a fake "LLM vision" node ship an infostealer (external-api-nodes.md, llmvision-incident.json).

Where people get burned

You left both token nodes in the graph. Nothing on the canvas stops you - the error only fires at run time. Bypass the other one with Ctrl+B rather than deleting it, so the wiring survives.

Empty or truncated answers on reasoning models. Reasoning tokens are counted inside max_completion_tokens, and 512 is not much once a model is thinking out loud. If the response comes back blank, check the node's usage preview - the pack prints a reasoning: count there - and raise the number instead of assuming the node is broken.

An old server that doesn't know the new field. Point this at a stale Ollama build and the unsupported-parameter error comes back the other way round. That's what OpenAI API - Max Tokens is for: swap the node, keep the chain.

It didn't re-run. Chat Completion caches its result; tick Force Regen on the chat node when the graph looks stale. And if you share images, launch with --disable-metadata - ComfyUI embeds widget values into PNG metadata, which is exactly why this pack refuses to take your key as an input.

CategoryOpenAI API/Options

Inputs (2)

NameTypeDefaultDescription
max_completion_tokensINT5121–1000000An upper bound for the number of tokens that can be generated for a response. Use this instead of Max Tokens on models that reject max_tokens.
other_optionsoptOAIAPI_OPTIONSOthers options to merge with

Outputs (1)

NameTypeDescription
OptionsOAIAPI_OPTIONSMerged options to forward