"Why is my OpenAI bill so high" is one of the most-searched questions about the API, and most answers stop at "use a cheaper model." That's true but incomplete. Here's the actual list of causes, roughly in order of how much money each one has cost real people, plus what genuinely stops each one (not just warns you about it).
1. Retry loops without backoff
The single most common cause. A request fails (rate limit, timeout, transient error), your code retries immediately, fails again, retries again - in a tight loop, that's hundreds of billed calls in minutes. Fix: exponential backoff with a hard retry ceiling (3-5 attempts, not infinite), and a circuit breaker that stops the whole loop after N consecutive failures rather than retrying forever.
2. A leaked or shared key
A key committed to a public repo, embedded in client-side code, or shared across a team with no per-key limit gets used by more than just you - sometimes within hours of being indexed by a scraper. Fix: never ship a key to the client, rotate immediately if a repo goes public with one in history, and if multiple people/services need access, give each its own key so a leak is isolated and traceable.
3. Defaulting to the expensive model for everything
Classification, extraction, routing, and simple formatting tasks almost never need the flagship model - a smaller/cheaper model handles them at a fraction of the cost with no meaningful quality loss. Fix: route by task complexity, not habit; reserve the expensive model for the calls that actually need its reasoning.
4. Resending the full conversation history every call
If your app passes the entire chat transcript as input on every turn, a 50-message conversation means message 50 pays for messages 1-49 all over again, every time. Fix: persist durable facts and pass a short summary plus relevant recent context instead of the whole history, and turn on prompt caching if your provider supports it - the repeated prefix (system prompt, tool definitions) drops to a fraction of normal input price.
5. Streaming and agent loops with no stop condition
An agentic loop that calls itself, evaluates, and calls again with no cap on iterations can burn through a budget in minutes if it gets stuck re-trying a task it can't complete. This is the fastest way to turn a $12 side project into a $300 bill overnight. Fix: hard iteration ceilings on any agent loop, and - this is the one most people skip - a check against actual spend so far, not just call count, since calls vary wildly in cost.
The setting that looks like a cap but isn't
OpenAI's dashboard "usage limit" is a notification threshold, not a hard stop. Cross it and you get an email; your requests keep going through. If you genuinely cannot afford to go past a number, that setting alone will not save you - you need something that actively checks spend before or during requests, not an email after the fact.
The real fix, for anyone building this themselves: don't do "read balance, compare, then decrement" as two separate steps - that has a race condition where two concurrent calls can both read "under budget" before either commits. Make the reservation itself atomic (a single compare-and-swap or a real ledger hold against one authoritative counter), so a second call's decrement simply fails once the first has already taken the balance below the threshold.
If you just want the email, not the engineering
Building the atomic-reservation version yourself is the right answer if you're already running agents in production at real volume. If you're a solo developer who just wants to know before a number gets crossed, that's a smaller problem, and it's the one I built Fusebox for: set a monthly ceiling, connect a read-only usage key (scoped so it can only ever see spend, never touch billing or make requests), get emailed at 50/80/100%. Free tier alerts once you've already crossed 100%; paid tier ($7/mo) adds the earlier 50/80% warnings that actually give you time to react before the bill is final. It's not a replacement for the atomic-reservation pattern above if you're at scale - it's the "email me" version for everyone else.
Either way, the actual lesson underneath all five causes above is the same one: OpenAI's per-token pricing means cost tracks behavior, not intent. Code that's correct can still be expensive if nothing is watching what it actually spends while it runs.
Top comments (0)