How to · Emergency

My API Bill Is Too High. Here Is Exactly What to Do Right Now

By Ghiles Asmani, founder of Weckr

You just opened the billing page and your stomach dropped. The number is way bigger than it has any right to be, and your first instinct is to either panic or start ripping things out at random.

Do not do that yet. A high bill is a symptom, and if you start cutting before you know the cause, you will probably break your product and still not stop the leak.

Here is the calm version. A short triage to find the real offender, three fast fixes, and one thing to set up so you never get ambushed like this again.

First, breathe. Do not delete things at random

The scary number is not the problem. It is the receipt for a problem, and the problem is almost always small and specific once you look.

Slashing features in a panic feels like action, but it usually hits the wrong thing. You turn off a feature users love while the actual culprit, some quiet retry loop, keeps billing you all night.

So spend the next few minutes finding the cause. It really does not take long, and you almost certainly have everything you need already.

The 60 second triage

Open your provider usage page, or better, your own request logs. You are answering three questions, in order.

1. Which model is being called the most?

Group your spend by model. If a heavy model like gpt-4o or claude-opus-4-8 is doing work that a small model could handle, you have likely found a big chunk of the bill right there.

2. Is anything looping or retrying?

Look for the same call firing over and over in a short window. A retry with no backoff, or an agent with no stop condition, can quietly send hundreds of calls while you sleep. This is the best case, honestly, because it is a bug you can just kill.

3. Is one user or one feature the outlier?

Sort by user id and by feature. Usually it is not spread evenly. One customer or one endpoint is carrying most of the cost, and everyone else is a rounding error. Find that one and you have found your bill.

Find the worst offender without any fancy tools

You do not need to buy a monitoring platform at 11pm. You need a sorted list.

Export your raw request logs to a CSV, or write a ten line script, and sort by cost or by total tokens, biggest first. Then look at the top twenty rows and ask what they have in common: same model, same user, same endpoint.

The pattern shows up fast. A single power user hammering one feature. A background job that runs on a loop. A model that is five times pricier than the task needs. Once it is sorted, the offender is rarely subtle. If you want to sanity check the math, drop your token counts into the break even calculator and see the real per call cost.

The three fastest fixes

Once you know the cause, the fix is usually one of these, and you can ship it tonight.

  • Switch to a cheaper model for the offending feature. If a summary or a classification does not need a flagship model, move it to a small one. Our take on when the mini model is enough walks through where you can safely downgrade and where you should not.
  • Add a hard spending cap. Put a dollar limit per user or per key so nobody, including a runaway bug, can run past it. Here is how to set spending caps per user without rewriting your app.
  • Kill the obvious bug. Add a backoff to retries, set a max_tokens limit, or give your agent a stop condition. If an agent is the culprit, these common causes of a runaway OpenAI bill will look familiar.

Do the one that matches your triage result. You do not have to do all three tonight, just the one that stops the bleeding.

The real fix: so this never blindsides you again

Here is the uncomfortable truth about tonight. The bill did not surprise you because the cost was huge. It surprised you because it was one big number with no breakdown, so you could not see it building.

The permanent fix is per user visibility. When you can see cost and margin for every customer in real time, a spike is a notification you get in hours, not a number you discover weeks later. That is exactly what Weckr does. You wrap your existing OpenAI, Anthropic or Gemini client and it tracks cost per user and per feature for you.

import { Weckr } from '@weckr/sdk'

const wk = new Weckr({
  apiKey: process.env.WECKR_API_KEY,
  plans: { free: 0, pro: 29 },
})

const response = await wk.chat(openai, {
  model: 'gpt-4o-mini',
  messages: [{ role: 'user', content: prompt }],
  userId: user.id,
  feature: 'chat',
  plan: user.plan,
})

From there the loop that burned you tonight fires an alert the moment a user runs unusual token volume, and the caps you set block or downgrade an outlier automatically. You can watch it run on seeded data first, no signup, at the live demo. And when you are ready to go deeper, the complete guide to AI cost and margin management lays out the whole system.

FAQ

My API bill is too high. What should I do first?

Do not start deleting features at random. Run a fast triage instead. Pull your provider usage or your own logs and answer three questions: which model is being called the most, is anything looping or retrying, and is one user or one feature carrying most of the cost. Nine times out of ten the answer is obvious once you sort by cost, and the fix is small.

How do I find what is driving my API bill without a monitoring tool?

You do not need a dashboard tonight. Export your raw request logs, put them in a spreadsheet or a quick script, and sort by cost or by total tokens. Then group the top rows by model, by user id, and by endpoint. The outlier almost always jumps out: one model, one user, or one feature sitting at the top of the list.

What are the fastest ways to bring an API bill down right now?

Three moves. Switch the offending feature to a cheaper model if the task does not need the expensive one. Add a hard spending cap so no single user or key can run past a dollar limit. And kill any obvious bug, like a retry with no backoff or a call with no output token limit. Those three cover most emergencies.

How do I stop this from happening again?

You got surprised because your cost was one big number with no breakdown. Fix the visibility, not just this bill. Track cost per user and per feature in real time, set caps before launch instead of after, and get an alert the moment someone spikes. That way the next spike is a notification, not a heart attack at invoice time.

Is a high API bill always a bug?

Not always. Sometimes it is a real bug like a loop or a retry storm, and that is the best case because you can just fix it. But often it is structural: you are on an expensive model for a simple task, you have no output limit, or a few power users are using the product exactly as intended and the cost simply followed them. Triage tells you which one you are looking at.

Keep reading

Stop guessing at the number

Tonight was a scramble because you were staring at a total with no story behind it. It does not have to be like that next month.

Weckr gives you cost and margin per user in real time, an alert when someone spikes, and a cap so no single user can run away with your bill. Wire it into your existing client in a couple of lines, or just see it running first.

See the dashboard with real data, no signup needed.

Try the demo →