OpenAI API - Presence Penalty

If you've ever asked a chat model to "suggest ten ideas" and gotten ten variations of the same idea, you've met the exact problem OAIAPI_PresencePenalty fixes. It penalizes any token that has already appeared in the conversation, whether it showed up once or fifty times - a flat "you've been used, go somewhere else" penalty. Positive values make the model more likely to talk about new topics. That's the whole job, and for ideation-style prompts inside ComfyUI it's quietly one of the most useful option nodes in the pack.

How it works

Same plumbing as the other option nodes: it packs presence_penalty into an OAIAPI_OPTIONS payload, and the Chat Completion node passes it as the named API parameter. Range is −2.0 to 2.0 (step 0.1), default 0, so it's off until you touch it. The distinction from the frequency penalty node matters: presence is a flat "this token appeared, penalize it" regardless of count, while frequency scales with how often a token repeats. Presence gets you topical variety; frequency kills verbatim loops. Use them together if you want both - that's the classic combination for long creative generations.

The inputs and output

• presence_penalty - the only widget. 0.3–0.6 is a sensible place to start for "give me a list of varied options" prompts; above that the output gets noticeably scattered.
• other_options (optional) - merge point for chaining option nodes.
• Output: Options (OAIAPI_OPTIONS), feeding the next option node or Chat Completion's options input.

Installing it

Part of the comfyui-openai-api pack, so install is the pack install. ComfyUI Manager → search "OpenAI API" → install, or

cd ComfyUI/custom_nodes
git clone https://github.com/hekmon/comfyui-openai-api

restart, done. Only new pip dependency is openai; no model files involved.

Where people get burned

Negative values. The dial goes below zero, and a negative presence penalty does the opposite - it encourages the model to reuse words and topics it's already touched, which is rarely what you want and can produce very samey output. The other common stumble is expecting it to fix repetition (that's the frequency penalty's job) and being confused when a loop persists. And fair warning: on small local models the effect is weaker and less predictable than on the big cloud ones - Ollama's implementation treats it as a hint more than a rule. For prompt-expansion workflows that need diverse output without babysitting, presence penalty at ~0.4 plus a low-ish temperature is the combination to remember.