Two controls get sold under the same promise — "we cap your agent spend" — and they are not the same control. One is a billing fence at the provider, checked against a monthly total. The other is a refusal in the call path, evaluated per agent before each call spends. The LangChain loop case — roughly $47,000 over about 264 hours — is what the difference looks like when it matters.
The short answer
Use both, for different jobs. Provider caps (OpenAI, Anthropic, Google all offer free, customer-set monthly caps) are the outer fence: coarse, monthly, single-provider, and reactive — they stop traffic at the line, after lag and overage. Per-agent refusal is the inner control: a gateway evaluates each call against that agent's own ceiling before the call executes, across every provider the agent can reach, and refuses the call that would cross it. Provider caps bound the invoice. Per-agent refusal stops the loop.
The comparison
| Dimension | Provider caps | Per-agent refusal (gateway) |
|---|---|---|
| Granularity | Organization, project, or workspace — never per agent | Per agent identity, per tool, per run |
| Clock | Monthly billing period | Every call, in real time; daily and monthly ceilings |
| Scope | That provider only | Every provider and tool the agent routes through |
| When it acts | Reactively — documented lag and overage while long sessions run | Before the call spends; the crossing call never executes |
| Failure shape | A loop spends through the lag; a shared key makes one agent's loop everyone's outage at the cap | The loop stops at its own ceiling; other agents keep working |
| Cost | Free — set them today | The gateway layer (free tier to start) |
When provider caps are enough
When one agent, one provider, and a human watching spend daily describe your whole setup — the cap is a sane backstop and there is little left to refuse. The shape that breaks caps is the normal production shape: several agents, shared provider accounts, long-running sessions, more than one model vendor. At that point the cap cannot tell you which agent is burning, cannot stop one agent without stopping all, and cannot act inside the billing period's lag. Sizing the caps themselves is covered in our spend caps guide.
What per-agent refusal needs to work
Three ingredients. Identity: each agent carries its own credential, so spend attributes to an agent, not a shared key. Estimates: the gateway cannot price a call it has not seen — every authorization request carries an estimated cost (token counts × model price for LLM calls, fixed prices for tool calls) that the policy layer sums against the ceiling. Fail-closed posture: a call that cannot be evaluated does not run. Estimates are approximate; the control still works because loops are orders of magnitude off normal, not percentages.
And keep the boundary clear: caps bound dollars, not damage. A single call to a destructive tool costs pennies and can be worth more than any bill. Refusal handles the spend; allowlists and approval queues handle the blast radius.
And the caps themselves size better from a trajectory than from a guess: budget burn forecasting projects the monthly bill from the live burn rate, which is how the outer fence and the inner ceilings get numbers worth enforcing.
Check your own setup against both layers: the free Spend Guard self-check names the gaps in five questions.