AI filter

A bypass-aware filter that catches what a wordlist can't - built to stop doxxing on stream.

The AI filter is the word filter’s big sibling, built specifically to stop streamers getting doxxed on their own stream. It’s a TipPage+ feature.

What it catches

Ban “Alex Adams” once, and the AI catches “Alicks Aderms”, “Eye Licks Add Dams”, and every phonetic bypass in between - plus the leetspeak, unicode lookalikes, split words, and creative spacing that a wordlist can’t see. It reads your filter list the way a person would: it sounds things out, it knows “Kris” is “Chris”, and it knows “Chris” on its own is not “Chrissie”.

It runs alongside your normal word list, not instead of it - regex catches the cheap stuff, the AI catches the clever stuff.

Turning it on

Filter page, Filter settings panel, flip the AI filter toggle. Without TipPage+ you’ll see an Unlock with TipPage+ button there instead.

Seeing why something was caught

• The Test the filter panel shows the AI’s reasoning for anything it flags.
• If you’ve set up a Discord webhook, blocked-message notifications include the AI reasoning too - so you can sanity-check its calls from Discord.

How it works

For the technically curious, and for anyone who wants to know exactly what leaves TipPage when the filter runs.

When it runs

Every tip is checked by your word list first. With the AI filter on, the name and message are also sent for an AI check whenever your filter list has at least one entry. Twitch alerts (follows, subs, resubs, cheers, raids) go through the same check on the viewer’s display name and the alert text, once per event - the overlay alert and the chat announcement share that one verdict.

What the model is given

One request per tip, containing:

• The donor name and message, exactly as typed.
• Your filter list - every entry, its action (replace or block), and any note you’ve written on it. The model needs the whole list to spot a name split across the message, and your notes (“people spell this as kriz”) are used as extra spellings to look for.
• A sound-alike pre-screen. Before the call, TipPage compares your entries against the donor’s words by sound (Double Metaphone codes plus edit distance) and writes the result out for the model: for each entry, the exact donor words that sound like it, and for a multi-word entry which of its words could and could not be found. This points the model at the likely bypass instead of asking it to notice one unaided, and it makes the model’s answer more consistent from one message to the next.
• The donor’s filter history - only counts, never content: how many tips this person has sent across TipPage, and how many were filtered or blocked, including in the last 24 hours. First-time donors and recent repeat offenders get a harder look. This is the one signal that crosses streamers, and it is a number, not a name.

The model is not given the donor’s email, payment details, IP address, Twitch account, device identifier, or anything about you beyond the filter list itself. Because the filter list is what you are protecting - often your own name or address - treat it as the sensitive part of this exchange: it is sent to the model provider on every AI check.

What comes back

A structured verdict: which filter entries matched, the exact donor text that matched each one, the cleaned name and message with replacements applied, whether anything on your block list was hit, and a one-line reasoning you can read in the test panel and Discord notifications.

TipPage does not take the model’s word for everything. A block is only honoured if the entry it names is actually set to block on your list - the model cannot decide to reject a tip on its own. If the model fails, times out, or returns something unreadable, the tip falls back to your standard word-list filter rather than going through unchecked.

Which AI is used

TipPage uses a variety of AI model providers, and which one handles a given message depends on cost, current usage, how much reasoning the input calls for, and how complex the text is. We deliberately don’t publish which providers or models are in use at any given time: the filter’s job is to beat people who are actively trying to get around it, and knowing the exact model behind it makes that easier. The providers we may use are listed in the Privacy Policy.

Caching

Verdicts are cached briefly, keyed by a hash of the donor text and your filter list. Identical text against an identical list within the cache window gets the same answer without another model call. Editing an entry or its note changes the hash, so a fresh verdict is taken. Cached verdicts never include the donor’s identity.