Skip to content

AI agent cost controls: budgets, quotas, and loop limits that stop runaway spend

7 min read
AI Strategy
AI agent cost controls: budgets, quotas, and loop limits that stop runaway spend

Key Takeaways

  • 1Set limits at four levels - per task, per agent, per team, and per account - because each catches a different failure
  • 2Cap steps, tool calls, retries, and wall-clock time on every run, not just tokens
  • 3Alert on forecasted spend and on unusual rate of spend, not only on the monthly total
  • 4Give every limit an owner and a defined stop behavior, including who can raise it

A chatbot costs roughly what you expect: one question, one answer. An agent does not. It plans, calls tools, reads the results, and tries again, and every step spends tokens and often money in other systems. If something goes wrong, such as a tool that keeps returning an error, a vague goal, or a hostile input, the agent can repeat the expensive part many times before anyone looks.

OWASP lists this under unbounded consumption and uses the term "denial of wallet" for attacks and accidents that drive up usage-based bills. For an operations or finance lead, the practical question is simple: if this agent misbehaves tonight, what is the most it can spend before it stops? This guide shows how to make that number small, known, and owned by someone.

Where agent spend actually comes from

Before you set limits, know what you are limiting. Agent cost has four main sources:

  • Model usage. Input and output tokens, which grow quickly when an agent re-sends a long history on every step.
  • Tool and API calls. Search, data enrichment, code execution, and paid third-party APIs, each with its own price.
  • Time and compute. Long-running jobs, sandboxes, and queues that keep running while nothing useful happens.
  • Human follow-up. Cleaning up wrong actions, such as duplicate emails or bad records, is a cost that never shows on the model invoice.

Tracking only the model invoice misses the second and fourth. If you have already moved to credit-based plans, our guide to AI subscriptions moving to credits covers how to budget the plan itself; this article is about limits on the agents running inside it.

Set limits at four levels

One limit is never enough. Each level catches a different failure.

Level Example limit What it catches
Per run (task) Maximum steps, tool calls, retries, minutes, and a spend ceiling A single stuck loop
Per agent Daily spend and daily run count A bug that starts many runs
Per team or project Monthly budget with an owner Slow drift and unplanned adoption
Per account Hard cap or provider budget at the cloud or API account Anything that slipped through the rest

The per-run level matters most for agents, because that is where loops live. The account level matters most as a backstop, because it is the only one that works even if your own code is wrong.

Limit the shape of a run, not just tokens

Token limits alone do not stop a loop that makes many small calls. Put a ceiling on each of the following for every run:

  1. Steps. Maximum reasoning and action cycles. Agent frameworks expose this directly; LangGraph, for example, has a configurable recursion limit that raises an error when a graph runs more steps than allowed instead of looping forever.
  2. Tool calls, per tool. Cap expensive tools separately. Ten web searches are fine; ten thousand are an incident.
  3. Retries. Allow a few retries with backoff, then fail. Retrying the same failing call is the most common loop in practice.
  4. Wall-clock time. A timeout per run and per tool call. OWASP recommends timeouts and throttling for resource-intensive operations for exactly this reason.
  5. Context size. A ceiling on how much history is carried forward, or a summary step, so cost per step does not grow with every step.
  6. Repeated-action detection. If the agent makes the same call with the same arguments three times, stop and report. This is cheap to build and catches many loops that the other limits would only catch late.

Pick starting values from observed normal runs. A reasonable first rule is to set the ceiling at a few times the typical run, then tighten it as you gather data. A limit hit constantly blocks real work and will be bypassed.

Rate limits and quotas

Rate limits control how fast spend can accumulate. Apply them per user, per agent, and per integration. OWASP recommends rate limiting and user quotas to restrict how many requests a single source can make in a time period, which also reduces abuse from a compromised account or hostile input.

Model providers publish their own rate limits and usage tiers (see the OpenAI and Anthropic documentation in the sources). Those protect the provider, not your budget, so treat them like an overdraft limit: a number you should never approach.

Alerts: forecast and rate, not just totals

A monthly total alert fires after the money is gone. Build three kinds of alert instead:

  • Forecast alerts. Cloud billing tools can alert on forecasted spend before it accrues, not only on actual spend. AWS Budgets and Google Cloud budgets both support threshold alerts; set one at a level where you can still react, such as when the forecast crosses 80% of the budget.
  • Rate alerts. Spend per hour compared with the usual pattern for that agent. A tenfold jump at 3 a.m. is more useful information than a monthly total.
  • Cost-per-outcome alerts. If an agent normally spends a small amount per resolved ticket or processed invoice, alert when that ratio drifts. It shows waste that stays under every absolute limit.

Send alerts to a person or channel that is actually watched, and say in the alert which agent, which limit, and what the runbook step is.

Decide what happens at the limit

A limit without a defined stop behavior is just a log line. For each limit, choose one of these in advance:

  • Stop and report. The run ends and a person is told what it was doing. Best default for loops.
  • Degrade. Switch to a cheaper model or a read-only mode. Suitable for customer-facing flows where stopping is worse than a lower-quality answer.
  • Ask for approval. Pause and require a named person to approve more spend or a larger action. Suitable for high-value but legitimate tasks.
  • Hard stop. Disable the agent's credentials. This is the kill switch; see our guide to AI agent incident response and kill switches for how to design it so it works under pressure.

Spend limits should also have an owner who can raise them. Raising a limit should be a recorded decision with a reason, not a quiet configuration change. This fits the wider approach in our guide to enterprise AI agent governance.

Use separate credentials and keys

Give each agent, or at least each team, its own API key or service account. Then spend can be attributed, a single key can be revoked without taking everything down, and per-key limits are possible where the provider supports them. A single shared key makes every alert ambiguous and every shutdown a company-wide event.

Tag usage with agent name, team, and task type where possible. Without tags, you will see a large number and not know who owns it. For what to record and how to do it without exposing sensitive data, see observing AI agents in production without leaking data.

Review spend as part of operations

Cost control is a routine, not a launch task. A light cadence works for most companies:

  • Weekly: top five agents by spend, any limit that was hit, any alert that fired and what was done.
  • Monthly: compare spend with the value delivered, adjust budgets, retire agents nobody uses, and review who holds the right to raise limits.
  • After every incident: add the limit or detection that would have caught it earlier.

The FinOps Foundation treats AI as a cost area that needs visibility, allocation, and accountability shared between engineering and finance. Finance cannot set useful limits without knowing how agents work, and engineers need a budget to aim for.

A one-page starting checklist

  1. Every agent has its own credential and a named owner.
  2. Each run has caps on steps, retries, tool calls, time, and spend.
  3. Expensive tools have separate, lower caps.
  4. Repeated identical calls stop the run.
  5. Each agent has a daily budget; each team has a monthly budget.
  6. Account-level budgets or hard caps exist at every provider.
  7. Alerts cover forecast, rate of spend, and cost per outcome, and go to someone who is watching.
  8. Each limit has a defined stop behavior: stop, degrade, approve, or disable.
  9. Raising a limit needs an owner's decision and a written reason.
  10. A weekly review looks at limits hit and alerts fired.

If you can answer "what is the most this agent can spend before it stops, and who is told?" for every agent you run, you have the core of cost control. The rest is tuning with real data. If you want help setting this up for your agents, get in touch with us.

Sources

Share this article

Need expert guidance?

Let's discuss how our experience can help solve your biggest challenges.