Claude's monthly spend limit is a gate, not a cap

Draft, written 24/08/2026, figures measured that day.

A "Monthly spend limit" field sits on the Anthropic billing page next to your usage-credit balance. Reading it as a British engineer reads a fuse rating, I assumed it did what a fuse does: let current through until a threshold, then stop. It doesn't. It's a gate that's checked before each request starts, and the request itself can be any size it likes.

I found this out the slow way — three times — and then the deliberate way, once.

The bounded test

By 24th August I'd already lost money to this twice (more on that below), so I did the thing I should have done first: set the monthly spend limit to £1.00, left auto-reload off, and switched the usage-credits toggle back on to watch what happened. A pound is a price I'm happy to pay for knowing how a mechanism behaves.

One Claude Code session. Under a minute. £5.29 gone — the entire remaining prepaid balance. The billing page then read "529% used" against a £1.00 limit, with a balance of £0.00.

That's not a limit being approached and enforced. That's a limit being noted after the fact, in the past tense, like a weather report.

The two earlier episodes were the same shape against limits set slightly higher than a pound, each exceeded by at least 200% — and I should be straight with you that those two are my recollection rather than something I captured properly at the time, so treat the numbers as indicative. Between the three of them they consumed the whole £15.00 of prepaid API credit I'd originally bought. An earlier report to support on 16/07/2026 came back with one sentence: "the usage credits purchased on your account have already been consumed." True, and not really the question I'd asked.

What Anthropic actually say

To their credit, the reply to the second, more specific enquiry (24/08/2026) explains the mechanism plainly, and it's worth quoting rather than paraphrasing:

"Our system checks whether you're within your limit before allowing a single request or message to begin. Once that request is processed, we calculate the token consumption—which means a single request can push you past your limit. The limit acts as a gate before each request starts, not as a real-time cap during execution."

So: pre-request gate, post-request accounting. Cost is only knowable after the work is done, which is a perfectly reasonable engineering constraint for a token-metered service. They also confirmed that usage-credit spend is non-refundable under the Credit Terms "regardless of the underlying cause", and declined a refund. Disappointing, but stated clearly and consistently, which is more than I can say for the label on the field.

The bit that still doesn't add up

Their model bounds the overshoot at one request's worth of cost. The observed overshoot was £4.29 — more than four times the entire limit.

There are only two ways I can see that happening. Either it was one near-maximal call (at Opus list pricing, that implies something like a million-token context in a single request, within sixty seconds of the session starting), or a number of requests were admitted after the balance had already passed the limit — in which case the per-request gate didn't do the thing it's described as doing. A transaction-level ledger with timestamps would settle it in about ten seconds. I asked for one; I've been told a human agent is needed, and as I write this it hasn't arrived. So I'm not going to tell you which of those two it was, because I don't know.

What I'd take from it

The practical lesson has nothing to do with whose fault anything is, and everything to do with what bounds your exposure. If you point anything that issues requests in a tight loop at a metered endpoint — and agentic coding tools are precisely that — then:

• The spend limit is telemetry, not a control. Useful for noticing. Useless for stopping.
• The only reliable bound is the size of the prepaid balance. Never hold more usage credit than you'd accept losing in one session, because one session is the granularity at which you can lose it.
• Leave the usage-credits toggle off unless you're actively spending with intent. Off with a £0.00 balance is the only spend cap I've had hold, three times out of three.
• Auto-reload is the failure mode with no floor. I had it off. I'd suggest you do too.

I've landed on subscription plans plus local inference for everything I can, and a £0.00 credit balance for everything I can't — not out of pique, but because it's the only configuration where the worst case is one I've actually computed.

None of this is a secret and none of it is hidden; it's all reconstructable from that one paragraph of support's reply. It just isn't what the interface implies, and the gap between what a control implies and what it enforces is exactly the sort of thing that costs people fifteen quid in three goes.

If you're reading this and you know the answer to the £4.29 question, I'd genuinely like to hear it — I'll update the post.

Ta ta for now, and mind your credit balance.