One Unattended Claude Loop Burned 13 Points of Plan Usage

Posted on Oct 19 • Originally published at my-blog.org

An LLM loop with no stop condition ran overnight on my Claude subscription and burned 13 percentage points of plan usage. The problem was not the price per token. Nothing in the code could end the loop, and nobody was watching. This post covers how Claude plan limits actually work, how to read your usage, and the three caps I now put in every unattended loop.

Pro and Max subscriptions include Claude Code, and the limits come as two meters: a 5-hour session limit and a 7-day weekly limit. According to Anthropic's help pages, Claude and Claude Code draw on the same pool. Whatever you spend in the chat app shrinks what Claude Code can use, and the reverse is also true.

That sharing is why an "unexpectedly high" bar in the morning is hard to explain from a terminal alone. If part of the usage came from the app, it will not show up in the terminal breakdown.

Two details are easy to get wrong when you hit a limit:

Usage credits have a side effect: the prompt cache lifetime drops from 1 hour (60 minutes) to 5 minutes, so the same working habits cost more. Also, the monthly API credit included with Max cannot be used to extend Claude Code limits.

Type /usage inside Claude Code. As a subscriber, ignore the Session block and look at the plan usage bars and the breakdown beneath them. The breakdown has three parts:

Press d for the last 24 hours and w for the last 7 days. One caveat: these numbers come from local records on the machine you are on. Other devices and claude.ai app usage are missing.

On 2026-08-01 an LLM loop ran overnight without anyone approving it, and plan usage went up by 13 percentage points. The 13 is a reading from the meter, a before/after change. I deliberately did not convert it to a token count, because any conversion factor would be an estimate. (The full incident write-up has the details.)

The root cause was that the loop could not stop. If a person had been watching, it would have been killed within minutes. Switching it to a cheaper model would not have fixed anything either, because the missing exit condition would still be there, just burning more slowly.

Pick at least two of these and enforce them in code: a consecutive-failure cap, a total-call cap, and a wall-clock cap. The values from my own example are 3 consecutive failures, 200 calls, and 3 hours.

import time MAX_FAILS, MAX_CALLS, MAX_SECONDS = 3, 200, 3 * 3600 def run ( task, step ): start, calls, fails = time. time (), 0, 0 while not task. done (): if fails >= MAX_FAILS: return " stopped: 3 consecutive failures " if calls >= MAX_CALLS: return " stopped: 200 calls " if time. time () - start >= MAX_SECONDS: return " stopped: 3 hours " calls += 1 try: step ( task ) fails = 0 except Exception: fails += 1 return " done " Enter fullscreen mode Exit fullscreen mode The check runs before every iteration, and the function returns the reason it stopped so you can log it. Test the guards first: feed step a function that always raises, and confirm you get the failure message after exactly 3 attempts.

One trap: a 429 cooldown is not a cap. It is a resume mechanism, because it revives the loop in every new limit window. It lets the loop run forever, politely.

The guard only covers loops you wrote yourself. For Claude Code's own /loop, check the Loops row in /usage and turn it off or lengthen the interval by hand. And because app usage is not in the breakdown, a high morning bar cannot always be attributed from the screen alone.

The full write-up, including the FAQ on limits, credits, and model switching, is in the original post on my-blog.org.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.