Runaway AI bill right now? The first 10 minutes.
This one’s for the person who found this page by searching in a mild panic. Your agent has been looping, or a key leaked, or the number in the billing console is climbing and you don’t know why — and it’s still happening. Good news: you can stop most of the bleeding in about ten minutes. Do it in this order, because the order is what saves the money.
Don’t read the whole playbook first. Every minute you spend understanding the problem is a minute the meter keeps running. Stop it, then understand it.
Minute 1–2: Kill the key
The fastest way to stop the spend is to make the thing doing it stop working. Revoke the API key at the provider — in the OpenAI / Anthropic / Google Cloud console, not in your own app’s config. A call can’t bill a key that no longer exists. This is faster and more certain than trying to redeploy your app, restart the agent, or find the bug.
If it’s a cloud key (Gemini/Bedrock/Vertex tied to a cloud project), and you can’t tell which key, you can go one level up in the next step — but if you can see the offending key, kill it now.
Don’t worry yet about breaking legitimate traffic. A few minutes of your real feature being down is cheaper than the runaway. You can mint a fresh, restricted key in a moment.
Minute 3–5: Trace what’s calling
Now find the source so you don’t fly blind:
- Provider usage dashboard — OpenAI, Anthropic, and the cloud consoles all show spend by key (and often by model). The key that’s on fire is usually obvious: it’s the one with 100× the others.
- Which workflow? If your keys aren’t split by feature, this is harder — which is exactly why the gateway pattern and per-workflow tagging exist. For now, correlate the spike’s start time with what you deployed or what changed.
- Is it you or an abuser? A looping agent burns steadily from your own infrastructure; a leaked key burns from unfamiliar IPs at machine speed. Both are stopped by killing the key.
Minute 6–8: Cap the account (the real stop, not the alert)
Killing the key stops the current attacker. Now put a floor under the account so the next surprise can’t run unbounded — and understand the trap: a budget alert does not stop anything. It emails you. You need the action that disables.
Stop it first, understand it second — every minute reading is billed.
- Google Cloud: trigger the documented budget → Pub/Sub → function that disables billing on the project. A “budget” alone is not a cap — here’s why a $50 account can hit $20k.
- AWS: a Budget Action that can stop resources / detach the policy — not just an alert.
- The provider itself: set the hardest usage limit the API offers, and lower per-key quotas to what your real app needs.
Minute 9–10: Preserve the evidence
Before you close the console, screenshot everything — because you may get this money back:
- the spike on the billing/usage graph,
- the anomaly email and its timestamp (if the provider sent one),
- your mitigation timeline — when you revoked the key, when you capped it.
That timeline is your case. Providers waive first-time accidental and abuse-driven bills more often than people expect — and the strongest fact is “their own system flagged it and I shut it down within minutes.” (Full waiver playbook: how to get an AI overage waived.)
Then — and only then — fix it so it can’t happen twice
Once the fire’s out, the permanent fixes are the boring, one-time ones:
- A cap that fails closed — the call gets refused at a ceiling, instead of billing forever. (caps + quotas)
- The key off the client — never ship a model key in a web or mobile app. (the $55k key mistake)
- Auth on the endpoint — an LLM route spends money; guard it like a payment endpoint. (auth on AI endpoints)
- A breaker on the request path, so a failing agent trips instead of looping. (kill switch on the request path)
If you’re in the middle of one of these right now and want a second set of eyes, or you want the guardrails put in before the next one, that’s exactly what I do. It’s just me, so it comes straight to me and I reply fast. Send me what’s happening — I’ll help you stop the bleed and, if you want, wire the fail-closed cap + per-feature attribution so there’s no next time. A prevented runaway pays for the whole thing.