Back to Blog

I Burned $100 in One Night on OpenClaw — Here's How to Prevent It

By Percy Kintu · March 5, 2026 · 9 min read

I went to bed at 11 PM on a Tuesday. I had an OpenClaw agent refactoring a mid-sized TypeScript project — roughly 40 files, nothing crazy. I left it running because it was making good progress and I figured it would finish by midnight.

I woke up to a $103.47 charge on my Anthropic dashboard.

The agent had not finished. It had gotten stuck in a loop around 1 AM, repeatedly trying to fix an import that did not exist. It hammered the API with hundreds of retry attempts over 4 hours, each one appending more context. Then it settled into idle heartbeat-polling for the remaining 2 hours. Every single call went through Claude Sonnet with a massive context window.

What exactly happened that night?

Here is the breakdown from my API logs. The session started at 11:12 PM and was still running when I woke up at 7:04 AM — 7 hours and 52 minutes of unattended operation.

Phase 1 (11:12 PM - 1:03 AM): Legitimate work. The agent made real progress on 23 files. This cost about $12.80, which was totally reasonable for two hours of Claude Sonnet refactoring with large context windows.

Phase 2 (1:03 AM - 5:18 AM): The loop. The agent hit a circular dependency it could not resolve. It tried variations of the same fix 214 times over 4 hours. Each attempt appended to the conversation history, so the context window grew from 8,000 tokens to over 120,000 tokens by the end. Early attempts cost ~$0.10 each; late attempts cost ~$0.60+ each due to context bloat. Cost: $82.40.

Phase 3 (5:18 AM - 7:04 AM): Heartbeat bleeding. After the loop exhausted itself, the agent dropped into idle polling — one heartbeat every 30 minutes. But each heartbeat carried the bloated 120K-token session context through Claude Sonnet. Just 4 heartbeat calls at ~$0.36 each, plus residual output tokens. Cost: $8.27.

The loop phase — where the agent kept trying the same failing fix over and over — accounted for 80% of the total bill.

What are the 5 mistakes that cause overnight bill shock?

After digging into this, I realized I had made every mistake in the book. These are the five patterns that cause runaway OpenClaw spending.

Mistake 1: No daily spending cap

I had an Anthropic monthly limit set to $200. That is useless for catching a single bad night. A $100 spike is well within a $200 monthly budget, so no alarm fires. You need a daily cap — ideally $5-$15 for most individual workflows.

Without a daily cap, any single session can consume your entire monthly budget in hours.

Mistake 2: Using an expensive model for heartbeat calls

OpenClaw does not differentiate between "do real work" and "check if I should still be alive." Both go through the same model. So my heartbeat calls were hitting Claude Sonnet at $3 per million input tokens and $15 per million output tokens, the same rate as my actual coding work.

A heartbeat call does not need Sonnet. It barely needs a model at all. Those 4 heartbeat calls should have cost fractions of a penny on a cheap model, not $8.

Mistake 3: No loop detection

The agent tried variations of the same failing fix 214 times over 4 hours. A human would have stopped after 3 attempts. Without loop detection, the agent just keeps hammering the API with identical or near-identical requests, burning tokens on a problem it clearly cannot solve.

Early iterations cost ~$0.10 each. But as context grew, late iterations cost $0.60+. By the 10th attempt, it was obvious the approach was not working. The remaining 200+ attempts were pure waste — over $70 thrown away.

Mistake 4: Session context growing unchecked

Every failed attempt got appended to the conversation history. By iteration 100, the context window had grown from 8,000 tokens to over 120,000 tokens. Each subsequent call was 15x more expensive than the first because the input token count kept climbing.

This is the compounding problem most people miss. Loops do not just waste time — they make each successive call more expensive than the last.

Mistake 5: Running the agent 24/7 without monitoring

I had no alerts. No way to check status from my phone. No kill switch. The agent ran for nearly 8 hours unattended and I had zero visibility into what it was doing. By the time I saw the damage, it was already done.

If I had received a Telegram alert when spending hit $20, I could have killed the session around 1:30 AM and saved over $80.

Why are provider-level spending caps not enough?

After this incident, the first thing people suggested was "just set a lower cap on your Anthropic dashboard." I tried that. It does not solve the problem, for three reasons.

Provider caps are monthly, not daily. Anthropic and OpenAI both let you set monthly usage limits. But a $50 monthly cap means your agent can burn all $50 in one night and then you have nothing left for the remaining 29 days. You need daily granularity.

Provider caps do not detect patterns. A monthly cap treats 100 legitimate requests the same as 100 loop-failure requests. It has no concept of "this agent is stuck" — it just counts dollars. By the time the cap kicks in, the waste has already happened.

