OpenClaw Runaway Costs: What Actually Causes Them and How to Cap Spend

In April 2026, an OpenClaw user posted their monthly bill: $623. They weren't running anything exotic. No video generation, no fine-tuning, no enterprise workload. They were using OpenClaw to draft emails and summarize meeting notes.

The number was startling, but the cause wasn't mysterious. Once we walked the logs back, the spike collapsed into three small mistakes — each one preventable with controls that already exist. Pay-as-you-go pricing didn't fail. Behavior did, and nobody had set a ceiling.

If pay-per-call billing makes you nervous, the question worth asking isn't whether spikes happen. It's what causes them, and what stops them.

What is an OpenClaw runaway cost event?

A runaway cost event is any 24-hour window where spend exceeds a user's baseline by 10x or more, driven by automated behavior rather than intentional usage. These events are rare, but they're the headline objection to consumption pricing, so they deserve a precise diagnosis.

The pattern is consistent across every incident we've reviewed: a model or skill enters a state where it keeps invoking itself, processing material it doesn't need, or calling external tools without supervision. The bill follows.

This is different from the slow, predictable creep covered in The Real Cost of Running OpenClaw. That post deals with steady-state spend. This one is about the tail — the rare days when something breaks.

Cause 1: Recursive loops in skill execution

The most expensive failure mode is a skill that calls itself, or two skills that call each other, with no exit condition.

A typical example: a user writes a skill that reads from a file, summarizes it, and writes the summary back. They forget to filter the input, so the next run reads the summary as fresh input, summarizes that, and writes another summary. Each iteration costs a few cents. Left running overnight on a cron, it consumes hundreds of dollars before morning.

Loop bugs are hard to spot because the model itself behaves correctly — it's the orchestration layer that's broken. Detection requires watching for the same skill firing repeatedly within a short window, regardless of whether each individual call succeeds.

Cause 2: Oversized context windows

The second most expensive failure mode is passing too much context into every request without realizing the per-token cost.

Context is billed per token. A 200,000-token context costs roughly 100x more per call than a 2,000-token one. Users who attach long documents, paste full logs, or load entire codebases into a session often don't notice the running total until the invoice arrives.

The trap is that the assistant frequently works better with more context, so the incentive points toward larger payloads. There's no warning when you cross from useful context into expensive context — the request succeeds either way, just at a different price.

Cause 3: Unmonitored skill calls to paid APIs

The third pattern is skills that call paid external services without any caps on frequency or output size.

An image-generation skill that costs $0.04 per call is harmless when invoked five times a day. The same skill called in a loop, or triggered by an automation that fires every minute, generates 1,440 images and a $58 bill in 24 hours. Multimodal output — image, music, video — amplifies this dramatically, as covered in When Your AI Assistant Can Generate Images, Music, and Video.

The risk concentrates where users least expect it: in helper skills they wrote months ago and forgot about. A scheduled task that worked fine last quarter starts misbehaving after an upstream API change, and there's no spend ceiling to catch it.

The three patterns at a glance

Below is a side-by-side view of the three failure modes, their typical 24-hour cost range, the signal that exposes each, and the control that prevents it.

How spend caps work on managed hosting

Spend caps stop incidents at the boundary, before the bill grows. On Clowdbot, three controls work together: a hard monthly ceiling, per-skill rate limits, and anomaly alerts that trigger when usage diverges from a rolling baseline.

The hard ceiling is the simplest and the most important. You set a dollar figure — say $80 — and once monthly spend reaches it, every additional request is rejected until you raise the cap or the month rolls over. No incremental charges, no surprise overage. This single control would have prevented the $623 incident.

Per-skill rate limits address loops specifically. You can specify that a given skill cannot fire more than N times per minute, hour, or day. A recursive bug still happens — but it dies at the limit instead of burning through the night.

Anomaly alerts catch the slower drift cases: contexts gradually growing larger, skill counts creeping up, new automations introduced by mistake. The alert fires when daily spend exceeds the trailing 14-day median by a configurable multiplier.

For a side-by-side look at how this compares to running OpenClaw on a self-managed VPS, where these caps don't exist by default, see OpenClaw Hosting Compared: VPS, Managed, and Pay-As-You-Go.

What to do if you've already been burned

If you've experienced a runaway cost event, the first step is identifying which of the three patterns applies — logs usually reveal it within minutes.

Pull the per-skill invocation count for the billing period and sort descending. A loop bug shows as a single skill with 1,000+ calls. Oversized context shows as a normal call count but average token sizes well above baseline. Unmonitored skill calls show as a previously low-volume skill suddenly producing high spend.

Once identified, the fix is the matching cap from the table above. The slower part is reviewing every skill you've written to confirm none can recurse — but it takes one pass to harden the system permanently. For users running their own setup, the cost dynamics in The Hidden Costs of "$20/month" AI Assistants are worth reviewing alongside this.

Frequently asked questions

Will a spend cap interrupt work mid-session?

Yes — once the cap is reached, new requests are rejected until the cap is raised or the billing period resets. This is the trade-off: predictability requires a hard stop. Most users set the cap at 2–3x their typical monthly spend, which leaves headroom without exposing them to a runaway event.

How fast do runaway events typically grow?

In the incidents we've reviewed, the median runaway grew from baseline to 10x baseline in under 6 hours and reached its peak within 24. This is why daily-resolution alerts matter more than weekly ones.

Can I get a refund if a runaseaway event happens?

On most pay-as-you-go pricing — including the underlying Anthropic API — refunds for behavioral overspend are handled case-by-case and are not guaranteed. The reliable defense is the cap, not the refund process.

Are these patterns specific to OpenClaw or do they apply elsewhere?

They apply to any consumption-priced AI system that supports custom skills, automation, or large context windows. OpenClaw's openness and skill ecosystem make these patterns visible — and addressable — in a way that closed assistants often don't.

If I bring my own API key, do these caps still apply?

It depends on the platform. Anthropic's console offers monthly limits but not per-skill rate limits or anomaly alerts. The runaway risk is real either way, which is part of the broader BYOK trade-off discussed in OpenClaw Without API Keys.

Pay-as-you-go pricing is honest about what you use, but it requires you to define what you're willing to spend. The three patterns above cause nearly every runaway cost event, and each has a specific control that stops it. Set the caps once, and the headline objection to consumption pricing becomes a non-issue.