Logit bias is the one vocabulary-level control an API hands you. It acts on tokens. Every rule you actually want to enforce is about strings, and those are not the same object.
Run it: https://dev48.infy.uk/prompt/day77-logit-bias.html
Nothing here simulates language
There is no model and nothing is sampled. The vocabulary is trained by a real BPE merge loop over a corpus that is data; the tokenizer is real string code; a ban is a real set of token ids; and whether a word survives a ban is decided by walking its segmentation graph. So every rate is a count over an enumerated corpus, and a 0.00% here is a zero, not "none seen".
One theorem, checked rather than assumed
An airtight token ban must contain a single-character token.
Because a byte-level vocabulary always leaves the character-by-character spelling available. Checked: 62 of 62 airtight bans across 80 word × strategy cells, 0 violations.
Necessary, and not sufficient — 5 of the 80 cells ban a character and leak anyway.
The centrepiece needs no dial at all
Take the ban every provider's documentation shows — run the word through encode(), set -100 on what comes back:
| words it leaves writable | 81.25% of sixteen |
| the three it does stop | stopped by accident |
The three it stops are exactly the words the tokenizer had already shattered into characters. And stopping them cost 30.33 ordinary words of collateral damage each, out of a 381-word lexicon, against 5.08 for the thirteen it failed on — 5.97× the damage on the cases where it worked.
The intended headline died under measurement
I built this expecting the documented ban to leak on everything. It does not; it leaks on 81.25%, and the exceptions have a reason. The page says so where the finding would have gone, because a result that came out weaker than the pitch is still the result.
Verifier 141,169 asserts, page self-check 130,278, 0 failures.
Top comments (0)