Free AI Credits Can Quietly Switch On Metered Billing

On a subscription plan the rate limit is a spend cap you never configured: hit it and you stop. Usage credits remove that wall and replace it with a meter, and it takes one toggle. Claude Pro users reported a $100 promotional credit leaving usage credits enabled with no limit, after which overage applied to every model past their plan allowance. The report is contested, which is exactly why you should read your usage settings instead of assuming.

7 min read

AI billingusage-based pricingspend capsClaudepromotional credits

The short answer: On a subscription plan, the rate limit is a spend cap you never had to configure. When you hit it, you stop. Turning on usage credits removes that wall and replaces it with a meter, and the switch is easy to flip without meaning to: several Claude Pro users reported that claiming a $100 promotional credit left usage credits enabled on the account with no limit set, at which point overage billing applied to every model they used past their plan allowance, not just the model the promo was for.

The report is contested, and that matters: other users checked after claiming the same promo and found the setting off. Either way the lesson holds. Credits and plan limits are two different billing modes, the boundary between them is one toggle, and nothing in the product tells you when you have crossed it. Go and look at your usage settings rather than assuming.

Most writing about AI cost control is about picking cheaper models. This is about something duller and more expensive: the moment your account changes billing mode without you deciding to. It has now happened publicly, to paying subscribers, on a first-party promotion, and the shape of it is worth understanding whether or not you use Claude.

The rate limit was doing a job nobody credited it for

A subscription plan with a usage cap has an accidental virtue. When you exhaust the allowance, the product refuses you. It is annoying, and it is also a hard spend ceiling that required zero configuration, no budget alert, no webhook and no finance conversation. You cannot overspend a wall.

Usage credits are the opposite design. They are there precisely so that hitting the wall does not stop you. That is the feature. The problem is that the two modes look identical right up to the point where one of them keeps going, and the difference between "you are rate limited, come back later" and "you are now paying per token" is a single account setting.

What was reported

In late July 2026 a Claude Pro subscriber posted that they had been offered $100 in promotional credits for Fable 5 and claimed them. Their account summary of what followed, which drew around 1,700 upvotes and 350 replies:

"What isn't made clear anywhere in that flow: claiming those credits automatically enables usage credits on your account with no limit. And once usage credits are on, they don't just apply to Fable 5. They apply to everything you do past your normal plan limits."

"So I carried on using Opus 4.8 like I always do. Hit my 5-hour limit. Instead of the usual 'you're rate limited, come back later,' it just kept going. Quietly billing me."

They noticed at about NZ$50 of unintended spend. The most-upvoted reply in the thread simply agreed that the objection was fair. A team-plan user reported the same thing causing problems across their organisation.

The part that makes it useful rather than just a complaint

The report is not unanimous, and the disagreement is the most instructive thing in the thread. One reply, itself well upvoted, said this:

"I claimed my $100 earlier today and I just checked, credit usage is not enabled in the 'usage' settings tab. Maybe you already had it enabled before."

That is a plausible alternative explanation and it should not be buried. It is entirely possible the promo did not flip anything, and that the affected accounts already had credits enabled from an earlier session and had simply never spent past a plan limit before, so the setting had never had a visible consequence.

Notice that both explanations end in the same place. Either a promotional flow changed your billing mode, or your billing mode was already changed and you did not know. In both cases you cannot tell from using the product, and in both cases the fix is the same thirty-second check. Another reply described exactly that instinct:

"As soon as I claimed it I thought, 'but how will it know when to stop?' Went in, saw the option, immediately turned it off."

Why this generalises past one vendor

This is the second time in a year that a free tier or a free grant has turned out to be entangled with a billing-mode switch. Enabling billing on a Google Cloud project removes that project's Gemini API free tier, so calls that were free start billing from the first token, which we covered in the Gemini free-tier writeup. Different vendor, different mechanism, identical failure: a change in billing state that the interface presents as a benefit.

The pattern is not malice, it is a consequence of bolting metered billing onto products that were designed around flat plans. Credits, overage, promotional grants and plan allowances are four different accounting concepts sharing one account, and the vendor's own UI is usually the last place their interaction gets explained.

What to actually do

  1. Open the usage or billing settings on every AI account you pay for and read the current state. Not what you think you set, what it says now. If there is a credits or overage toggle, note whether it is on and whether it has a limit.
  2. Set an explicit limit even if you want overage. "On, with no limit" is the dangerous configuration, not "on". A cap you chose is a different thing from an absence of a cap.
  3. Treat a claimed promotion as a billing event. Re-check the settings after accepting any credit grant, trial extension or bonus allowance, because that is the flow most likely to touch billing state.
  4. Watch for the tell. If you used to get rate limited and you have stopped getting rate limited, that is not generosity. Something is absorbing the overflow and it is probably your card.
  5. Meter it yourself if the spend matters. A vendor dashboard tells you what a vendor charged. It does not tell you which team, feature or customer caused it, and it does not tell you in time to stop.

Where UsageBox fits

UsageBox exists because the vendor's meter and your meter answer different questions. The vendor tells you a total, after the fact, per account. Your own meter tells you which customer, feature or agent generated the usage, in time to act, and it survives the vendor changing its pricing model underneath you. If you are reselling or rebilling AI usage, that gap is not a nice-to-have: a billing-mode change on your upstream account is a margin event you need to see the same day, not at invoice time.

Related reading: hard spend caps and kill switches, why unlimited AI plans died, and the Fable 5 usage-credits cutover.

Key Topics

  • AI billing
  • usage-based pricing
  • spend caps
  • Claude
  • promotional credits

Related Articles

Explore more articles on similar topics to deepen your understanding of usage-based billing.

Per-Seat Pricing Can't Survive Agentic Users: The SaaS Margin Math That Breaks in One Loop

If you sell software at a flat per-seat price and your product calls an LLM that bills per token, your margin is a bet t...

6 min readRead more

The $23,000 Vercel Bill: How Usage-Based Platforms Create Bill Shock (and How Not To)

A DDoS attack turned a developer's Vercel account into a $23,000 bill because all attack traffic billed at the standard ...

10 min readRead more

Metered AI Billing Is Breaking Developer Trust. That Is an Engineering Failure, Not a Pricing One

The June 2026 revolt against metered AI billing (the GitHub Copilot credit switch, "pay the same, get anxiety for free",...

9 min readRead more

Explore More Articles

Discover our complete collection of usage-based billing guides and implementation patterns.

View all articles