# The bill spiked after launch — usage-billing incidents, and how to cap them > Why cloud and AI API costs run away after you launch an app built with AI, explained for non-engineers. The five patterns that spike, how to set caps on Vercel, Supabase and AI APIs, and how to add rate limiting. - Published: 2026-08-06 - Author: 友田 陽大 - Tags: バイブコーディング, 個人開発, Vercel, インフラ, AI - URL: https://tomodahinata.com/en/blog/ai-app-cloud-bill-spike-prevention - Category: Running the app you built with AI - Pillar guide: https://tomodahinata.com/en/blog/ai-app-pre-launch-guide-for-non-engineers ## Key points - Usage-based billing has no ceiling unless you set one. Unexpected traffic, an accidental loop or bot crawling can produce very large bills even for a solo project. - Five spike patterns: AI API calls, image and video conversion, infinite loops, bot crawling, and the automatic switch to paid billing once a free tier is exceeded. - AI APIs are the most dangerous — high unit cost, and more expensive the longer the input. A per-key spending limit is mandatory. - Rate limiting in the app is needed separately from spending caps. A cap sets the ceiling on damage; rate limiting stops it happening. - Billing alerts only notify after the fact. What you actually want is a hard spending cap, wherever a service offers one. --- Security incidents happen when someone attacks you. This one **happens with nobody attacking at all**. Your own bug is sufficient. And you usually find out when the invoice arrives. --- ## 1. Why it spikes — usage billing has no ceiling Old shared hosting was "1,000 yen a month, use as much as you like." Overuse just made the site slow; the bill didn't change. Modern cloud services are the opposite. **You are billed for what you use, and there is no ceiling unless you set one.** Under load nothing slows down — it scales, and you are billed accordingly. That is a benefit by design: a sudden traffic spike doesn't take your service down. The catch, and the subject of this article, is that **"more traffic" isn't always legitimate traffic**. --- ## 2. The five patterns that spike ### Pattern 1: AI API calls **The most dangerous.** OpenAI and Anthropic APIs have a per-request unit cost orders of magnitude above other cloud services, and **it grows with the length of the input**. Dangerous implementations AI tends to write: - **Resending the whole conversation history every time** — each call gets more expensive as the conversation goes on - **No limit on the length of text a user can submit** — one long paste is expensive on its own - **No cap on retries** — a persistent error repeats the same call - **Usable without logging in** — anyone can call it, without limit The last one bites hardest. Opening an AI feature without login "so people can try it" creates **a window through which anyone can use AI on your money**. ### Pattern 2: image and video conversion Image optimisation, thumbnail generation, video encoding. These are heavy, and many services bill per conversion or by data transfer. The problem is **the same image being converted repeatedly**. Without caching — reusing what was already produced — a conversion runs every time the page renders. ### Pattern 3: infinite loops The quietest and fastest way to spike. ``` [what happens] - process A calls process B, and process B calls process A - a process triggered by a data update updates data itself - a process that retries on failure keeps failing and retrying ``` The third is especially common. Ask an AI to "retry if an error occurs" and, unless you specify a limit, it may write code that **retries forever**. Loops are invisible to you. They spin quietly on the server. ### Pattern 4: bot crawling A published site attracts search-engine and AI crawlers. That is normal. But if you have **many pages that contain heavy processing**, crawlers walk all of them. - Search-result pages generated endlessly (`?page=1` through `?page=99999`) - A calendar feature generating infinite future dates - Filter combinations exploding the URL space These produce "infinitely many URLs with effectively the same content," and crawlers dutifully visit them all. ### Pattern 5: the moment you exceed a free tier Finally, an assumption problem. "I'm on the free plan, so no bill can arrive" — **this differs per service**. - Exceed the free tier and **the service stops** → no bill (but the service is down) - Exceed the free tier and **billing switches to usage-based automatically** → a bill arrives Check which behaviour applies before you launch. Some services move to the second the moment you register a card. --- ## 3. Countermeasure 1: set a hard spending cap (highest priority) This comes first. ### Why "billing alerts" aren't enough Many people set a billing alert and feel safe. But an alert **only tells you that you overspent — it doesn't stop anything**. Suppose an infinite loop starts at 2am. The alert arrives at 2:30. You notice at 7am. That four and a half hours is billed in full. What you want is not a notification but a **hard spending cap**. ### Where to set it, per service **Vercel** — the Spend Management feature lets you configure what happens when a monetary threshold is reached. Beyond notification, you can choose to **pause deployments**. Check the official documentation for which plans and options apply. **AI APIs (OpenAI / Anthropic and others)** — the dashboard lets you set **per-key and per-organisation usage limits**. **Set these without exception.** Specify an amount and it stops there. Separating development and production keys and capping each is safer still. **Supabase** — check the per-plan limits and how overage is billed. If a spend cap setting exists, enable it. **Cloud generally (AWS / GCP)** — budget alerts are configurable, but automatic shutdown is not included by default. Automating a stop requires additional machinery. ### Two things to confirm For every service, confirm: 1. **What happens when the cap is reached** — does it stop, or keep billing 2. **If it stops, how do you recover** — the procedure at 2am A "stop" setting means, by definition, "the service goes down." For a solo project, **an unbounded bill is almost always worse than downtime** — but that is a choice you should make yourself. --- ## 4. Countermeasure 2: add rate limiting Where a spending cap sets **the ceiling on damage**, rate limiting **stops the volume happening at all**. **Rate limiting** restricts how many requests one person can make in a period — "10 per minute per person," for instance. With only a cap, the service stops. With only rate limiting, there is no ceiling. **Both together** give you a service that neither goes down nor runs up a bill. ### Where to apply it Not everywhere. **Only where the cost is high** is enough. - Anything calling an AI API ← highest priority - Image and video conversion - Anything calling a paid external API - Sending email - Heavy aggregation or search ### Requiring login alone helps Simply putting AI features behind a login materially reduces indiscriminate abuse. The wish to "open it up free so people can try it" is understandable — but **if you open it, pair it with a usage limit**. --- ## 5. Countermeasure 3: remove the causes in advance Caps and rate limiting exist so that an incident doesn't hurt. Some prevention is cheap to add too. **Cap retries.** Decide "three times, with a delay." Never retry forever. **Limit what you send to an AI.** Set a character limit, and send only the last N messages of history. **Cache conversion results.** Don't reconvert the same image every time. **Narrow what crawlers see.** Use `robots.txt` to exclude search-result pages and filter-combination pages. Not generating infinitely many URLs with effectively identical content is a design question too. **Set timeouts.** Don't wait indefinitely on an external service — you are billed while waiting. --- ## 6. The instruction to paste into your AI tool ```text List every usage-billed service this app depends on and produce a table with, for each one: (1) What is billed (request count, data transfer, execution time, tokens) (2) A concrete scenario in which cost spikes unexpectedly (3) The caps and alerts available in its dashboard Then read the code and check for these dangerous implementations. - Retries with no upper limit - No limit on the length of input sent to an AI API - Sending the entire conversation history every time - Conversions that run every time because nothing is cached - Expensive operations callable without logging in - External calls with no timeout - Places where processes may call each other (the seed of an infinite loop) Finally, implement rate limiting on the highest-cost endpoints. Explain in plain language which endpoints you limited, to what values, and why. I cannot read code. ``` --- ## 7. A checklist for right after launch - [ ] Listed every service in use, free tiers included - [ ] Confirmed, per service, what happens when the free tier is exceeded (stop or bill) - [ ] Set a hard spending cap wherever one is available - [ ] Set a per-key spending limit on AI APIs - [ ] Set billing alerts (alongside caps, not instead of them) - [ ] Added rate limiting to high-cost operations - [ ] Put AI features behind a login, or added a usage limit - [ ] Capped retries - [ ] Set timeouts on external calls - [ ] Excluded infinitely-generated URLs in `robots.txt` - [ ] **Look at the billing page once a day for the first week after launch** ← the most effective item That last one matters more than it looks. A spike almost always begins as a small anomaly. Looking daily means noticing on day one. --- ## Summary - Usage billing has no ceiling. It spikes from your own bug, with nobody attacking - Five patterns: AI APIs, image and video conversion, infinite loops, bot crawling, the automatic switch after a free tier - AI APIs are the most dangerous — high unit cost, more expensive with longer input. Per-key caps are mandatory - Billing alerts are after-the-fact notifications. Use a hard spending cap where available - Rate limiting is needed separately. A cap is the ceiling on damage; rate limiting stops it happening - Look at the billing page daily for the first week. Spikes start small This is a "right after launch" item rather than a "before launch" one, but deferring it comes back as a painful expense. Once [the four pre-launch items](/blog/ai-app-pre-launch-guide-for-non-engineers) are closed, this is next.