How to avoid OpenAI bill shock: hard caps that hold

OpenAI has no control that stops a bill in real time. It has three that bound it. One is an opt-in hard spend limit that fails requests with a named 429 error. One is a prepaid credit balance with auto-reload turned off. One is a wallet-shaped account where the worst case is the balance itself. Each of the three has a delay, in OpenAI's own words. This page checks every control against OpenAI's docs today, works the worst-case math, and puts the documented cases next to the controls that would have stopped them.

All amounts on this page are US dollar amounts, written as bare numerals. Every provider state below was checked against that provider's own docs on 2026-10-26.

This page is one half of a pair. The general machinery lives in the published guide how to avoid API bill shock. That guide owns the five causes of a runaway bill, the four-provider table, the key hygiene list, and the dispute playbook for a bill that already landed. This page owns the OpenAI questions. What caps OpenAI spend. How hard the cap is. What the worst case looks like in numbers.

What OpenAI gives you today, control by control

OpenAI ships five spending surfaces. The split that matters: which ones only tell you, and which ones refuse requests.

Start with the hard spend limit, since that is the one readers ask for. It is off until you turn it on. The spend limits guide states the behavior plainly. When tracked spend reaches an enforced limit, "affected API requests return a 429 error with the organization_spend_limit_exceeded or project_spend_limit_exceeded code." Then comes the sentence to read twice: "Enforcement is not instantaneous, so recorded spend can slightly exceed the configured amount."

Two facts there do a lot of work. The limit sits at the account level and again at the project level. You can cap one risky workload without capping the whole company. The failure also carries a named code, not a mystery. Your logs can tell a spend cap from a rate limit. The changelog dates the feature to July 2026. That month OpenAI wrote: "Added hard spend limits for organizations and projects on the OpenAI API platform."

Spend alerts are the soft half. They never stop a request. Making a project spend limit adds an alert at 100 percent of the limit by default. You can add more at other levels. An alert at 100 percent of a cap that lags arrives after the interesting spending is done. Set them at 50 and 90 percent. Give yourself room the lag cannot eat.

Above both sits a cap you did not set. OpenAI gives every account an approved monthly usage limit by tier. It is separate from the spend limits you set. The rate limits guide carries the current table, cut to three paid tiers in October 2026:

Now the billing side. "New API accounts use prepaid billing," per OpenAI's prepaid billing article. You buy credits first. Usage draws the balance down. A balance at zero fails requests with credit_balance_exhausted. The smallest purchase is 5. The default first purchase is 10. Bought credits expire after one year.

The prepaid floor has a trap and a delay. The trap: auto-reload is on by default at setup. A balance that refills itself is not a ceiling. It is a deal to keep paying while something burns. If you keep auto-reload, set the monthly reload limit. Know that "a recharge limit is not an API usage limit," in OpenAI's words. The delay: "API access may not stop immediately after your credits run out. Usage processed during this delay can appear as a negative credit balance." OpenAI's own closing line is worth the whole quote: "Do not rely on the prepaid balance as an instantaneous spending cutoff."

Older accounts and enterprises see other shapes. Card billing collects "at usage thresholds or monthly." A stolen key on a card account can trigger mid-month charges, not one month-end invoice. Enterprise API customers get invoices after the month ends.

The documented cases, with the figures

The published guide carries the full case record. The shared figures are byte-checked against it here. Two new cases have landed since.

May 2025, a web dev forum. A student spent four days on a Google Maps feature. The bill came in close to 10k. No billing email arrived. The first notice came from a fraud flag on the account. The top advice was to beg for a waiver. The sharpest reply asked the question that matters: is your key in a public repo.

March 2026, The Register. A three-developer company was billed 82,314.44 in 48 hours after someone stole its Gemini API key. The firm normally spent about 180 per month. The outlet called it about a 46,000 percent jump. The provider cited the shared responsibility model. The charges stood.

June 2025. A student pushed a Gemini API key to GitHub. The bill hit 55,444.78. Most of a 300 free credit was still sitting on the account.

The costgoat archive, page-dated 2026-05-18, counted 2.4M-plus in documented surprise bills. Its entries: 100 coding agents that burned 603 billion tokens for a 1.3M month. A stolen key that ran 19 billion translation calls for 450k. A flood aimed at one sound file that pushed a free static site to 104.5k. A buggy auto-translate loop that called a paid API six billion times in two days for 121k. One dating note, told straight: that archive no longer resolves. The domain now sells a monitoring app. The figures stand on the published guide's record.

