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”, it knows “Chris” on its own is not “Chrissie”, and it knows “Christine” is Chrissie written out in full.

A name on your list is a person, not a spelling. Filter “Joseph Finney” and “Joe Finney”, “Joey Finney” and “J- OH, seffinny” are all caught: inside a full name a well-known nickname counts for that word in either direction (Joe and Joseph, Matt and Matthew, Chris and Chrissie), and the chunks a donor types don’t have to line up with the words - “J- OH sef” plus “finny” is read as one run and comes out as Joseph Finney. A single-word entry is stricter on purpose: “Chrissie” does not catch “Chris”, because you filtered the longer name and the shorter one is a different, common name.

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.

Every match then gets a second look. Where the sound comparison can vouch for it outright (the donor’s chunks, read together with the chunks either side of them, have the entry’s exact sound) it stands as it is, widened to cover the whole disguised run so no half of the name is left on stream. Where it can’t, the match is put to the model again as a single question - “does this span really say this entry?” - with the sound evidence written out, and a no drops it. It works the other way too: if the sound comparison found an entry whole in the text (the letters split into chunks, a near spelling, the identical sound, or every word of a name) and the model claimed nothing for it, the same single question is asked and a yes adds the match. So a name the model happens to miss on one run is still caught by the arithmetic that doesn’t vary between runs.

Which AI is used

The model runs on third-party inference providers that TipPage only uses under zero-data-retention terms: your donors’ text and your filter list are processed to produce the verdict and are not stored by the provider afterwards or used to train anything. Every request is technically restricted to providers that meet that standard, so it cannot be routed to one that keeps or trains on content. Which provider handles a given message depends on price and availability; the providers are listed in the Privacy Policy. We deliberately don’t publish which model is 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.

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.