Overnight, an AI Agent Burned Through $1000: What's Truly Scary Isn't the Model Cost, But "Losing Control of the Agent"

Last night, I thought I just asked Claude to do a code review.

The task was simple:

Check if the code completes the task and supports OpenSpec rule transitions.

But the next day, the bill blew up.

What I saw wasn't just one or two failed requests, but a row of glaring errors:

Agent stalled: no progress for 600s
stream watchdog did not recover
Too many pending requests
Concurrency limit exceeded
DAILY_LIMIT_EXCEEDED

My first reaction was naturally: Is there a bug in the model? Did cc-switch miscalculate? Did Claude go crazy?

After checking the logs, the conclusion was scarier:

It wasn't that the model suddenly went crazy, but that the Agent workflow had entered recursive derivation.

Incident Scene

The local cc-switch database showed that the main consumption was concentrated in the same Claude session:

session_id: 6d2296bc-65e7-42d9-a92a-6358bbb56a42
project: /Users/lininn/work/openflow
time: 2026-06-15 evening to 2026-06-16 morning
model: gpt-5.5
successful billing requests: 10244
input tokens: ~593M
output tokens: ~5.17M
cache read: ~532M
cc-switch estimated cost: ~$3386.97

I originally thought I had only spent $1000.

But the local records told me: if estimated based on cc-switch's price table, the actual risk exposure could exceed $3000.

More critically, under this session:

subagent .jsonl: 10146
subagent .meta.json: 10146

That means, this wasn't "launching a few Agents to do reviews."

This was tens of thousands of sub-agents being repeatedly created in the same task.

The Real Explosion Point: Agent Spawning Agent

The root cause of this incident was not a certain interface 429, nor a watchdog timeout.

429 and watchdog were just symptoms.

The real chain was:

1. I asked Claude to check the code.
2. Claude triggered the code-review skill.
3. The code-review skill required launching 7 types of independent review agents: diff scan, removed behavior, cross-file trace, reuse, simplification, efficiency, altitude.
4. After the sub-agents started, they also loaded the skill list.
5. Some sub-agents did not directly complete their small task, but instead triggered code-review again.
6. The new code-review then continued to launch 7 types of Agents.
7. Thus it became:

Main Agent
  -> 7 review agents
       -> each triggers code-review again
            -> launch more agents
                 -> continue deriving

This is a typical subagent recursion.

It looks like "intelligent collaboration," but in essence, it's "exponential task propagation without circuit breakers."

Why Did the Errors Appear at the End?

The error in the screenshot was:

Agent stalled: no progress for 600s

Many people would think: Oh, the Agent stalled, so it didn't spend much money.

Quite the opposite.

By the time it stalled, the money had already been spent.

Before the watchdog determined 600 seconds of no output, a large number of requests had already returned successfully and been billed. The subsequent 429, daily limit, context window exceeded—those were just the aftereffects of the system being overwhelmed.

Failed requests are usually not charged.

What actually burned the money were those 10244 successful requests before that.

The Biggest Lesson for Me

In the past, we worried about:

• The model being too expensive
• The prompt being too long
• The output being too much
• The context being too large

But in the Agent era, the real danger is:

A seemingly reasonable workflow can automatically replicate itself while you sleep.

Especially these scenarios are very dangerous:

• Code review automatically spawning multiple Agents
• Sub-agents can continue calling Skills
• Sub-agents can continue calling Agents
• No budget ceiling
• No concurrency ceiling
• Continuing to input "continue" after errors
• High-cost models as the default route

Combining these conditions leads to a billing incident.

How to Fix It?

I will fix it in three layers.

First layer: Prohibit sub-agents from spawning sub-agents.

Add a hard rule at the very beginning of the code-review skill:

If this skill is running inside a Claude Agent/subagent,
do not invoke Skill, Agent, Task, code-review, simplify, review,
or any workflow that spawns agents.

In subagent context, complete the assigned review directly
with local read/search tools only, return the requested JSON, and stop.

Also, add in all sub-agent prompts:

Do not invoke Skill tool.
Do not invoke Agent tool.
Do not run code-review, simplify, review, or any workflow.
Complete this exact task directly.

Second layer: Add fuses to cc-switch.

Suggestions:

max_retries: reduce from 6 to 1 or 2
high-cost model daily limit: $20-50
Claude concurrency limit: 2-4
gpt-5.5 not as default review model

An Agent system without budget limits is essentially running naked.

Third layer: Change usage habits.

From now on, when seeing these signals, stop immediately:

Too many pending requests
Concurrency limit exceeded
DAILY_LIMIT_EXCEEDED
Agent stalled
response exceeded 64000 output token maximum
use SendMessage to continue this agent

Do not input "continue" in the original session.

The correct approach is to open a new session and clearly say:

Do not use Agent.
Do not use code-review skill.
Summarize current state from logs only.

Finally

This incident gave me a new understanding:

The risk of an Agent is not that it can't do work.

Quite the opposite.

The risk is that it is too good at working, and it has no boundaries.

In the past, when we wrote programs, we feared infinite loops.

Now, when we use AI Agents, the biggest fear is:

An infinite loop that spends money.

The stronger the AI tools, the more engineering guardrails are needed.

It's not about "using less AI," but about adding to AI:

• Recursion limits
• Concurrency limits
• Budget limits
• Failure circuit breakers
• Clear sub-agent responsibility boundaries

Otherwise, the next time you think you just ran a code review.

When you wake up, the bill will have already given you a thorough debrief.