October 2026 brought a case closer to home. The Hacker News reported on October 19 that an intruder reached OpenCode Console on the night of October 16. OpenCode Console is a hosted workspace where users paste their own provider keys. Keys for OpenAI, Anthropic, and Google accounts may have leaked for 1.4 percent of its users. The named losses were small next to 82,314.44, and real. One user reported 281 spent on his OpenAI key and 168 on his Anthropic key. Another put his losses at 1,700. A third reported 400. The lesson is in the shape, not the size. A provider key is a bearer credential. Deleting it from the tool does not revoke it. The tool's own budget cannot cap spending it never sees.

February 2026, via The Register again. Security researchers counted 2,863 live Google API keys embedded in public websites. The keys were pasted in as map embeds. The same key format later began to open billable model access, and many owners never knew. Every case in this section ends the same way. Where a stop held, it ran on the provider's side of the wire.

Can you hard-cap OpenAI spend? The direct answer

No single switch stops the meter at once. Here is the honest answer, checked today.

First: a true instant cap does not exist at OpenAI. The hard spend limit is close, but opt-in, and it lags a little. The prepaid floor is close, but it can dip negative before it holds.

Second: the two stack. Put a hard limit on a prepaid account. The month is then bounded twice. Requests fail at the cap. And the balance cannot charge a card you never gave.

Third: no OpenAI control is per key. The cap covers an account or a project. So give each workload its own project and its own key. A leak then lands inside one capped box.

The lag, per party, in their own numbers:

One split decides which controls matter. The published guide states it well: provider-side against client-side. A counter in your own code is worth having. It cannot stop a thief, because the thief does not run your code. The meters that bind a stolen key all run on the provider: caps, hard limits, and balances that run out. Audit your own setup by that one property.

A spend alert is a note about yesterday's money. A hard limit is a decision about tomorrow's.

The worst-case math, worked with today's rates

The published guide names the shape. On a postpaid account, the worst case is rate times volume, and volume has no ceiling. On a prepaid account, the worst case is at most the balance you loaded. Here is that math again with OpenAI's current rates, then with this platform's.

Symbols first, with named variables. Let r be the per-unit rate, V the volume a runaway job eats, and W the wallet balance when things go wrong:

postpaid worst case:  cost = r x V      and V is unbounded
prepaid worst case:   cost = at most W  the balance is the ceiling

Now numbers, on OpenAI's listed rates for GPT-6 Luna, read 2026-10-26 from OpenAI's own model page: 0.10 per million input tokens, 0.50 per million output tokens. Picture a retry loop. Each call sends 10,000 input tokens and 1,000 output tokens. It runs ten times per second for two days:

cost per call = 10,000/1,000,000 x 0.10 + 1,000/1,000,000 x 0.50
              = 0.0015

calls in 48 hours = 10 x 3,600 x 48 = 1,728,000

postpaid cost = 1,728,000 x 0.0015 = 2,592
flagship tier = the same shape at 100x rates = 259,200

prepaid, W = 20: the loop stops at call 13,333 and the next
request fails

That is the whole argument in four lines. A cheap model in a tight loop, the least scary setup you can name, spends 2,592 in two days on an open account. The same shape on the flagship tier spends 259,200. A 20 balance turns either run into a denial and a dead loop. The sensitivity line: the rate sets how fast the bleed runs. Only the billing shape sets the ceiling.

This platform is prepaid only. That is the shape the math argues for. You top up a wallet. Every request meters against it per unit. A balance at or below zero denies the next request. The units differ by lane, which matters when you size a wallet. Chat meters per million tokens on models like qwen3.8-27b. Text to speech meters per million characters on models like pocket-tts. Speech to text meters per audio-hour on models like hayamimi-stt. Document parsing meters per page. Two honest limits, as current facts. There is no per-key spend cap on this platform today, so the wallet floor is the stop, and the answer to a leak is revoking the key, which takes one action. And a wallet does not budget for you. Load for the work you plan. Treat the balance as your blast radius.

The defensive checklist, control by control

