A forgotten /loop and a four-figure API bill: what repeated agent runs really cost
TL;DR
A story circulating in the community: a developer ran /loop to check a PR every 30 minutes, forgot it, and woke up to an API bill of several thousand dollars. Why: each iteration resends the entire conversation, and because the default cache only lives 5 minutes, every iteration paid full price for that context.
A story going around the community: a developer ran /loop to check PRs every 30 minutes, forgot to turn it off, and the next morning the API bill was several thousand dollars. Whatever the details of each case, the mechanism behind it is real and worth understanding, because it applies to every agent that runs in a loop. This post explains why cost balloons, how prompt cache pricing works, and how to stop and prevent it.
Why does it cost so much?
- Every model call resends the whole context (system prompt, history, tool results). The longer the context, the more expensive each turn.
- Prompt caching makes repeated context much cheaper, but its default lifetime (TTL) is only 5 minutes; there's a 1-hour option at a higher write price.
- Looping every 30 minutes → the cache has expired → each iteration rewrites the cache from scratch at the write price, never getting the cheap read price.
- Each iteration also appends new results to the history → the context keeps growing, so each turn costs more than the last.
How is prompt caching priced?
| Type | Versus base input price |
|---|---|
| 5-minute cache write | 1.25× |
| 1-hour cache write | 2× |
| Cache read | 0.1× (lower, about 0.05×, on some newer models) |
There are also conditions: the cached part must reach a minimum length (about 512 tokens on newer models) and each request can have at most 4 cache breakpoints. Caching only pays off when you call again within its lifetime; a loop sparser than the TTL gets almost no benefit.
An illustrative calculation
Suppose a 100,000-token context. Calling every 3 minutes (within the TTL), each turn reads the cache at 0.1× the input price, about 10,000 "equivalent" tokens. Calling every 30 minutes, each turn rewrites 100,000 tokens at 1.25×, about 125,000 equivalent tokens, more than 12 times as much. Multiply by 48 turns a day and a growing context, and it's clear where the bill comes from.
How to stop and prevent it
- Know how to stop it: a fixed-interval loop (
/loop 30m …) doesn't stop with Esc; you have to ask Claude to cancel it. Recurring tasks expire automatically after 7 days. - Use the right tool: long-running work belongs in cloud/desktop scheduled tasks or GitHub Actions with a fresh session each time, not one long session looping forever.
- Set spend limits and budget alerts in the API console; watch usage daily.
- Keep context lean:
/clearor open a new session for recurring work; the looped prompt should be short and specific. - Match the model to the task: checking PR status doesn't need the most expensive model.
Checklist before turning on a loop
- Do I really need to poll, or is there a webhook/event to trigger it?
- How does the interval compare with the cache TTL?
- Is there a limit on iterations, time or budget?
- Who will turn it off, and how?
- Does each iteration start from a clean context?
How to apply it
- Dev: set limits and alerts before running anything that loops overnight.
- Tech Lead: establish a convention: recurring work runs as scheduled tasks/CI with fresh sessions, not in long interactive sessions.
- PM: add AI costs to weekly budget tracking; a surprise bill is often a sign of a forgotten loop.