Provider caps are per-provider. If you use both Anthropic and OpenAI models (which many OpenClaw configurations do), you need separate caps on each dashboard. There is no unified view. A multi-provider workflow can blow through limits on both services simultaneously.

Provider caps are a useful last line of defense. But they are too coarse to prevent the kind of overnight burn I experienced.

How does two-layer protection actually work?

The solution I built (and eventually turned into ClawCap) uses two layers of protection that work together.

Layer 1: Hard daily spending cap. Every API request passes through a local proxy before reaching the provider. The proxy tracks cumulative spending per day. When the daily cap is hit — say, $5 — the proxy returns a 429 status code and the agent stops. No exceptions, no overrides unless you explicitly resume.

Layer 2: Real-time loop and heartbeat detection. The proxy analyzes request patterns as they happen. If it detects 5+ near-identical requests within a sliding window (loop detection) or periodic low-value calls at fixed intervals (heartbeat detection), it blocks those requests immediately. You do not have to wait for the daily cap to kick in.

These two layers catch different failure modes. The daily cap is your absolute ceiling — it guarantees you never spend more than X per day. Loop detection is your early warning system — it catches waste patterns within minutes, often saving 80-90% of what the daily cap alone would allow.

What does a nightmare scenario vs. a protected scenario look like?

Here is the same overnight session with and without protection:

Phase	Unprotected	With ClawCap ($5/day cap)
Legitimate work (2 hrs)	$12.80	$5.00 (capped at limit)
Loop failure (214 retries)	$82.40	$0.00 (blocked after 5 retries)
Heartbeat bleeding (4 calls with bloated context)	$8.27	$0.00 (routed to cheap model)
Total cost	$103.47	$5.00
Useful work completed	23 files refactored	~9 files refactored
Cost per useful file	$4.50	$0.56
Waste	$90.67 (87.6%)	$0.00 (0%)

Yes, the protected scenario completes less work in a single session. But it completes zero wasted work. You can resume the next day with a fresh $5 cap and finish the remaining files for another $3-4. Total cost for the same 23 files: roughly $8-9 instead of $103.

How do you actually set this up?

ClawCap runs as a local proxy on port 5858. Setup takes about 2 minutes:

npm install -g clawcap
clawcap init        # interactive setup wizard
clawcap start       # starts proxy on localhost:5858

During clawcap init, you set your daily cap (default: $5), add your API keys, and optionally connect a Telegram bot for remote alerts. Then you point OpenClaw at the proxy by updating your ~/.openclaw/openclaw.json:

{
  "models": {
    "providers": [{
      "name": "anthropic",
      "baseUrl": "http://127.0.0.1:5858"
    }]
  }
}

That is it. Every API call now goes through ClawCap. Your daily cap is enforced, loops are detected after 5 repetitions, heartbeat patterns are caught within 3 intervals, and you get a Telegram alert the moment spending hits 80% of your cap.

What does a $5/day cap actually get you?

More than you think. At current Claude Sonnet pricing ($3 per million input tokens, $15 per million output tokens), a $5 budget gives you roughly:

• 250,000-400,000 input tokens depending on your input/output ratio
• 60-90 minutes of active coding work with medium context windows
• 15-30 file modifications in a typical refactoring session

For most individual developer workflows, $5/day is plenty. You are not paying for 8 hours of unattended operation — you are paying for focused bursts of useful work.

If you need more, set the cap to $15 or $25. The point is not the specific number — it is that you have a number at all. Without a cap, there is no upper bound.

What about the agent's work quality when it gets stopped?

This is the objection I hear most. "If ClawCap kills my agent mid-task, won't it leave things in a broken state?"

The answer is: your agent is already leaving things in a broken state when it loops 47 times on the same error. A clean stop at attempt 5 is strictly better than a messy failure at attempt 47. At least at attempt 5, the codebase has not been churned by 42 additional broken patches.

When ClawCap blocks a request, it returns a clear error message that OpenClaw can surface to you. You see exactly why it stopped — "daily cap of $5.00 reached" or "loop detected: 5 similar requests in 3 minutes" — and you can make an informed decision about whether to resume.

How much does this actually save over a month?

I tracked my spending for 30 days before and after implementing proxy-level caps. Here are the real numbers:

Before (no caps): $487.30 total. Three "bad nights" accounted for $289 of that. Average daily spend: $16.24 with a standard deviation of $22.10 (meaning huge variance, mostly from outlier nights).

After ($10/day cap + loop detection): $198.60 total. Zero bad nights. Average daily spend: $6.62 with a standard deviation of $2.80 (tight, predictable). Same volume of actual work completed — I just spread it across more sessions.

That is a 59% reduction in spending with no reduction in output. The savings came entirely from eliminating waste: loops, heartbeats, and runaway sessions.