Agent Retry Loop Cost Patterns
Retry loops are the most common runaway pattern in the incident database — one failure multiplied. Here's the shape, the cost, and the fix.
The pattern
An agent retries a failed call in a tight loop — the $12,400 founder story is 40 retries of one purchase at 2 AM.
Each retry re-bills the same operation: rate, tokens, or purchase — multiplied by attempts.
The cost shape
Cost = single-operation cost × retries. A 40-retry loop is 40× the base cost.
Loop costs compound across subagents: fan-out × retries.
The fix
A velocity limit caps transactions per window — retry #11 (or wherever you set it) is BLOCKED before it bills.
Time-of-day rules catch unattended overnight loops.
At a glance
| Pattern | Multiplier | Rule that stops it |
|---|---|---|
| Tight retry loop | ×N retries | Velocity limit |
| Subagent fan-out | ×subagents | Shared daily cap |
| Overnight loop | Unreviewed | Time-of-day rule |
| Unknown vendor retry | ×N attempts | Merchant allowlist |
FAQ
How common are retry loops?
They're the pattern behind several incidents in the public database — the most common runaway shape.
What's the fastest fix?
A velocity limit: it kills the loop at the cap, usually within seconds of it starting.
Does a rate limit on the API side help?
Provider rate limits throttle requests; they don't stop the loop from trying. A velocity rule stops the loop at the source.
Related
Stop the next $12,400 night.
One API call (or MCP tool) in front of every agent transaction — APPROVED, BLOCKED, or FLAGGED, deterministic, ~5 ms, fully logged.
See plans — from $99/mo Try a live check