一次無人值守 LLM 循環一夜耗用 Claude 訂閲方案 13 個百分點

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.

The limits are shared with the chat app

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:

• Switching models only helps when the message names a model (for example an Opus-specific limit). For the generic "all models" message, switching does nothing.
• Your options are to wait, turn on usage credits, or auto-continue after the reset. Auto-continue is configured with /rate-limit-options on v2.1.234 or newer, and organizations use the autoContinueAtUsageLimit setting.

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.

Read /usage the right way

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:

• Attribution: share of usage by skill, subagent, plugin, and MCP server.
• Behavior flags: things like long contexts and cache misses.
• Loops: runs and tokens per scheduled task (v2.1.242 or newer).

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.

What the overnight incident looked like

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.

Put three caps in the loop

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"

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.

A checklist before any unattended run

1. Write down the expected usage before you start.
2. Have a human approve that estimate.
3. Set at least two caps and test them.
4. On exit, log the stop reason and the usage.
5. Once a month, audit every cron job, scheduler entry, and background runner.

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.