Each control below carries its real state today, per party. The published guide owns the general list. This one is the OpenAI-first cut, current as of 2026-10-26.

1. Turn the hard limit on, twice. Once at account level for the firm, once at project level for each workload. The toggle ships off. Opting in is the whole difference between a cap and a hint.
2. Go prepaid, and fix auto-reload. New OpenAI accounts already are prepaid. Turn auto-reload off, or set a monthly reload limit. Remember it caps purchases, not usage. The wallet is only a ceiling when nothing refills it.
3. Set alerts at 50 and 90 percent. The default alert fires at 100 percent of a limit that already lags. Earlier alerts buy back the time the delay takes.
4. One key per workload, one project per risk. OpenAI keys can carry expiry dates. Since September 2026, admins can enforce a maximum key life across the account, which turns rotation from a habit into a rule. The October breach was contained by revocation, not by detection.
5. Never ship a key in client code or a repo. The 55,444.78 student bill and the 2,863 embedded keys are one mistake at two scales. If a key must live in a browser, put a budget under it that fails closed.
6. Watch usage, not invoices. Usage views update faster than billing views. OpenAI also ships a Usage API for querying spend with code. That is how a local tripwire gets its numbers. The published guide carries a working tripwire snippet.
7. Treat the spend-cap 429 as a stop, not a slow-down. The cap error reuses the rate-limit status. An engineering post dated October 10 2026 measured the official Go SDKs retrying the cap response three times before surfacing an error. Catch the named codes, organization_spend_limit_exceeded and project_spend_limit_exceeded, and shut the job down.

Hard caps became a shipping feature in 2026

For years the answer to "can I hard-cap my API bill" was no. In 2026 it flipped. Google Cloud shipped Spend Caps in July 2026, per its own spend cap budgets doc. They block new usage per project for a list of services that includes the Gemini API. OpenAI added hard spend limits that same month. AWS followed on September 16 2026 with project spend limits that pause a project at the limit, per its spend limit doc. The minimum is 20, on paid plans. Anthropic's Claude API carries tier spend caps of 500 on Start, 1,000 on Build, and 200,000 on Scale per month, per its rate limits doc. Usage pauses at the cap until the first of the next month, with a 429 and an enforced_spend_limit_reached code.

The holdout is the old shape. Azure budgets still only alert. Cost data runs 8-24 hours behind, and budgets are checked once every 24 hours. Google Cloud's classic budgets only alert too. The new spend caps are the separate, newer thing.

Simon Willison argued on October 3 2026 that hard caps should be the default everywhere, with an opt-out for the daring. In his words, soft caps that send a warning email "will not cut it." The ship dates above show the direction. Defaults lag. Until your provider defaults to a cap, opting in yourself is the whole game.

Frequently asked questions

How do I stop OpenAI billing?

Cut the account's ability to spend, in this order. Turn on "Enforce a hard limit" at account and project level, so requests fail at the cap. Switch to prepaid credits and turn auto-reload off, so there is no card to charge. Revoke any key you cannot account for. Usage stops failing inside the delays above. It does not stop mid-request.

Why does OpenAI keep charging me?

Three usual causes. Auto-reload, on by default at prepaid setup, buys fresh credits whenever the balance dips. Card billing collects at usage thresholds, not just month-end, so heavy use triggers mid-period charges. And a leaked or shared key spends on your account until you revoke it, which no local budget prevents. Check the usage view for calls you do not recognize. Then revoke and rotate.

What happens when my OpenAI credits run out?

API requests begin failing with the code credit_balance_exhausted. A little usage can still land during the delay and show as a negative balance. That amount comes off your next purchase. New credits take effect within a few minutes.

Is OpenAI's hard spend limit really hard?

It is hard in one sense. Requests fail once tracked spend reaches it, with a named 429 error. It is not instant. OpenAI states that recorded spend can slightly exceed the amount while the limit travels. Treat it as a wall with a short runway before it, and set alerts below it. The prepaid floor is the same shape, with its own short delay.

The wallet-first shape is how this platform bills. Per unit, against a prepaid balance, with current rates on the pricing page. You can open an account, load a small wallet, and put a key over it at signup. The general guide, with the four-provider table and the dispute playbook, is how to avoid API bill shock.

Last verified: 2026-10-26