Agent fleets scale faster than anyone tracks their spend. Here is the workflow that caps every run, catches loops, and puts an owner on every dollar.
Nobody plans for the invoice that arrives after an agent loops all weekend. Automated agent cost control is the workflow that stops it: every agent run gets a budget, a loop detector, and an owner before it touches production. Here is how DevOps and security teams put that guardrail in place without slowing anyone down.
See the pattern in action, tap through the tabs below:
The bottleneck: agent fleets grow faster than anyone tracks them. One team ships a triage agent, another ships a review agent, and a month later the bill has a line item nobody owns. Retry storms, oversized models on trivial steps, and silent loops all look like normal traffic until finance asks questions.
The outcome: every run is capped, every agent has a named owner, and overspend pages a human before it becomes a surprise.
# agent-budget-policy.yaml
fleet: release-and-triage
limits:
per_run_usd: 2.50
per_agent_daily_usd: 40
fleet_daily_usd: 400
max_tool_calls_per_run: 60
max_retries_per_step: 3
routing:
default_model: small-fast
escalate_to: large-reasoning
escalate_when:
- confidence_below: 0.6
- step_type: [plan, security_review]
on_breach:
soft_80pct: notify #agent-ops
hard_100pct: pause_agent_and_page_owner
loop_detected: kill_run_and_attach_trace
tags_required: [team, workflow, owner]
agentctl budget watch --fleet release-and-triage [09:02] triage-agent run#8841 0.31 USD calls=12 OK [09:14] triage-agent run#8852 1.94 USD calls=47 WARN 78% of per-run cap [09:15] triage-agent run#8852 same tool called 9x with identical args [09:15] LOOP DETECTED -> run killed, trace attached to INC-2291 [09:16] review-agent daily spend 82% of cap -> notify #agent-ops [09:40] review-agent switched 61% of steps to small-fast model [10:05] fleet 118 of 400 USD daily budget, 3 owners tagged [10:05] report top spender: triage-agent (retry storm, fixed)
Do this week: 1) Tag every agent with team, workflow, and owner. 2) Set a per-run cap at roughly 3x your median run cost. 3) Add a loop detector on identical repeated tool calls. 4) Route trivial steps to a small model. 5) Send a weekly top-spenders report to the owners.
Want this built for your team? The DevOps Boot Camp walks through it hands on.
Why agent spend gets out of hand
Classic cloud cost problems are slow. A forgotten VM burns money at a steady rate you can graph. Agents are different, because cost scales with behavior, not uptime. A single confused run can call a tool fifty times, re-read a huge context on every step, and retry a failing API until it hits a rate limit.
Three patterns cause most of the damage:
- Retry storms: an agent hits a flaky endpoint and keeps retrying, paying for a full context each time.
- Model overkill: the largest model handles steps a small one could do, like formatting or classification.
- Orphaned agents: a prototype keeps running because nobody remembers who launched it.
The workflow: budgets, routing, and owners
Automated cost control is a small loop that runs on every agent call. It checks the budget before the call, records the spend after it, and reacts when a threshold trips.
1. Give every run a ceiling
Set a per-run dollar cap and a maximum tool-call count. Most healthy runs finish far below both. When a run reaches the cap, it stops and hands its trace to a human instead of quietly continuing.
2. Detect loops early
The cheapest signal is repetition. If the same tool is called with identical arguments several times in a row, the run is stuck. Kill it, attach the trace, and open a ticket. This single rule catches most runaway spend.
3. Route by difficulty
Send routine steps to a small, fast model and escalate to a larger one only when confidence drops or the step is a planning or security review. Teams that adopt routing commonly shift the majority of steps to the cheaper tier without hurting quality on the hard ones.
4. Attach an owner to every agent
Require team, workflow, and owner tags before an agent can run. When a budget trips, the alert goes to a named person, not a shared channel that everyone mutes.
How it's built
The mechanics are simple, and the tooling is interchangeable. A gateway or proxy in front of your model calls records token usage per run and per tag. A small policy file, like the one in the widget above, defines caps and escalation rules. A scheduler posts a daily spend summary and pauses agents that breach a hard limit. Most teams wire this into their existing observability stack and chat alerts rather than adopting a new platform.
For governance, treat the budget policy like any other config: keep it in version control, review changes in pull requests, and log every override. That gives auditors a clean trail and gives engineers a safe way to raise limits when a workflow legitimately needs more.
What to measure
- Cost per successful run, not just total spend.
- Percentage of runs killed by loop detection.
- Share of steps handled by the small model.
- Agents without an owner tag (target: zero).
Review these weekly. Falling cost per successful run with steady success rates means the guardrails are working. A rising loop-kill rate usually points at a flaky dependency worth fixing at the source.
Common mistakes
Setting one giant fleet-wide cap is the most common one. It protects the invoice but not the workflow, because one noisy agent can starve the rest. Set limits per run and per agent first, then add the fleet ceiling as a backstop. The second mistake is alerting without action: a warning that nobody owns is just noise. Pair every threshold with a default action, such as pausing the agent, so the safe outcome happens even if no one is watching.
If you want to build this workflow for your own team, see the tha-shed courses or start with the DevOps Boot Camp. For background on why cost governance matters for agent systems, the OWASP Top 10 for LLM Applications covers unbounded consumption as a named risk.
FAQ
How do I set a good per-run budget?
Measure a week of normal runs, take the median cost, and set the cap near three times that. Tighten it once you see the distribution.
Will caps break legitimate long tasks?
Not if you allow an approved override. Let the owner raise the cap for a named workflow, and log the change in version control.
What is the fastest first step?
Add owner tags and a loop detector. Those two changes give you accountability and stop the worst spikes in one afternoon.
