Lessons from a $37 Bill: How to Set Spending Limits for AI Agents

A developer bought an API key for a research agent to run a single competitive monitoring task, capped at 50 calls per day, with each call costing under a cent. On the third evening, the bill showed $37 spent that day.

The cause was a subtask stuck in an error loop: a call failed, the agent adjusted parameters, retried, and failed again. The 50-call cap didn't stop it, because each endpoint had its own quota, and that cap didn't cover all endpoints.

$37 isn't a disaster. But it exposed a more fundamental problem: the developer had never designed how the agent should spend money. He gave each agent a working card, not an account with a budget.

Below is a set of practices summarized after the fact, none of which require new infrastructure.

Split budgets by purpose, not just a single monthly total

Giving each agent a monthly total is too coarse. A more effective approach is to split into three buckets:

• Exploration budget: $5 to $20 per week for trying new APIs. Stop when it's used up, and wait until next week to continue.
• Project budget: A fixed amount loaded for a single task, e.g., $10 to scrape a batch of competitor prices. When the task ends, the unspent money is returned.
• Escalation approval: Any spending above a threshold requires human approval. The agent must proactively request it rather than spend directly.

The key is that limits must be set before the agent starts. Cutting spending after the fact teaches the agent nothing.

Prepaid budget is an idea inherited from gift cards and prepaid phones: deposit money into an isolated account first, spend until it's gone, rather than relying on post-paid credit. For agents, the difference lies in the cost of default. Under a credit model, a runaway loop keeps generating real charges until a human notices; under a prepaid model, once the account balance hits zero, it is physically impossible to initiate further calls, turning loss prevention from "monitoring alerts" into "the mechanism itself."

Prepayment also brings two side benefits: first, at the end of a task, the unused balance can be returned to the main account, naturally matching the semantics of a "project budget"; second, each agent's balance is a readable number, so you can directly see "how much it has left" instead of parsing a mixed monthly bill.

Use allowlists, not blocklists

The old approach was to allow everything by default and then block things one by one when services had problems. Every new service is a new risk, and you're always one step behind.

The logic is now reversed: nothing is allowed by default.

• Start with services you already trust, such as OpenAI, Anthropic, and existing data sources.
• New services are added only after individual review.
• If an agent needs a new service, it must submit a request.

Allowlists should also come with numbers. The author limits spending per call and per day, e.g., "at most $5 and 200 calls per day." A single rule like this can cut off a retry loop in its third round.

Allowlist vs. blocklist is a fundamental pair of models in access control. A blocklist is "allow by default, prohibit one by one," and its security depends on whether you can enumerate all bad cases; an allowlist is "deny by default, permit one by one," and its security depends on what you've reviewed. The former inevitably lags in an open environment, because the attack surface and new services keep growing.

This model first became widespread in firewalls and email gateways, and later became a common practice for cloud IAM policies, package manager dependency whitelists, and container image signing. It's especially critical for agents: agents autonomously discover and call new services, and if allowed by default, an endpoint that doesn't exist due to a hallucination could still trigger real billing. Setting the default to deny is equivalent to taking the decision of "whether to spend this money" out of the model's hands and back into human hands.

Set per-transaction caps and monitor for anomalies

A healthy total doesn't mean individual transactions are fine. Every agent account should have a hard rule: any single charge over $2 must be routed to a human.

On top of that, the account should be frozen when call frequency, failure rate, or spending velocity is abnormal. The cheapest version needs only one condition: the agent can spend money only if the budget is greater than zero and no anomaly flag has been triggered.

Rate and failure-rate signals in anomaly detection deserve separate mention. The typical signature of a retry loop is: call frequency spikes in a short period, failure rate rises in tandem, and individual amounts are tiny but there are extremely many of them. So looking only at the total is often too late; you need to monitor three dimensions simultaneously—calls per unit time, share of failed calls, and spending velocity per unit time.

A common engineering practice is to set a sliding-window threshold for each dimension; if any one triggers, freeze the account and notify the owner. Freezing is better than outright banning: the account is retained and can be restored after top-up or manual review, avoiding accidental damage to legitimate long-running tasks. The condition can be extremely simple, e.g., "budget balance greater than zero and no anomaly flag," so the judgment logic itself is unlikely to go wrong and won't let spending through due to monitoring system failure.

Give the agent a visible owner

When an agent calls a third-party service, it should indicate who it works for, e.g., showing an identifier like yourname.cloudflare.pay, rather than an anonymous account.

An agent with a clear owner is more likely to get trial credits; when problems arise, merchants are also more likely to email you rather than ban you outright. This is the same reason people trust yourname.com but not a bare IP plus port.

Three things you can do this week

1. List all paid services your agents call, and how much each costs per month. The total is usually higher than you think.
2. Give each major agent a budget number and enforce it in code, not in a memo.
3. One API key per agent. Separate bills, separate limits, and turning one off doesn't affect the others.

All of this takes less than an hour.

Hard limits bring freedom

With a $10 cap, the author can confidently let an agent try 50 services without watching it. Conversely, with $1,000 in the account and no cap, he'd have to check the bill at 2 a.m.

This is also why he endorses Cloudflare's two-tier wallet design: it turns "do I trust this agent" into "what's the cap."

Under normal conditions, a well-limited agent system will occasionally show a "budget exhausted, paused" message. You top up or adjust, and work continues. Rather than waking up every day to open the bill first thing.

The original article finally reminds: prices and policies change, so please consult the official documentation before purchasing.