Why is my OpenAI API bill so high? No rate limiting on your AI endpoints

Symptoms

• Your OpenAI or Anthropic bill jumps into the hundreds or thousands overnight, before you notice anything is wrong
• The provider's 'usage limit' email arrives after the money is already spent
• Usage logs show your LLM endpoint hammered by a bot, a competitor's scraper, or one determined user in a loop
• Documented cases include four-figure bills from a single exposed key in under 24 hours
• Automated abuse against reasoning models has generated $500 to $5,000 per day

Why it happens

AI-generated backends ship without working rate limiting

A Tenzai study of 15 AI-generated apps found only one even attempted rate limiting, and that one was bypassable. Scaffolded code optimizes for working, not for surviving contact with the public internet.

Limiter middleware written but never wired in

DryRun Security found agents writing rate-limit middleware into files without ever connecting it to the app. The code exists, passes review, and does nothing in production.

Provider 'usage limits' that notify instead of stop

OpenAI's dashboard usage limit has historically behaved as a notification threshold rather than a hard stop, so alerts fire while requests keep processing and billing.

A public endpoint that proxies a paid API

Any unauthenticated route that forwards requests to an LLM is free compute for whoever finds it. Bots and scrapers do find it.

How to fix it

1. Contain the spend firstIf the bill is actively climbing, take the costly endpoint offline or put it behind auth immediately, and rotate any API key that may have leaked. Every minute the endpoint stays open and anonymous costs you money.
2. Add rate limiting at the edgePut limits in front of your app, not buried inside it: Vercel WAF rules, Cloudflare rate limiting, or middleware such as @upstash/ratelimit keyed on both IP and user ID. Edge enforcement rejects abusive traffic before it ever triggers a paid API call.
3. Require authentication on anything that costs money per callAnonymous access to an LLM proxy is an open wallet. Every endpoint that results in a provider charge should verify a session or token before doing anything else.
4. Set hard spend controls and independent alertsUse project-level budgets and limits where the provider supports them, and add billing alerts you control on top. Do not assume a 'usage limit' field is a cap; verify what it actually does before you rely on it.
5. Add per-user quotas in application logicCap each account at N requests per day so a single authenticated user cannot drain the budget either. Rate limiting by IP alone does not stop a logged-in user running a loop.
6. Prove the limiter actually firesLoad-test the endpoint and confirm requests get rejected at the threshold. A limiter that is defined but never wired in passes code review and fails in production, so watch usage dashboards daily during launch week.

How to prevent it

• Ship rate limiting with the first deploy of any endpoint that calls a paid API, not as a later hardening pass
• Never expose an anonymous LLM proxy, even for a demo
• Set provider budgets and independent billing alerts on day one
• Load-test the limiter before launch to prove it triggers
• Check usage dashboards daily during launch week

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

Frequently asked questions

Sources

• Zuplo: Vibe coding and API security
• Capped: Why is my OpenAI bill so high?
• Rafter: OpenAI API key exposure
• How to stop your OpenAI API bill from spiraling out of control

Related errors