Runaway AI Spend: Common Patterns From Real Postmortems

'Our AI bill was 12x normal this month' is a common enough story that the causes have started to repeat. Almost every runaway-spend postmortem traces back to one of a small set of patterns — which is good news, because it means most of them are preventable with a guard that costs a few minutes to set up.

Pattern 1: The retry loop with no backoff limit

A transient error triggers a retry. The retry hits the same transient condition. It retries again. Without a maximum retry count or exponential backoff that eventually gives up, a single failing request can multiply into hundreds of billed calls before anyone notices the error rate spike. The fix is mechanical: every retry path needs a hard cap, full stop, no exceptions for 'this one should always succeed eventually.'

Pattern 2: The test script that pointed at a production key

A developer testing a prompt change locally, running a loop over a few hundred test cases, using the production API key because it was the one already in their .env file. Multiply a few hundred test iterations by a model that's more expensive than intended, and a routine testing session becomes a four-figure surprise. Separate keys for development and production — with visibly different names, not just different values — make this mistake much harder to make by accident.

Pattern 3: The agent stuck reasoning in a circle

Covered in more depth elsewhere, but worth repeating here: an agent that keeps re-verifying its own output, or gets stuck alternating between two tool calls without making progress, will keep running — and keep billing — until it hits a provider-side limit or someone kills the process manually. A per-run step cap is the fix, and it needs to exist before the agent ships, not after the first incident.

Pattern 4: Context that grows unbounded across a session

A chat feature that appends every message to history and resends the whole thing on every turn looks fine for the first twenty messages and then starts costing meaningfully more per message as the conversation grows — often without anyone noticing, because the growth is gradual rather than a sudden spike. Long-running sessions need either a summarization step or a hard context-length cap; otherwise cost per message quietly climbs the entire time a user stays engaged.

What all four patterns have in common

None of these are pricing problems — they're missing-guardrail problems. The model didn't get more expensive; something removed the ceiling that normally keeps a single request, session, or run bounded. That's why the fix in every case above is a hard limit, not a cheaper model: a retry cap, a separate key, a step count, a context ceiling. Cheaper models still hit the same unbounded loop, just at a lower price per iteration — the bill still climbs, just more slowly.

The postmortem question worth asking upfront

For every AI-powered feature before it ships, it's worth asking one question: what's the actual ceiling on how much a single user action could cost, in the worst case? If the honest answer is 'unbounded,' that's the gap — not a hypothetical one, but the exact shape of the next incident. A spend alert catches it after the fact; a hard cap on retries, steps, and context prevents it from happening at all.