A user on the OpenAI community forum recently posted a billing dispute. By their account, they had $5 in prepaid credits and auto-reload turned off. They ended up with a $9,152 bill and a negative balance of nearly ten thousand dollars. The thread is titled as a billing review request, so as far as I can tell the case is still open.
This is not an isolated incident. If you run production workloads, or even just experiment with agentic loops, do not rely on your provider's dashboard to protect you. Software limits can fail, and they can lag. You need a hard circuit breaker at the bank level, plus a few guards in your own code.
The Illusion of Control
Most of us assume that when we set a budget cap, the API stops at that number. The OpenAI case suggests you cannot count on that. Per the post, requests kept landing long after the credits ran out.
It is not just OpenAI, and it is not just billing bugs. Reddit posts from this year show the same pattern with Anthropic:
-
A post in r/claude from November 9 is a fresh example. A developer let a coding agent run a routine task, and in 43 minutes it made 29 unrequested changes. The session logs show 109 model calls and 21.3 million tokens, about half a million a minute, roughly $15 for that stretch and $49 for the whole session. About 20.8 million of those tokens were the same context re-read on every call. The user also says the effort level changed mid-session without his input. The dollar figure is small, but the burn rate is the point: at that speed, a few hours unattended is a four-figure bill.
-
One developer reported burning roughly $6,000 of Claude usage overnight after scheduling a
/loopcommand to check pull requests every 30 minutes. It ran 46 times over 26 hours on an Opus model. The dashboard showed only a fraction of the spend because of a multi-day reporting lag. A limit email was the only real-time signal. Prompt caching expiring between runs made each pass re-send a growing conversation at full price.
The cost spreads beyond hobbyists. A recent write-up on a four-agent LangChain pipeline claims it ran for 11 days and burned $47,000 before anyone noticed, because the monthly invoice was the first alert. I cannot verify that number, so treat it as an illustration. As Fast Company has noted, businesses are learning that tokens are not free and that managing the cost is now an operational problem.
The common thread is a mismatch between consumption speed and billing visibility. An agent can hit an endpoint thousands of times a minute, and a retry limit will not help, because a loop is not an error. Every call returns a valid response. By the time a dashboard catches up, the money is gone.
Building a Circuit Breaker
You cannot fix the provider's code. You can control the money you give them. The goal is simple: if a runaway process tries to spend money you did not authorize, the payment fails and the loop dies.
Level 0: Guards in Your Own Code
Cards are the backstop, not the first line. Do these as well:
-
Put a hard iteration cap and a stop condition on every loop and scheduled job.
-
Use a separate API key per project, with its own limit where the provider supports it.
-
Use a cheaper model for unattended work. Save the expensive one for when you are watching.
-
Turn on every usage alert your provider offers, and do not treat the dashboard as a live gauge.
-
Consider a gateway such as LiteLLM that enforces budgets before requests reach the provider.
Level 1: The Virtual Card
This is the most effective tool for a developer or small agency. Do not use your primary card for API access. Use a virtual card service such as Privacy.com (US only) and set a spend limit on each card.
Put a $500 limit on the card behind an experimental Claude project, and the bank declines the 501st dollar. The provider cannot auto-reload through a declined card. That turns a ten thousand dollar disaster into a five hundred dollar inconvenience.
Run a tiered setup. Give your core production API one card with a higher limit and close monitoring. Give every experiment or agentic workflow its own low-limit card. If a buggy script loops, it only burns the small amount on that card.
Know the limits of this approach. A declined card stops new charges. It does not erase usage the provider has already billed, and a provider may suspend your account or keys after repeated failed payments. Some providers also reject virtual cards. Test yours before you depend on it.
Level 2: Prepaid Credit
For steadier workloads, prefer accounts where you load credits up front. OpenRouter is a good example. You load a balance, it burns down, and the service stops when the balance hits zero. Treat it like a prepaid phone: if the project needs $1,000 of tokens this month, load $1,000.
Prepaid is not a guarantee on its own, since the OpenAI case above was supposedly prepaid. It works best when the provider enforces the balance strictly, and the virtual card sits behind it as a second layer.
Stop Playing Roulette
The current state of LLM billing is a bet that the provider's software behaves the way their marketing says. If it does not, you are the one holding the bill, and support is often a queue of generic replies and closed tickets.
If you are still using your primary credit card for API access, you are one infinite loop away from a bad week.
Create a virtual card. Set a limit. Move your keys to it today.
Need a Second Pair of Eyes?
A card limit is the backstop. The rest of the job is deciding which workloads get which keys, which models they run on, and what happens when an agent misbehaves at 3am. Most teams do not have anyone whose job that is.
That is the work we do at ThinkLikeActo.ai. We provide fractional CTO services with a focus on AI: spend controls, vendor choices, and agent architecture that does not surprise your finance team. If you would like help putting guardrails around your AI usage, reach out to us there.
PS AI Disclosure statement; Gemini was used to reproduced me in the role of Stanley Ipkiss from the 1994 comedy "The Mask"
