How a Forgotten Claude Loop Command Burned $6,000 Overnight

Last week, I woke up to an email that immediately made my stomach drop. The message said my Claude usage limit had been exhausted. At first, I assumed there had to be a mistake. I had not launched a major experiment, generated thousands of pages of content, or intentionally run any unusually heavy workload. From my perspective, nothing extraordinary had happened.

But after reviewing the local session logs, the cause became clear. A single unattended /loop command, combined with long-lived Claude sessions, had quietly consumed a massive amount of usage while I was away.

The command had been set the night before to check my open pull requests every 30 minutes. I forgot about it. Over roughly 26 hours, it ran 46 times. Some of those runs used claude-opus-4-7, and another long analytics session had also been left open. Together, these sessions burned through approximately $6,000 before I noticed what had happened.

The most frustrating part was that the Anthropic usage dashboard did not clearly show the full spike when I checked it manually. The dashboard appeared to show only a fraction of the actual cost at the time. Because usage reporting can lag, the dashboard was not useful as a real-time budget warning system. By the time the limit email arrived, the money had already been spent.

This experience exposed an important problem that many AI developers, engineers, and power users may underestimate: unattended AI loops can become extremely expensive when they run inside long conversations with large context histories.

The Hidden Cost Behind Long Claude Sessions

The most important detail is that every Claude API call does not only send the latest user message. It sends the conversation history as context. That means the first turn in a session may include only a few hundred or a few thousand tokens, but later turns can become much larger.

In my case, by the time the loop had been running for many hours, the conversation had grown to hundreds of thousands of tokens. Around hour 20, the session had reached approximately 800,000 tokens. At that point, each new loop iteration was not simply checking a pull request. It was also processing a huge accumulated conversation history.

This is where the cost became dangerous.

The actual pull request checks were not the expensive part. The expensive part was repeatedly sending and caching a large, growing conversation history. Each loop iteration added more output to the session, which made the next iteration even larger. This created a compounding cost problem.

A small automated task became expensive because it was attached to a large context window.

Why Prompt Caching Did Not Save the Cost

Prompt caching is designed to reduce costs when the same conversation history or prompt content is reused. In simple terms, if the model has recently seen the same context, the system can serve part of that prompt from cache at a discount instead of charging the full input rate again.

That sounds helpful, and in many cases it is. But prompt caching has an important limitation: cache entries expire after a period of inactivity. In this case, the relevant cache window was around five minutes. Earlier, the window had been longer, but with a shorter cache lifetime, a 30-minute loop interval becomes costly.

The pattern looked like this:

A loop iteration runs.

The conversation history is cached.

Thirty minutes pass.

The cache expires.

The loop runs again.

The entire conversation must be written back into cache.

The next iteration is even larger because more content has been added.

This means a /loop 30m command can repeatedly miss the cache window. Instead of benefiting from discounted cached reads, each iteration may pay the expensive cache write cost again. When the conversation history is small, this may not seem dramatic. But once the session grows to hundreds of thousands of tokens, the cost can rise quickly.

This was the core issue: the loop was not expensive because checking pull requests is complicated. It was expensive because every automated check carried the weight of a growing conversation history.

The Dashboard Problem: Usage Reporting Is Not Always Real-Time

Another lesson from this incident is that the usage dashboard should not be treated as a real-time budget monitor. When I checked the dashboard manually, it did not show the full extent of the usage. It appeared delayed.

That delay matters. If a dashboard lags by hours or days, it cannot protect you from runaway automation. By the time the numbers show up clearly, the damage may already be done.

For developers running AI agents, scheduled tasks, loops, or background workflows, relying only on the provider dashboard is risky. The limit notification email may be the first real warning, and that is not enough if the system has already spent thousands of dollars.

A better approach is to set external safeguards, shorter task limits, local monitoring, and strict stop conditions before running unattended AI workflows.

What I Would Do Differently

The biggest mistake was leaving an open-ended loop running without a clear stop condition. A better version of the command would not simply say:

/loop 30m check my PRs

A safer version would include a limit:

/loop 30m check my PRs — stop when all are merged or after 3 hours

That small difference matters. An automated AI task should always know when to stop. Without a stop condition, even a harmless check can become expensive if it continues running overnight or across multiple sessions.

The second change I would make is model selection. Opus is powerful, but it is also significantly more expensive than Sonnet. For unattended polling tasks such as checking pull requests, summarizing status, or watching for simple updates, Sonnet is usually enough. Opus should be reserved for situations where I am actively present and where the quality difference truly matters.

The third change is session management. Long-lived sessions are not always cheaper. Keeping one massive conversation alive for automated tasks can actually make costs worse, especially when the loop interval is longer than the prompt cache lifetime. For simple recurring tasks, starting a fresh session may be cheaper than continuing inside a huge existing conversation.

The fourth lesson is that max_turns should not be misunderstood. It limits the tool-call chain inside one iteration. It does not limit how many times the loop itself fires. If a loop is scheduled every 30 minutes, max_turns will not prevent the loop from continuing over many hours or days. A separate stop condition is still necessary.

Why Long-Lived AI Automation Needs Cost Controls

This incident is not only about Claude. It is a broader warning about AI automation. As developers increasingly use AI tools for coding, monitoring, pull request reviews, analytics, debugging, and scheduled checks, hidden token costs can become a serious operational risk.

AI systems feel conversational, but billing is still based on tokens, context, cache behavior, and model pricing. A task that looks small in plain English may become expensive if it repeatedly runs inside a large context window.

The danger increases when several conditions happen at the same time:

The task runs unattended.

The loop has no stop condition.

The session history is large.

The interval exceeds the cache expiration window.

The model is expensive.

The dashboard is delayed.

Multiple sessions run in parallel.

That combination can turn a simple automation into a costly mistake.

Practical Solutions to Prevent AI Billing Surprises

The first solution is to always add explicit limits to loops. Every recurring AI command should include a stop rule based on time, number of runs, or task completion.

The second solution is to use cheaper models for routine automation. If the task is repetitive and does not require deep reasoning, use a lower-cost model.

The third solution is to avoid running scheduled tasks inside large, long-running conversations. Use fresh sessions for small automation jobs whenever possible.

The fourth solution is to track cost locally. Do not depend only on provider dashboards. Add your own logging for token counts, model usage, session size, and loop frequency.

The fifth solution is to prefer scripts, hooks, or event-based automation when possible. A traditional script may be safer and more predictable than an AI loop for simple polling tasks. In corporate environments where third-party integrations or MCPs are blocked for security reasons, local scripts may still be the better option.

The sixth solution is to treat prompt caching as a cost optimization, not a guarantee. Cache windows can change, expire, or fail to apply depending on timing and session structure.

Final Takeaway

The real lesson from this experience is not that Claude is bad, or that AI loops should never be used. The lesson is that AI automation needs the same discipline as cloud infrastructure. Nobody would leave an uncapped cloud job running without monitoring, budget limits, or shutdown rules. AI agents and loops deserve the same caution.

A forgotten /loop command may look harmless, but if it runs inside a large conversation, misses the cache window, uses an expensive model, and continues unattended, the cost can grow quickly.

For anyone using Claude, ChatGPT, or other AI coding assistants in professional workflows, the safest approach is simple: use stop conditions, choose the right model, avoid unnecessary long sessions, monitor token usage, and never assume the dashboard will warn you in time.

AI tools can save hours of work, but without cost controls, they can also create expensive surprises overnight.