The email nobody wants to get from a service like OpenAI or Stripe or a cloud provider is the one with a number in it that does not match your traffic. You have fifty users. The bill says you owe four hundred dollars. Or four thousand. And you cannot figure out where it came from.
I see this almost every week, and it has a name: AI app runaway API costs. A founder ships something with Cursor, Replit, Lovable, or Bolt, it works beautifully in the demo, and then a few weeks later the connected services quietly drain money in the background. No alert. No warning. Just a charge that lands when the billing cycle closes.
Here is the good news. This is one of the most preventable problems in the entire AI-built app world. In this post I will explain exactly why these apps leak money through API calls, how to spot it before the bill arrives, and the specific guardrails you need in place so it never happens to you again.
What "runaway API costs" actually means
Your app almost certainly talks to outside services to do its job. When it asks one of those services to do something, that request is called an API call (think of it as your app placing an order with another company's system). Many of those companies charge you per order.
That is completely normal. The problem is not that you pay for API calls. The problem is paying for calls you did not need to make.
Runaway API costs happen when your app makes far more of these calls than the work actually requires, and nothing in the code stops it. The same question gets asked a hundred times when once would do. A loop fires off requests in the background. A single user, or a single bot, hammers an expensive endpoint and nobody set a limit. The meter runs and runs because no one told it when to stop.
Your bill is not a measure of how successful your app is. It is a measure of how disciplined your code is.
That distinction matters. A surprise bill almost never means you suddenly got popular. It means something is calling a paid service over and over for no reason.
Why AI tools generate code that leaks money
This is where my experience with these tools shows. AI builders are not careless on purpose. They optimize for one thing: producing code that works in front of you right now. And in a demo, cost is invisible.
When you ask an AI to "connect this to GPT-4 and summarize the user's notes," it writes code that does exactly that, in the simplest way that runs. It calls the API. It gets an answer. It shows you the answer. Demo done, founder happy.
What it almost never adds, unless you specifically demand it, are the unglamorous parts that control spend:
- Caching. If ten users ask for the same summary, a careful app computes it once and reuses it. AI-built code usually recomputes it ten times and pays ten times.
- Rate limits. A guardrail that says "one user can only make so many requests per minute." Without it, a single person (or a script) can run up your bill at machine speed.
- Spend caps. A hard ceiling that shuts things off before you cross a dollar amount. AI tools never set these for you.
- Retry sanity. When a call fails, naive code sometimes retries it in a tight loop, turning one failed request into thousands.
There is a deeper reason too. The AI does not know your pricing. It does not know that the model you picked costs thirty times more per call than the one right next to it. It does not know that calling an API inside a loop that runs on every page load is going to be expensive at scale. It is writing code that is functionally correct and financially blind.
And here is the trap I watch founders fall into. The bill arrives, they paste it back into the same AI and ask it to "make this cheaper," and the AI confidently rewrites the code with the same blind spots that caused the problem. Asking the tool that built the leak to find the leak is like asking it to grade its own homework. I wrote more about that pattern in the hidden cost of vibe coding debt, because runaway costs are really just one symptom of a bigger issue.
What it looks like in real life
Let me get concrete, because these leaks have very recognizable shapes. If any of these sound familiar, you probably have one.
The call that fires on every render
A lot of AI-built apps put an API call in a spot that runs far more often than anyone intended. A common one: the call lives inside the code that draws the screen, so every time the page redraws (which can be many times per second), it fires again.
In a demo, you load the page once and see one call. In production, that same page might trigger dozens of calls per visit. Multiply by every user, and you have a problem.
// This pattern quietly fires the API on every re-render.
// It looks fine in a demo with one user clicking once.
function Notes() {
const summary = callExpensiveAI(notes) // runs again and again
return <div>{summary}</div>
}
The fix is not complicated for a developer, but you would never spot it from the outside. The app works. It just works expensively.
The expensive default model
AI tools love to reach for the biggest, most capable (and most expensive) model because it gives the best demo answer. For most real tasks you could use a model that costs a fraction as much and nobody would notice the difference. Founders often pay premium prices for work that did not need them.
The missing front door lock
If your app has no rate limiting, anyone (a curious user, a competitor, or an automated bot scanning the internet) can hit your expensive endpoints as fast as they want. This overlaps with security, because the same missing guardrails that leak money also leave you exposed. If you have not had your access controls looked at, your AI-built auth is probably broken too.
The silent background loop
Sometimes the leak is a process that runs on a schedule or in a loop, syncing or checking or refreshing something, and it calls a paid API every cycle. Nobody sees it because it never shows up on a screen. It just runs, day and night, billing you while you sleep.
How to spot it before the bill arrives
You do not need to read code to catch this early. You need to watch the right numbers. Here is what I would do today, even as a non-technical founder.
- Turn on billing alerts everywhere. Every paid service you use (OpenAI, Anthropic, your cloud host, your database, your email sender) lets you set a threshold that emails you when spend crosses it. Set it low. You want to hear about a fifty dollar surprise, not a five thousand dollar one.
- Find the usage dashboard for each service and actually look at it. Most providers show you calls per day and cost per day. Open it. If you have a handful of users but thousands of daily calls, that gap is your leak.
- Do the napkin math. Take your number of active users and roughly how many actions each one takes. If your call count is wildly higher than that, the code is making calls nobody asked for.
- Watch the shape of the graph. Costs that climb smoothly with users are healthy. Costs that spike, or that keep rising when usage is flat, are a code problem, not a growth problem.
- Check whether spend tracks with real activity. If your busiest day and your quietest day cost roughly the same, something is calling the API on a schedule regardless of users. That is a background leak.
These checks take twenty minutes and they move you from "I'll find out when the invoice lands" to "I'll know within a day." That alone is worth doing this afternoon.
The guardrails every AI-built app needs before launch
Now the practical part. These are the specific protections that keep a connected app from bleeding money. Some you can arrange yourself. Some genuinely need a developer, and I will be straight with you about which is which.
1. A hard spend cap
This is the single most important one. Many providers let you set a maximum monthly spend that shuts the service off when reached. It is the difference between a bad day and a catastrophe. Set it. Even if it occasionally inconveniences you, a capped app cannot ruin you.
You can usually do this yourself in the provider's billing settings. Do it before you do anything else.
2. Caching for repeated work
If your app computes the same answer for the same input over and over, it should compute it once and remember it. This is caching, and it is often the biggest single cost saving available. For an AI-built app it can cut spend dramatically because these tools almost never cache anything.
This one needs a developer. It is not hard for someone who does it regularly, but it requires understanding which results are safe to reuse and for how long.
3. Rate limits on every paid endpoint
A rate limit caps how many requests a single user can make in a window of time. It protects you from one person, or one bot, running up your bill at machine speed. It also makes your app more stable under load, which matters when your app starts breaking at scale.
This needs a developer, and it is worth every minute.
4. The right model for the job
Have someone check which model or tier your app is actually calling, and whether a cheaper one would do the same job. I frequently find apps paying top-tier prices for tasks a budget model handles perfectly. Switching can cut costs by huge margins with zero change to the user experience.
5. Sane retry and timeout behavior
When a call fails, the code should wait, retry a sensible number of times, then give up gracefully. What it must not do is retry forever in a tight loop, which turns one hiccup into thousands of billed calls. A developer can confirm this is handled correctly.
6. Alerts that reach you fast
Beyond billing alerts, you want monitoring that tells you when call volume suddenly jumps, not just when money is spent. Catching a spike in real time means you can pull the plug in minutes instead of discovering it weeks later.
What you handle, and what I handle
Here is the honest division of labor. You can set billing alerts, set a spend cap, watch the dashboards, and do the napkin math. Those are yours, and they are genuinely powerful on their own. Do them today and you have already protected yourself from the worst outcome.
The code-level fixes (caching, rate limits, model choices, retry logic) are where a real developer earns their keep, because getting them wrong can break the app or quietly leave the leak in place. This is exactly the kind of work that matters before you start looking for testers or pushing for real traffic, since more users on a leaky app just means a bigger bill.
A surprise invoice feels like a disaster when it lands, but the underlying fix is well understood and fast for someone who knows where to look. If you have built something with AI and you are even slightly nervous about what it is costing you behind the scenes, that nervousness is worth listening to. I review AI-built apps for exactly these leaks every week, find where the money is going, and either plug it or hand you a clear plan. If a quick look at your app would put your mind at ease, let's talk about what it needs.
Cover photo by Kindel Media on Pexels.