The bill arrives before the alert does. Cap the blast radius now.

How a bill runs away.

The most common route is a key with spending power sitting in public. AI coding tools reach for the path of least resistance: a config object in client code with the raw key in it, or an environment variable prefixed VITE_ or NEXT_PUBLIC_, which by design is inlined into the JavaScript your users download. Automated scrapers collect keys from public bundles and repos around the clock, and when one lands on a Google key with no restrictions, the attacker does not use it for your app's two Firestore reads. They point it at the most expensive API it can reach, which today is usually an LLM endpoint, and run it flat out. That is the whole mechanism behind the $60,000-in-13-hours report: exposed key, no application restriction, no API restriction, Gemini access.

The subtlety that traps Firebase apps specifically is that the web config's apiKey is public by design. Shipping it is normal. It is only safe when the key is restricted to your domains and your APIs and your data is guarded by security rules. An unrestricted key that can also reach paid AI APIs is not a config value, it is a blank cheque.

The second route is an open proxy: you did the right thing, moved the provider key server-side, and then exposed an endpoint that forwards requests without checking who is asking or how often. Attackers do not need your key if your endpoint will spend your money for anyone who posts to it.

The third route is your own software: a retry loop without backoff, an agent that calls a paid API inside a loop, a cron job running against production. And occasionally the meter itself is wrong. On 11 July 2026, Replit reported that a cost-calculation error had inflated checkpoint charges for roughly 6 percent of paying users for several hours; it fixed the error and refunded automatically. The lesson is not that platforms are careless, it is that invoices are software output and deserve the same scepticism as any other output: read them.

What makes all three routes expensive is the broken feedback loop. Firebase's own billing documentation warns that budgets and budget alerts do not cap your usage or charges, and that the alert email can arrive days after the costs were incurred. By the time a human reads the warning, the damage is done. So the plan is: shrink what a leaked key can do first, then put hard stops where the provider actually offers one.

Ten minutes on key lockdown.

1. Restrict every Google API key twice. In Google Cloud Console, open APIs & Services, then Credentials. Every key needs an application restriction (which websites, IP addresses, or apps may use it) and an API restriction (which APIs it may call). Google rejects any request that does not satisfy the restrictions. A key locked to your domain and to the two APIs your app uses is a much smaller prize than an open one, whatever else goes wrong.
2. Search what you actually shipped. Open the built, deployed JavaScript, not your source, and search for AIza, the prefix of every Google API key, and for sk-, the prefix of most LLM provider keys. Anything you find is public. A Google key with restrictions may be fine there; an LLM provider key never is.
3. Rotate anything that shipped unrestricted. Assume it was harvested the day it went live. Rotation and the rest of the incident drill are in the leaked-key response plan; the short version is that the new key must not ship in the next bundle, which is what the next step prevents.
4. Keep LLM keys server-side only, behind your own auth and rate limit. The client calls your endpoint, your endpoint holds the key and checks the user before forwarding. The proxy pattern is a dozen lines; the auth check and the rate limit are the two lines that keep the proxy from becoming route two above.

The caps that actually exist, provider by provider.

Anthropic has real caps. The Claude Console lets you set a monthly spend limit for the organisation, and a lower one per workspace. A workspace limit caps that workspace's monthly spending outright, which is exactly what you want: put your production key in its own workspace with a limit you can afford to lose. Note that you cannot set limits on the Default Workspace, which is one more reason not to run production from it.

OpenAI has per-project limits. The platform supports custom rate and spend limits per project, alongside a notification threshold that emails you at a dollar amount you choose. Every account also starts with an approved usage limit, from $100 per month, that rises with your usage tier. Keep production in its own project with its own limit, and set the notification threshold well below the number that would hurt.

Supabase has a Spend Cap. On the Pro plan it is a single toggle in the organisation's Cost Control settings: with the cap on, once you exceed the plan quota for a covered item, further usage of that item is disallowed until the next billing cycle instead of being billed. It covers the abuse-shaped items, egress, edge function invocations, active users, realtime, storage; it does not cover things you explicitly provision, like bigger compute or point-in-time recovery. The Free plan never charges at all, it just stops.

Google, including Gemini and Firebase, has no native cap. This is the one to internalise, because it is where the biggest bills keep happening. A Google Cloud budget is a monitoring tool: its own documentation states that it does not cap usage or spending, it only alerts. The supported way to get a hard stop is to wire the budget's Pub/Sub notification to a small Cloud Run function that calls the Cloud Billing API and detaches billing from the project. Google documents this pattern, with a warning worth taking seriously: disabling billing shuts down all resources in the project and some may be irretrievably deleted. That is the correct trade for a side project or an early-stage app, where the worst case should be an outage, not a mortgage. Decide which one your app is before the meter decides for you.

Prepaid platform credits are a cap of a different kind. Lovable runs Cloud usage on workspace credits and pauses a project when the balance runs out, which bounds the damage by construction. Replit's effort-based pricing draws from your account in the same prepaid spirit. The residual risk on credit-metered platforms is metering bugs, which is what the 11 July incident was; the defence costs one minute a month: read the invoice.

If the bill has already landed: stop the burn first, rotate and restrict the key, or take the endpoint down. Screenshot the provider's usage pages before anything resets, so the abuse window is documented. Then contact the provider's billing support and ask for an adjustment, in writing, with the evidence attached. Providers have refunded abuse-driven bills, Replit refunded its own metering error unprompted, but none of them guarantee it, and your case is strongest when you can show the leak is closed and the usage pattern was plainly not yours.