llama.cpp Token Ban

A token ban is the blunt instrument of LLM control: a list of strings the model is told it can't output, applied as logit bias at sampling time. Where a prompt says "please don't," a token ban makes the offending token a very unattractive choice. It's how you stop a model from writing "Here is your enhanced prompt:" as a preamble, how you keep a captioner from producing markdown headers, how you prevent a word from ever appearing - even when the model's chat habits are screaming for it.

This node builds that ban list. Type your banned strings, and it produces a logit_bias output that plugs into an ADV++ Prompt node's token_ban input.

How it works

You give it text; it builds llama.cpp text-form logit-bias entries. Text-form matters: instead of you hunting down token IDs in the vocab, the server resolves your strings to the tokens that spell them and biases those. The node accepts three list formats:

• one entry per line - the simple case.
• a JSON string array - use this when an entry contains commas or meaningful surrounding whitespace, because those would otherwise be parsed wrong.
• the legacy comma-separated form - kept for compatibility with old workflows.

The robust list handling mirrors the pack's stop-sequence semantics, which is nice: one parsing rule across the suite.

Inputs

• banned_tokens - the strings to ban, in any of the three formats above.
• enable - switch the whole ban list on or off without deleting it. Leave it wired and flip this while debugging whether the bans are actually what's changing the output.

Output: logit_bias, into ADV++'s token_ban.

When to reach for it

The KB's LLM-in-ComfyUI essay describes the canonical fix for dirty, non-structured LLM output as "hard token-ID stopping - the model is physically prevented from writing role delimiters like 'assistant' into your output." That's exactly this. Common real uses:

• ban assistant, system, user role markers from a prompt-rewriter so chat scaffolding can't leak into your conditioning;
• ban markdown fence markers or ** when the downstream wants plain text;
• ban a word you never want in captions.

One honest caveat: bans are per-token, so banning "no" also bans it inside "noteworthy" - it's not word-boundary-aware, and over-broad bans can make the model's output noticeably stilted. Ban the minimal set and prefer Structured Output for shape-level control; token bans are for the specific tokens you never want, and the two stack well in ADV++.