Bots load cookie banners too. We don't bill for them.

One site on Inth received about 197,000 suspected scraper sessions in a week. They came from 161 old Chrome versions, and each version had almost the same number of sessions. That even spread is why we think it was one scraper rotating its user agent.

None of those sessions answered the cookie banner. Vercel's firewall flagged 99.9% of them too.

That first detail is the test we use for every rule. Flagged sessions rarely record a consent choice.

The easy fix is to let a network firewall decide. Vercel's firewall has a managed bot filter, and we used its verdict in billing for a while.

It didn't fit how c15t runs. In Next.js, TanStack Start and Nuxt, c15t can fetch consent on the server and render the banner with the page. Customers can also proxy Inth through their own domain. Either way, the request that reaches us comes from the customer's server, not the visitor's browser.

For one site that sent visitor data from its own server, the firewall flagged every one of those requests and none of the site's other requests. It was judging the site's server, not its visitors.

It was also noisy on traffic that came straight from browsers. In a week of 2.05 million browser-direct sessions, sessions only the firewall flagged made a consent choice 7.0% of the time, close to the 9.8% of sessions nobody flagged. Those look like people. Sessions only our rules flagged did it 1.65% of the time.

Firewalls are built to block suspicious connections. Deciding what to bill is a different job.

We judge the visitor's browser, using the user agent the customer's server forwards to us. A session doesn't count when:

• The browser names itself as a bot. This covers search and AI crawlers such as Googlebot, GPTBot, ClaudeBot, ExaBot and meta-externalagent, plus monitors and link previews.
• The user agent has no operating system, or comes from a headless browser.
• The Chrome version is years out of date. Chrome updates itself, so very old versions are rare among real visitors. This is the rule that caught the 161-version scraper.
• The user agent doesn't match what standard Chrome sends. Chrome has shortened its version to the form 150.0.0.0 since 2022. Companies could switch that off through Chrome 144, so from Chrome 145 we treat a full build like Chrome/150.0.7871.46 as modified. WebView, in-app browsers and apps that name themselves in the user agent are exempt. That exact string showed up on 54 customer accounts in a week and never answered a banner. Chrome on an operating system it doesn't support, such as a recent Chrome on Windows 7, is caught the same way.

Every rule passes the same test before it ships. Flagged sessions recorded a consent choice about 0.5% of the time, against 7.2% for sessions we bill.

Most of what we filter isn't the polite crawlers. Last week, more than half the bot sessions we removed claimed to be an ordinary Chrome browser.

A bot with a current Chrome user agent and nothing else odd about it looks like a person to us, and we bill it. A firewall catches some of those.

The rules also catch some people, such as real visitors on very old machines. If every flagged session that answered the banner were a person, at most about 7% of flagged sessions would be people. Some bots click accept, so the real share is lower.

We'd still rather miss some bots than assume every request from a cloud server is one.

We read the public pricing pages, terms and help docs of every consent platform on CookieBench on 28 October 2026. Inth runs CookieBench. Here's what each says about bots and billing, quoted where they say anything. "Not stated" means we found nothing either way, not that bots count.

Cookiebot, which Usercentrics owns, bills its core plans by the number of pages on your site rather than traffic.

CookieYes filters "known" bots, and iubenda filters bots that name themselves. Neither publishes exactly how. We can't test their systems, but we can test the kind of list these filters are usually built on.

We ran the user agents from this post through isbot 5.2.2, a popular open-source bot detector. We also ran them through a filter that looks for "bot", "crawl" or "spider", the words iubenda says it checks. We left out the extra list iubenda says it also uses.

Both filters caught GPTBot. Neither caught one bot posing as Chrome. These strings have the same shape as the ones we saw, but they aren't the scraper's exact user agents.

So bots like the 161-version scraper probably get past filters built on lists like these and end up on the bill. We haven't tested any vendor's own system, and one with its own bot management, as OneTrust describes, may catch them.

Usercentrics is the clearest case. It bills sessions, the same unit we do, publishes its prices, and says bots count. Its pricing page says plans upgrade automatically when you go over, and its terms allow a move up after two months in a row over the limit.

If bots are 1 in 5 sessions, they add 25% on top of your real ones. Here's what that does on Usercentrics' published USD prices a month, before tax:

These are examples, picked to show both cases. If you sit just under a tier, bots push you over it. If you have room, as in the 60,000 row, they cost nothing until you grow. Your bot share won't be exactly ours, and only bots that run the consent script count toward Usercentrics' sessions.

If your consent platform bills by visits or sessions, ask: do bots count? Then ask how it spots a bot that claims to be Chrome.

Bots load your banner. They shouldn't be on your bill.