The 7 Failure Modes Behind Runaway AI Bills—and the Circuit Breakers for Each

An AI bill does not need a dramatic breach to become expensive. A valid key, a valid request, and a small missing guardrail are enough. The useful response is not simply "set a budget." It is to give every failure mode a limit, a signal, and a stop mechanism.

Retries with no ceiling

A failed call repeats until it succeeds—or until someone notices. Limit attempts per job, add exponential backoff with jitter, make work idempotent, and stop retrying errors that require human action. Alert on retry count before the bill moves.

Duplicate background work

Queue replay, lost acknowledgements, duplicate schedules, and deploy races can run a healthy task twice. Use durable job IDs, completion records, concurrency limits, and a cost ceiling per queue. Track work completed beside requests made; a 100% success rate can still mean the same work ran twice.

Agents that never reach a terminal state

Give every run a maximum number of steps, tool calls, wall-clock time, token budget, and dollar budget. Make the agent record whether each step changed state. If the same tool call repeats without progress, stop and surface a clear terminal reason: blocked, timed out, step limit, or budget exhausted.

Context that grows on every turn

Long transcripts, repeated retrieval payloads, and duplicate tool output make a looping agent progressively more expensive. Cap retrieval size, summarize deliberately, cache deterministic work, and measure cost per completed task—not merely monthly spend. The question is: which component gets more expensive every time the workflow loops?

Expensive provider fallback

Fallbacks protect availability, but a silent switch to a premium model, a non-cached path, or a different region can change unit economics while every request still succeeds. Declare permitted fallback routes by feature, log the chosen route and reason, and alert when average cost per successful task changes materially.

A leaked or shared key

Production keys in logs, browser bundles, repositories, or broad integrations turn a cost event into a security event. Isolate keys by application and environment, use least privilege, set individual ceilings, and rehearse revocation. The highest-spending key should never be the least observable one. Read more about how ModelBrake protects credentials.

A dashboard with no response path

Dashboards are useful for diagnosis; they are not automatically incident controls. OpenAI's project budgets are soft thresholds—requests continue after an alert—while configured hard spend limits can stop affected requests. OpenAI's documentation Be explicit about which controls are notification-only and which actually interrupt traffic.

For every provider, identify who gets paged, who can stop the work, and what latency to expect from cost data. AWS Cost Explorer is excellent for analysis but its current-month data is typically prepared on an approximately daily cadence, so it is not minute-by-minute incident telemetry. AWS documentation

The minimum viable circuit breaker

For each production workload, document five fields:

1. Maximum cost per task or run.
2. Maximum retries, steps, and elapsed time.
3. The owner and delivery channel for an anomaly alert.
4. The fastest authorized way to stop further spending.
5. The last date this control was tested.

Native hard caps, careful application controls, and request-level observability all have a role. ModelBrake adds an independent provider-spend signal without placing a proxy in the request path. It can alert on abnormal spend or a per-key ceiling, and can use a separately scoped, opt-in credential for revocation. It is a backstop, not an excuse to omit safe retries and termination limits.

Use the spend-risk audit to score your current controls.