How Subscriber Limits Work

Benecaster counts your subscribers in two separate ways, and each has its own limit and enforcement behavior. Understanding the distinction — especially what gets counted and what doesn’t — makes it easy to predict how your account will behave as you grow.

Two Separate Limits

Paying subscriber limit — counts only subscribers actively enrolled in a paid membership tier. Free-tier subscribers, followers, and anonymous public feed listeners are excluded. This is the number you’ll focus on day-to-day as your podcast grows.

Total token cap — counts every active feed token, regardless of tier:

• A paying subscriber has a token.
• A free-tier subscriber has a token.
• A follower — an email-only signup through the follower form — has one too, and counts exactly the same.

Only public feed listeners hold no token at all. See What is a follower versus a free member? for the difference between the two free routes.

Both limits are based on your current active count, not a historical high watermark. A subscriber who cancels stops counting immediately.

What the Token Cap Actually Counts

The token cap often causes confusion because “free” means different things in different contexts.

The token cap counts subscribers who have signed up through your membership plugin, whether on a paid tier or a free-access tier. These listeners have a Benecaster feed token — a unique URL that their podcast app uses to receive your episodes.

The token cap does not count anyone listening to your public feed. Your public feed requires no token, no account, and no limit. If 10,000 people subscribe to your public podcast in Apple Podcasts, none of them generate a token or count toward any Benecaster limit.

A concrete example: if you have 40 paying subscribers, 15 free members on a $0 membership tier and 5 followers from the signup form, your paying subscriber count is 40 and your total token count is 60. The cap counts all three groups; the paying subscriber limit counts only the first.

Why Tokens — The Value of This Approach

A feed token is a private URL that belongs to one subscriber. When their podcast app polls for new episodes, it sends that URL to your site. Benecaster validates the token in milliseconds and returns the correct feed for their tier — no login, no password, no app update required when their tier changes.

This design has real advantages for your subscribers and for you:

Podcast apps just work. There is no “log in to your podcast app” flow. Subscribers add their private URL the same way they’d add any podcast feed. It works in Apple Podcasts, Overcast, Pocket Casts, and every other standards-compliant app.

Tier changes are invisible. If a subscriber upgrades from Silver to Gold, their URL stays the same. On their podcast app’s next refresh, they get Gold-tier content. No action required from you or them.

Access is per-subscriber. If a subscriber cancels, their token stops serving private content. There’s no shared password to change, no way for a cancelled subscriber to keep accessing your feed through someone else’s credentials.

Token reset is the escape hatch. If a subscriber believes their URL was shared, they can reset their token and get a new URL — the old one stops working immediately. One subscriber’s reset doesn’t affect anyone else.

Plan Limits at a Glance

When Limits Don’t Apply

• Public feed listeners — no token, never counted, no limit regardless of how many people listen
• Followers and free members — exempt from the paying subscriber limit only. Both hold a feed token, so both count toward the total token cap.
• Listeners who only hold episodes they bought — a listener whose membership ended but who kept episodes they bought counts toward neither limit, and is never set aside for being over a limit, so a plan limit cannot cut off their feed. This is a different exemption from the follower one: followers still count toward the token cap. Benecaster does not take away access somebody bought from you.
• WordPress.org version — the free plugin has no subscriber token system and no limits
• Cancellations — a subscriber who cancels is removed from your count immediately; limits are based on currently active tokens, not a historical peak

The Enforcement Timeline

At 80% of either limit, Benecaster shows a dashboard notification with a one-click upgrade path. This is the early warning — you typically have time to act before you actually hit the ceiling.

The rest of this section covers each row in turn.

Going over the paying subscriber limit takes effect right away. Subscribers who join after you have passed it receive your public feed rather than their private one. Nothing is deleted and no URL changes — which feed to serve is decided at the moment a podcast app asks for it, so there is no waiting period to rely on under either enforcement setting. Everyone already under the limit is unaffected.

Their RSS URL keeps working; their podcast app simply receives your public episode set rather than their private tier. A persistent warning appears in your WordPress admin and over-limit listeners are highlighted in Benecaster → Subscribers — see What the Subscribers screen shows you below.

Going over the total token cap depends on your enforcement setting, and this is the one difference between the two limits. On Cap, over-cap free listeners are locked out — their feed URL stops returning a feed at all, which is a different and harder outcome than the demotion above. On Auto-upgrade, nothing happens to anyone: they keep their private feed while your plan is raised instead.

The lock applies to free listeners only — followers and free-tier members, the two groups who hold a token but pay you nothing. A paying subscriber is never locked out, over cap or not — they get the public-feed demotion they have always had. See The free-tier lock below for what it looks like.

What the Subscribers screen shows you

Benecaster → Subscribers highlights every over-limit listener, and the indicator on their row names which of the two outcomes they are actually getting:

A red indicator only ever means a free listener over your token cap. A paying subscriber is never locked, so a red row is never someone who is paying you.

