One in Five Enterprises Can't Stop Runaway Agent Spend

By Lazar Milicevic · Published October 22, 2026 · 12 min read

Your agent just looped on a failing tool call overnight, and the first sign was the invoice. Or maybe you haven't had that night yet, but you've shipped an agent with an API key and a prayer, and you're not sure what stops it if something goes wrong. This post covers what the data says about how teams control agent spend, what each major provider's caps actually do (and don't), and a layered design you can build in a weekend.

What the VB Pulse data says, and what it doesn't

VentureBeat's Pulse research found that 21% of surveyed enterprises can't stop an AI agent's spending in real time. The survey covered 107 enterprises. In the September 2026 wave, that 21% breaks into 11% who monitor spend only after the fact and 10% with no specific controls. A further 12% don't know how spending is controlled at all (VB Pulse Agentic Orchestration Report, September 2026).

A few caveats before you quote that number anywhere:

• It's a small panel. 107 organizations from VentureBeat's own Pulse panel, not a representative study. Don't read "one in five" as a statistic about all businesses, and certainly not about small ones.
• It varies by wave. An earlier August Pulse put the after-the-fact-only figure at 23% of platform users, and a July wave also reported 21% across all respondents. Compare figures only within the same wave and read each one against its own sample.
• Size didn't help much. Among enterprises with 10,000+ employees, 18% use only reactive control, versus 23% of smaller ones. Being big doesn't buy you a kill switch (source).

The context matters too. Per the same survey, 85% of enterprises use two or more orchestration tools and only 15% run a single platform. The median enterprise runs three. Microsoft AI Foundry/Copilot Studio appears in 70% of stacks, OpenAI's Agents SDK in 68%, and Anthropic's Claude Platform in 47%.

That last point is the real engineering problem. If spend is spread across three platforms, each with its own budget mechanism, "set a cap" isn't one action. It's three different mechanisms with three different failure behaviors, and nothing that sums them.

Builders' top concerns when choosing a platform, from the same survey: security and permissioning limits (37%), vendor lock-in (23%), limited visibility and observability (22%), and inflexibility around models and tools (16%). I'd read that as distrust in what vendors let you control, which is narrower than "distrust of vendors" in general. I wouldn't call it a measured trust statistic.

On how teams control spend today, one wave reported 30% relying on native platform controls and 25% on custom gateway or proxy middleware, with 21% on reactive monitoring only. The September report breaks it down differently (19% platform-built, 17% custom middleware or proxy). The waves differ, so I'm not going to blend them. The pattern is consistent either way: a minority of teams build their own enforcement layer, and a similar-sized group has only post-hoc logs.

Why agents overspend: the failure modes

Agents don't overspend because the model is expensive per token. They overspend because a loop has no natural stopping point. Here are the failure modes I see most often when reviewing agent setups:

1. Retry loops. A tool returns an error, the model "reasons" about it, calls the tool again with slightly different arguments, and repeats. Each iteration resends the growing context.
2. Context bloat. Every step appends to the conversation. Cost per step rises as the run gets longer, so the last ten steps cost more than the first fifty.
3. Fan-out. An orchestrator spawns sub-agents that each spawn their own. One user request becomes dozens of parallel model calls.
4. Unbounded inputs. Someone feeds a 400-page PDF or a huge repo into a workflow designed for one-page documents.
5. Scheduled jobs with no owner. A cron-triggered agent keeps running after the person who built it moved on.

Notice that none of these look like "attack" or "bug" at the provider level. Every request is valid, authenticated, and within rate limits. That's why rate limits alone don't solve this: they cap how fast you spend, not how much.

What each provider's caps actually do

Provider-native limits are your last line of defense, not your first. They're coarse (per org, per project, per workspace) and enforcement semantics differ. Here's what the official docs say.

OpenAI

Hard spend limits can be set monthly at the organization or project level. When reached, affected API requests return a 429 with organization_spend_limit_exceeded or project_spend_limit_exceeded. Enforcement isn't instantaneous, so recorded spend can slightly exceed the limit. Spend alerts only notify and don't enforce anything (OpenAI spend limits docs).

Practical implication: a per-project hard limit is a good blast-radius container. Give each agent (or each client) its own project and its own cap, so one runaway doesn't take down everything else.

Anthropic

Anthropic has several overlapping layers, and they behave differently:

• Usage tier caps. Monthly spend caps by tier: Start $500, Build $1,000, Scale $200,000, none on Custom. When you hit one, usage pauses until 00:00 UTC on the first of the next month. You can set your own lower limit, which returns HTTP 400 with invalid_request_error when reached; your limit can't exceed the tier cap (rate limits docs).
• Workspace limits. Console workspaces can have their own monthly spend limits, except the Default Workspace. Organization-wide limits always apply, even if workspace limits add up to more (workspaces docs).
• Managed Agents session budgets. An optional hard spend ceiling set at session creation. The platform prices usage at public list rates and stops issuing new model requests once the budget is reached (budgets docs).

The session budget is the closest thing to a per-run cap I've seen from a provider. Two details to design around: it's checked between model requests, so a session capped at 50 cents can pause at 53 cents, and the session goes idle with stop_reason: budget_reached rather than terminating. The amount is a string of whole US cents ("125" is $1.25), USD is the only supported currency, and you can only attach a budget at session creation (sessions docs). Managed Agents is in beta, so check the docs for current behavior.

Comparison

For Azure, Google Cloud, and AWS, I'm deliberately not making claims here. I've seen secondary-source write-ups on newer spend-cap features from each, but I haven't verified them against official docs, so check each vendor's current billing documentation before you rely on them.

The layered design: what to build yourself

Provider caps are monthly and coarse. A runaway agent can burn a month's budget in an hour, and "monthly cap reached" means every agent on that key stops, including the healthy ones. You need enforcement closer to the agent. Here's the stack I'd build, from innermost to outermost.

Layer 1: per-run budget inside the agent loop

The cheapest, fastest control is a counter in your own code. Track tokens (or estimated dollars) per run and bail out when you cross a threshold.

import time

class RunBudget:
    def __init__(self, max_usd: float, max_steps: int, max_seconds: int):
        self.max_usd = max_usd
        self.max_steps = max_steps
        self.deadline = time.monotonic() + max_seconds
        self.spent_usd = 0.0
        self.steps = 0

    def charge(self, input_tokens: int, output_tokens: int,
               in_price_per_mtok: float, out_price_per_mtok: float):
        # Prices come from your provider's current pricing page; don't hardcode guesses.
        self.spent_usd += (input_tokens / 1e6) * in_price_per_mtok
        self.spent_usd += (output_tokens / 1e6) * out_price_per_mtok
        self.steps += 1

    def check(self):
        if self.spent_usd >= self.max_usd:
            raise BudgetExceeded(f"usd cap: {self.spent_usd:.2f}")
        if self.steps >= self.max_steps:
            raise BudgetExceeded(f"step cap: {self.steps}")
        if time.monotonic() >= self.deadline:
            raise BudgetExceeded("time cap")

class BudgetExceeded(Exception):
    pass

Call check() before every model call, not after. Three limits (dollars, steps, wall-clock) catch different failure modes: dollars catch context bloat, steps catch retry loops, time catches hung tools.

Layer 2: a gateway that sees everything

The builders who wrote custom gateway or proxy middleware are onto something. If you run agents on more than one platform, a thin proxy in front of all model calls gives you one place to meter spend, attribute it to an agent and client, and cut it off.

A minimal version is a service that:

1. Receives the model request with an agent_id header.
2. Looks up the agent's remaining budget in Redis or Postgres.
3. Rejects the call (HTTP 429 from your service) if the budget is gone.
4. Forwards the call, reads usage from the response, and decrements the budget atomically.

# Example budget policy, one entry per agent
agents:
  invoice-triage:
    daily_usd: 5
    per_run_usd: 0.50
    max_concurrent_runs: 3
    on_exceed: pause_and_notify
  lead-followup:
    daily_usd: 10
    per_run_usd: 1.00
    max_concurrent_runs: 5
    on_exceed: pause_and_notify

The numbers above are placeholders to show the shape, not recommendations. Derive yours from a week of observed baseline spend, then set caps at a modest multiple of normal.

Two design notes. First, make the decrement atomic. If two parallel sub-agents both read "$1.00 left" and both proceed, you've overspent. Second, expect overshoot of one in-flight request, the same way the provider-side caps do. Reserve an estimated max cost before the call and reconcile after.

Layer 3: approvals for the expensive and irreversible

Not every limit should be a hard stop. Some actions deserve a human click: spawning more than N sub-agents, running a job on an unusually large input, any step that sends money or external email. A simple pattern is a budget "soft threshold" at, say, 50% of the per-run cap that pauses the run and pings Slack or email with approve/deny buttons. Approved runs get a raised cap for that run only.

This is also where Anthropic's budget_reached idle state is useful: the session doesn't die, so a human can inspect it and decide whether to continue.

Layer 4: provider caps as the backstop

Now set the provider-native limits, one project or workspace per agent or client, with caps comfortably above your gateway's daily limits. If your gateway has a bug, the provider cap contains the damage to that one agent. If you use alerts (which only notify), pair them with a hard limit; an alert on its own stops nothing.

Layer 5: a kill switch you've actually tested

A kill switch is a boolean your agents check on every loop iteration, stored somewhere you can flip from your phone.

# Flip the global kill switch (example using Redis)
redis-cli SET agents:kill_switch 1

# Per-agent
redis-cli SET agents:lead-followup:paused 1

Test it quarterly the same way you'd test a backup restore. A kill switch you've never flipped is a hypothesis.

Observability: you can't cap what you can't attribute

Per the survey, limited visibility and observability was a top-three platform concern (22%). Even with caps in place, you need to answer these questions in under a minute:

• Which agent spent the most in the last 24 hours?
• What was the cost of the most expensive single run, and what did its trace look like?
• Which client or workflow does this spend belong to?

Log one structured record per model call: agent_id, run_id, client_id, model name, input and output tokens, computed cost, latency, and step number. Dump it to Postgres or even a SQLite file if you're small. Then build exactly two views:

-- Spend by agent, last 24h
SELECT agent_id, SUM(cost_usd) AS usd, COUNT(DISTINCT run_id) AS runs
FROM model_calls
WHERE ts > now() - interval '24 hours'
GROUP BY agent_id
ORDER BY usd DESC;

-- Top 10 most expensive runs
SELECT run_id, agent_id, SUM(cost_usd) AS usd, MAX(step) AS steps
FROM model_calls
GROUP BY run_id, agent_id
ORDER BY usd DESC
LIMIT 10;

Set an alert on the rate of spend (dollars per hour above a multiple of the trailing baseline), not just the total. A rate alert fires within minutes of a loop starting; a total-spend alert fires after the damage.

A weekend plan for a solo builder or small team

If you have one or two agents in production and none of the above, here's the order I'd do it in:

1. Today, 30 minutes. Create a separate provider project (or workspace) for each agent or client and set a hard monthly limit on each. Add alerts too, knowing they only notify.
2. Today, 1 hour. Add the RunBudget check to every agent loop with dollar, step, and time caps. Fail loudly.
3. Tomorrow, 2-3 hours. Add per-call logging with agent_id and run_id. Build the two SQL views.
4. Tomorrow, 2-3 hours. Add the kill-switch flag and a rate-of-spend alert.
5. Next week. Put a gateway in front if you run more than one provider. Add approval flows for the expensive paths.

If you can only do one thing: step 2. A per-run cap in your own code is the control that stops a loop in seconds, not days.

One more reason to bother. Gartner predicted in a June 2025 press release that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls (Gartner). Two of those three reasons are things a cost-and-controls layer directly addresses.

What I'd still be skeptical about

• Provider caps will keep changing. Several of these controls are new or in beta (Managed Agents is explicitly beta). Re-read the docs each quarter; semantics like "does the session terminate or idle" matter for how your code reacts.
• Cost estimation is approximate. Your computed cost may diverge from the invoice because of caching discounts, tool-call surcharges, or pricing changes. Reconcile weekly against actual billing.
• Caps trade availability for safety. A tight cap can stop a legitimate long-running job. Pair every hard stop with a notification and a documented way to raise the cap for one run.
• The survey is a snapshot of a small panel. It tells you reactive-only control is common among enterprises that answered; it doesn't tell you your risk. Your risk is a function of how many loops you run unattended.

How I build this in practice

Cost caps, approval gates, and observability are how I build every production agent: per-run and per-day budgets enforced in code, provider-level limits scoped per agent or client as a backstop, structured per-call logging so spend is attributable, and a tested kill switch. I'd rather add them before the first incident than after it.

I work with solopreneurs and small teams who don't have a platform engineering group to set this up. If you have agents running, or about to run, and you're not sure what would stop one that goes wrong, the weekend plan above is a good place to start.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.