How to set a spend cap on AI agents — before the bill

The short answer

To set a spend cap on AI agents, enforce a cumulative budget at the action layer, not just the model call: reserve estimated cost before each action, commit actual cost after, and block or escalate to a human when the running total hits the cap. Gateway budgets cap tokens; an action-layer cap also stops the $40,000 refund.

Why “we have budget alerts” keeps failing

Three patterns from the last twelve months, all on the record or widely reported:

• An enterprise client reportedly ran up ~$500M in Claude token spend in one month after issuing employee licenses with no usage limits (an AI consultant’s account reported by Axios; the company is unnamed and the figure unconfirmed — treat it as a story, not a stat).
• Uber exhausted its 2026 AI coding budget by April and instituted a $1,500/engineer/month cap afterward.
• Microsoft moved most Experiences + Devices engineers off Claude Code, where internal usage reportedly ran $500–$2,000/engineer/month.

The common thread is not a rogue model. The cap either didn’t exist or wasn’t turned on — and alerts are posterior to the spend.

The three places you can put a cap

1. Provider limits (OpenAI/Anthropic dashboards). Hard monthly org-level ceilings. Blunt: one shared ceiling, no per-agent attribution, and when you hit it, everything stops — including the agents doing useful work.

2. Gateway budgets (LiteLLM, Portkey, Bifrost). Virtual keys with per-team budget windows and a 429 on breach. Good cost control, and you should probably have one. But a gateway caps token dollars. It cannot see that draft_reply and issue_refund cost the same fraction of a cent in tokens while one of them moves $40,000 of real money.

3. Action-layer caps (Arc). A cumulative budget enforced per agent on the actions themselves: each action declares its cost (token estimate, dollar field, or fixed weight), the runtime reserves against a ledger before execution and commits after, and a breach blocks the action or pauses it for human approval — instead of letting the loop keep running.

arc.defineActions({
  issue_refund: {
    risk: "high",
    defaultDecision: "ask",
    cost: { mode: "field", field: "amount" },   // charged against the agent budget
  },
})
// budget: $2,000/day → action #41 that would cross it is blocked, not logged

The reserve-then-commit ledger matters more than it looks: a naive if (spent > budget) check races under concurrency — two agent loops read the same balance, both pass, and you’re over. Correct enforcement is an atomic reservation in integer minor units.

What to cap, concretely

Start with one number you can defend to your CFO: per-agent daily budget = (expected daily actions × typical action cost) × 3. Then declare the irreversible actions (delete_*, send_*, refunds over $X) as ask regardless of budget headroom — a correctly-budgeted catastrophe is still a catastrophe. Anything you didn’t declare should be blocked by default.

FAQ

Do I need an action-layer cap if I already use LiteLLM budgets? Keep the gateway for token cost and routing. Add an action-layer cap if your agents take consequential actions — refunds, sends, deletes, infra changes — where the risk is the action, not the token bill. They compose: gateway in front of the model, Arc in front of the action.

What should the agent do when it hits the cap? Pause, not crash. Arc holds the action for human approval (or blocks it), logs the attempt in a hash-chained audit trail, and the loop waits. Fail-closed, with a paper trail.

How do I set a cap on agents I didn’t build (MCP tools)? Route tool calls through a policy adapter. @geostack/arc-mcp-adapter wraps MCP tool calls in the same allow / ask / block + budget evaluation without modifying the agent.

---

Arc is the spend-and-action guardrail for AI agents — free Developer tier, no credit card: npm i @geostack/arc. Quickstart →