Setting Spend Caps Before Your Agents Set Them for You

A request-count limit is the simplest to implement but doesn't account for the fact that one agent turn can vary enormously in cost depending on how many tool calls and how much context it involves. A token-based limit tracks cost more directly. A hard dollar cap per session or per day is the most direct protection against a genuinely runaway loop, and it's worth having even if you also track the other two.

Per-session limits catch a single stuck conversation. Per-user daily limits catch a pattern across many sessions from the same source. An account-wide or system-wide daily cap catches the scenario where the first two limits are individually reasonable but something is happening at a scale you didn't design for, a lot of users hitting their per-session limit at once, for instance.

Layer the limits so each one catches a different failure:

• A per-session limit catches a single stuck conversation before it runs for the whole length of the exchange.
• A per-user daily limit catches a pattern across many sessions from the same source.
• An account-wide or system-wide daily cap catches activity at a scale you did not design for.
• A separate, lower limit on destructive or expensive tool calls covers the case where a loop keeps calling a write tool.
• A hard dollar cap per session with automatic cutoff bounds the worst case whatever caused the loop.

The agent should degrade gracefully when it hits a limit, telling the user clearly that it's reached a usage boundary, rather than failing silently or returning a confusing error. For destructive or expensive tool calls specifically, consider a lower, separate limit than the one you'd set for read-only lookups, since a loop that keeps calling a write tool is a more expensive and more dangerous failure than one stuck reading the same record repeatedly.

For example, a support agent might allow generous read-only lookups per session but only a few write actions, with a clear message once the write limit is reached: the agent says it has hit a usage boundary and offers to hand the conversation to a person. The message matters as much as the limit, because a silent cutoff looks like a bug and generates support tickets, while an explicit one tells both the user and your own alerting exactly what happened.

A single session hitting a much higher tool-call count than your typical session, or the same tool being called with nearly identical arguments several times in a row, is the signature of a stuck loop or a manipulation attempt, not normal usage. Alert on this pattern specifically, rather than only on total spend crossing a threshold, since spend alerts fire after the damage is already done.

Build the alert to fire on the pattern within minutes, not as part of a daily spend report reviewed the next morning. The gap between when a loop starts and when someone notices it is exactly the window where the damage actually accumulates.

Say a customer's message contains an unusual formatting quirk that confuses a tool's argument parser, and the tool returns an error the model interprets as "try again with different phrasing" rather than "this input has a structural problem." The model rephrases and calls the same tool again, gets a similar error, rephrases again, and repeats this pattern a few dozen times within one turn before either hitting a cap or, without one, simply continuing until the user gives up waiting.

In the logs, this shows up as the same tool name called with slightly different argument text, one after another, in a single session, well outside the range of tool calls a normal turn would ever need. A per-session call-count cap catches this specific case cleanly, stopping the loop within a handful of attempts instead of letting it run for the full length of the conversation.

The actual fix, once found, was in the tool's error message, changing it from a generic "invalid input" to one that specifically named the formatting quirk, which gave the model something concrete to correct rather than a vague signal to keep guessing at. The rate cap didn't solve the underlying bug, but it kept a confused model from turning a small parsing issue into a large, unnoticed bill while the actual fix was still being worked out.