Spend control

What it is

A mechanism that bounds how much an agent is allowed to consume, in dollars, tokens, or iterations, before a human has to look at it or the run simply stops. Two different answers show up in practice. One is visibility: track spend, surface it, and let a person decide when something looks wrong. The other is a hard ceiling: a ceiling an agent cannot cross on its own, no matter how the run is going.

Why you need it (in a large team)

• Nobody has to teach an agent to feel bad about burning tokens. Left alone, it will retry a failing CI run, keep expanding context, or run for hours past the point a human would have given up and asked for help. At small scale that's a rounding error on a bill.
• Uber's own account of the problem states it as arithmetic, not a hunch. Spend equals users, times sessions per user, times turns per session, times requests per turn, times tokens per request, times price per token. The first two terms are adoption, the thing everyone actually wants to grow. The rest is what the agent does on its own initiative once it's running.
• The uncomfortable part: growing adoption is the goal and the risk at the same time. Multiply all of those terms together and the more successful the rollout, the faster the other terms compound, not slower.

How it should work

The instinct that shows up most often isn't to block first, it's to make spend visible and let a human decide. Uber keeps a live cost counter in the harness status line, tracking spend per harness and in total, and fires Slack alerts at 50, 80, and 100% of expected spend, explicitly so engineers "have time to plan" rather than getting cut off mid-task. Shopify runs the same logic without a fixed number at all: no per-team token budget, on principle, but a session that's been burning tokens for hours (reported as a check around the ten-hour mark, or a $250-a-day threshold, depending on the source) triggers an alert asking whether the spend was intended.

Where a hard ceiling does show up, it's usually reserved for the case where the downside is real money moving, not developer time. Ramp's coding agent gets the visibility treatment, but its separate agent handling actual payment decisions is staged: shadow mode against production requests first, then running alongside human risk operators, and only then a metrics-gated "exposure budget" that caps the dollar volume and the kinds of operations it's allowed to decide on its own. The ceiling exists because the failure mode there isn't a wasted CI run, it's money leaving the company.

Shared tiers beat per-tool budgets for the same reason a single gateway beats point-to-point integrations elsewhere in this project: Uber runs one shared spend tier across every interactive harness rather than tracking each tool's budget separately, and escalating to a higher tier needs a manager's sign-off, described as quick rather than as friction for its own sake.

None of this replaces someone actually going and looking for waste. A running total doesn't catch a cache-hit ratio quietly sitting at 30% against an expected 80%, or token spend leaking into plan names, terminal window titles, and recaps generated for idle sessions, both of which Zalando only found because two separate tools were pointed at the problem on purpose, not because a dashboard flagged them.

Where it fits into a software factory

Like the MCP gateway, this isn't one of the five activities a factory gets scored on. It's a constraint that sits underneath whichever of those activities agents are actually doing: background agents opening PRs, reviewers reading diffs, migration scripts touching a live system. Every one of those gets cheaper to run and easier to trust once volume goes up, which is exactly why nothing in this list works safely at scale without something watching what it costs. Skip it, and the same success that makes a background agent worth having, more sessions, more adoption, is the thing that makes the bill unpredictable.

What you should look for when deciding on one

• Visibility or a hard ceiling, decided up front. Tie that choice to what actually breaks if it runs unchecked. An agent burning extra tokens on a retried CI run is a cost problem; an agent deciding whether to move money is a different kind of problem, and Ramp's staged escalation into a metrics-gated budget only for the second case is the right instinct: match the mechanism to what's actually at stake, not to whichever is easier to build.
• One shared tier, not a budget per tool or per team. Uber's is deliberate, and the alternative is the same drift this project keeps finding wherever enforcement gets scattered across many separate integrations instead of one place.
• Someone actually looking for waste, not just a total. Zalando's two clearest findings, cache-hit ratio and idle-session token spend, were both invisible to a simple running total and only surfaced once someone instrumented for them specifically. A spend dashboard answers "how much," not "how much of that was wasted," and those are different questions requiring different tooling.

Companies using spend control for AI agents

CloudflareAI Gateway routes every request, cost per session and per review tracked and optimized down 68%Rampstaged from shadow mode to a metrics-gated budget, but only for the payments agentShopifyphilosophically opposed to per-team limits, alerts on runaway sessions insteadUbercost decomposed into six multiplied terms, published as the stated reason to actZalandofound real waste (cache-hit ratio, idle-session spend) only by auditing for it directly

Stripe isn't in this roster: its two-round cap on CI iterations bounds how many attempts a minion gets, not what it costs, a narrower and cheaper problem to solve than the one this pattern is about.