The two limits do not behave the same way

The two enforcement settings look like a matched pair and are not one. Only the token cap responds to its setting:

Why the subscriber limit demotes either way. Raising your plan is not instant: the 24-hour window below has to run first, and your site is over its limit for the whole of it. Demoting is the correct interim state during that wait. Once the upgrade lands, the demotion clears itself at the next daily check with no action from you or your subscribers.

Why the token cap does not. Choosing Auto-upgrade for the token cap is a statement that you would rather your bill moved than your listeners’ access — so nothing changes for anyone’s feed and the plan change is the only consequence.

If I go over my total token cap, who loses access?

Your newest free listeners.

That ordering is a guarantee, not a tendency. Free listeners are exhausted completely before a single paying subscriber is affected; within each group the newest are affected first. A listener whose tier cannot be determined is treated as paying, so they are never chosen while a known free listener remains.

It is worth knowing the guarantee rather than assuming it, because it is what keeps someone who pays you out of the harshest branch of this behaviour.

The free-tier lock

Under Cap, an over-cap free listener’s feed URL returns an error, and most podcast apps report that to them as the feed being gone or unavailable.

The cap is a combined total, so your free ceiling moves as your paying audience grows. Nothing about a free listener has to change for them to end up over the line:

On a site with a 100-token cap, 10 paying subscribers and 90 free listeners, signing up an 11th paying subscriber locks free listener #90.

It reverses on its own. Nothing is revoked, reset or deleted. If that paying subscriber cancels, or you free up room any other way, the locked listener is restored at the next daily validation. There is no new URL to send and no token to reset.

You will have seen this coming. Threshold warnings start at 80% of the cap, and past the cap a non-dismissible notice appears on every admin load. If free listeners are being locked out, the fix is a plan with the headroom your audience already has — see Upgrading Your Plan.

The 24-hour rule is about your plan, not their feed. If your count stays over a limit for 24 continuous hours, Benecaster treats it as a real overage rather than a blip and acts on your subscription — so a limit crossed today is acted on the next day. The window is rolling, not a calendar day and not your billing period — if your count drops back inside the limit the clock clears and starts from zero the next time you go over, so a brief crossing never triggers a change.

Auto-upgrade (default for the paying subscriber limit): Benecaster moves you to the next tier once the 24 hours are up. The email confirming it arrives after the change, not before — what you get in advance is the warning sent when you first go over, so that is the one to act on if you would rather resolve it yourself. On a paid plan the plan changes immediately and the prorated difference for the rest of your current period is charged to your card that day — your renewal date does not change, and your next invoice arrives on its normal date carrying the new rate. Private access restores when the upgrade takes effect. If the card is declined the upgrade simply does not happen: you stay on your current plan and its limits, nothing is charged, and nothing is suspended.

Moving off Launch differs only in the amount, because there is no subscription to reprice — there is one to create. A Launch account crossing its paying subscriber limit is moved to Starter monthly and the card saved at signup is charged the full first month rather than a part-period difference.

Cap (default for the token cap): No upgrade is scheduled and no change to your Benecaster plan is charged. Affected listeners stay where the setting put them until you upgrade yourself — paying subscribers on the public feed, over-cap free listeners locked out. When you upgrade, access restores at the next daily validation — nobody needs to change their podcast app URL.

The defaults are not the same for the two limits, and that is deliberate: the paying subscriber limit defaults to Auto-upgrade, the token cap defaults to Cap. If you have never opened the setting, an over-cap free listener is locked out of your feed and an over-limit paying subscriber triggers a plan change. That is the configuration every install starts in, so the lock is the default behaviour rather than an opt-in one.

Your subscribers keep being billed while over-limit. Neither preference stops subscriber payments — an over-limit subscriber continues paying for private access while receiving the public feed, and does so from the day they join rather than after any grace period. This applies to every membership setup, including Benecaster’s built-in membership: over-limit behaves identically no matter which system handles your subscriptions, so nothing changes if you switch later. This is the reason the admin warning is persistent rather than dismissible — the situation is costing your subscribers money for access they aren’t currently getting, and it’s worth resolving promptly.

Show Limits

Show limits work differently from subscriber limits. There is no grace period and no advance warning at 80%.

When your plan’s show slot is occupied, the Add Show button is disabled and any attempt to create a show is hard-blocked immediately. An upgrade prompt appears linking to Multi-Show or Studio.

Slot recovery: The limit is on active shows, not total shows ever created. Deleting or archiving a show frees the slot — a podcaster who retires Show A can create Show B without upgrading. Only active shows count against the limit.

Restoring Access After an Overage

If any subscribers were receiving the public feed, or any free listeners were locked out, upgrading your plan restores their access automatically at the next daily validation cycle. You can also trigger an immediate validation from Settings → Account → Validate now. No subscriber needs to update their podcast app.