Skip to content
Agentic Control Plane
Incident series · Part 7 of 11
Stop Your Agent From… →

Stop your AI agent from burning through your API budget — in three steps

David Crowe David Crowe · · 6 min read
governance defense-in-depth rate-limiting budget-caps
Share X HN LinkedIn

A developer posted on the Cursor forum that their Cursor agent fell into a loop when context was summarized mid-generation — abandoning the file and restarting, over and over, until they caught it. A Codex CLI issue titled “Sub-agent costs are too high and too opaque” reports its author “easily $350 over my Pro Plan for a week.” A Google Cloud customer with a $7 budget woke up to an $18,000+ bill after a forgotten public API key fielded 60,000+ unauthorized requests, blasting through a $1,400 spending cap that was supposedly hard.

The pattern: an agent gets stuck, or a credential gets reused, and the bill arrives later. The provider’s “spending cap” turns out to be advisory, or to apply at a granularity (monthly, per-account) that doesn’t catch a runaway loop running for hours.

If you’re running agents and you don’t have an external rate limit, your only stopgap is “I notice in time” — and devs reliably don’t.

Why the provider’s caps don’t save you

Most AI providers and cloud platforms have some form of spending limit. They share a few weaknesses:

  • They evaluate at coarse intervals. Stripe-style usage billing settles every minute or hour, not per-call. A loop can produce thousands of calls between settlement boundaries.
  • They apply at the account level, not the agent level. If you have ten agents, the cap caps all of them collectively. One runaway agent can burn the budget for the rest.
  • They don’t distinguish tiers. A $5/hour interactive Cursor session is fine. A $5/hour cron-scheduled background agent is a problem. The provider’s cap doesn’t know the difference.
  • They’re “advisory” more often than not. Google Cloud’s spending cap is famously a notification, not a hard limit — an attacker can run past it for hours before the account is suspended.

Your defense isn’t the provider’s cap. Your defense is a control plane between your agent and the provider’s API.

Three steps that put a budget gate between your agent and the bill

Step 1 — Install the hook

For Cursor, Claude Code, or Codex CLI:

curl -sf https://agenticcontrolplane.com/install.sh | bash

Every tool call the agent makes — including the LLM round-trips for non-proxied calls and the underlying API calls for tool dispatch — goes through ACP’s hook. The hook tracks per-agent, per-tier call counts and token spend in a local in-memory window, and ACP’s gateway aggregates fleet-wide.

Step 2 — Set per-tier rate limits and call budgets

In your dashboard (cloud.agenticcontrolplane.com) → Policies:

{
  "mode": "enforce",
  "defaults": {
    "background": {
      "rateLimit": { "calls": 30, "window": "1m" },
      "tokenBudget": { "max": 500000, "window": "1d" },
      "callBudget":  { "max": 200,    "window": "1h" }
    },
    "interactive": {
      "rateLimit": { "calls": 120, "window": "1m" },
      "tokenBudget": { "max": 2000000, "window": "1d" }
    },
    "subagent": {
      "rateLimit": { "calls": 20, "window": "1m" },
      "callBudget": { "max": 50,  "window": "10m" },
      "comment": "subagents are spawned by other agents — tightest limits"
    }
  }
}

The semantic: a background-tier agent has a sliding-window cap of 30 calls per minute, 200 calls per hour, and 500K tokens per day. If a loop produces a 31st call inside a one-minute window, the 31st call is denied. The agent sees a tool_error: rate_limited and adapts (or aborts).

For the subagent tier specifically, you can be tighter — subagents are spawned by other agents and are the most common source of runaway fan-out.

Step 3 — Set a hard fleet-wide budget alarm

For the “$18,000 GCP bill” scenario, you don’t just want per-agent rate limits — you want a fleet-wide budget threshold that triggers a hard kill switch:

{
  "fleetBudget": {
    "monthlySpendCap": "$500",
    "alertThresholds": ["$100", "$250", "$400"],
    "onBreach": {
      "action": "deny_all_tool_calls",
      "scope": "tenant",
      "until": "manual_reset"
    }
  }
}

When the cumulative spend across all agents in your tenant hits $500, every tool call is denied until you manually reset. Alerts fire at $100, $250, $400 so you know it’s coming.

This is the layer that catches the GCP-style “leaked key fields 60,000 requests” scenario. Even if an attacker has a working credential, they can’t spend more than the fleet cap.

(Free fourth step) — Spend audit + alerts

Every governed call writes spend to your activity log: agent identity, tier, token count, estimated cost. The dashboard groups by agent + tier + time window, so you can see at a glance “agent X has used 80% of its daily token budget at 11am — concerning.” Set up alerts for sudden spend deltas (5x over rolling baseline) so the runaway loop wakes you up at hour one, not hour twelve.

The total time investment

  • One curl command (Step 1): ~30 seconds
  • Per-tier rate limit + budget config (Step 2): ~3 minutes
  • Fleet-wide budget cap (Step 3): ~2 minutes

Five to six minutes from blank slate to “an autonomous agent in this environment cannot exceed N calls per minute, M tokens per day, or $X total spend without explicit override.”

The asymmetry between five minutes of setup and an $18,000 surprise bill is large. The harder part is convincing yourself that the runaway loop is eventually going to happen. The forums and GitHub issues say it already has, in environments that look a lot like yours.

A cap is half the story; seeing where the money goes is the other half. The loop tax explains why agent bills concentrate in the orchestration loop, ACP for coding agents prices every session at API rates, and the Tool Surface Index shows which declared tools can spend in the first place.

Correction (2026-07-18): an earlier version of this post attributed a “$135 of credits in a week” figure to the Cursor forum thread and described the GCP victim as a consultant in Australia with a leaked Gemini key. The thread reports the runaway loop but no cost figure, and the article we cite doesn’t name the person’s role, location, or the specific API. We’ve corrected the text to match the sources.

AgenticControlPlane.com

Share X HN LinkedIn
Get the next data drop
What agents actually cost, new tool-surface captures, and the occasional incident post-mortem — sent when we publish something worth your inbox, not on a schedule. Unsubscribe anytime.
Share: Twitter LinkedIn
More in Stop Your Agent From…
  1. 1. Stop your AI agent from running `rm -rf` on your filesystem — in three steps
  2. 2. Stop your AI agent from deleting your production database — in three steps
  3. 3. Stop your AI agent from touching files outside your project — in three steps
  4. 4. Stop your AI agent from rewriting your git history — in three steps
  5. 5. Stop your AI agent from leaking secrets in your `.env` file — in three steps
  6. 6. Stop your AI agent from leaking PII through tool calls — in three steps
  7. 7. Stop your AI agent from burning through your API budget — in three steps · you are here
  8. 8. Stop your AI agent from making payments without approval — in three steps
  9. 9. Stop your AI agent from dropping a Kubernetes namespace — in three steps
  10. 10. Stop your AI agent from escalating IAM permissions — in three steps
  11. 11. Stop your AI agent from being weaponized by a malicious package — in three steps
Related posts

← back to blog