Three dials labeled cap, alert and coach above a stack of agent sessions

Cap, alert or coach: how to govern coding-agent spend

A spend cap limits the bill. It can't tell you what the capped spend bought. When each of the three levers fits, and what each one misses.

Governing coding-agent spend comes down to three levers. A cap puts a ceiling on spend. An alert flags a sudden spike so someone looks. Coaching looks at what the spend bought and changes how the work is done. A cap bounds the bill and an alert catches runaways. Only coaching changes what next month's spend buys.


What a spend cap can and can't do

Caps are easy to set up. Claude Code's cost docs, for example, describe how Team and Enterprise admins can set spend limits "at the organization, group, or individual member level." You can switch one on in an afternoon.

A cap answers one question: what's the most this can cost? It can't say what the money bought. A cap only binds on your heaviest users, and that group mixes two kinds of people: engineers getting a lot done with the agent, and engineers whose sessions keep looping. The cap can't tell them apart. It stops both, and usually in the same week of the month.

Two more side effects show up quickly. A ceiling of $1,000 a month starts to read as an allowance of $1,000 a month. And if raising a limit takes a ticket and a few days, people stop handing the agent the hard tasks, which are usually the ones where it pays for itself.

The useful data a cap produces is its exceptions log. Who asked for more, and what were they doing? That list is your first coaching agenda.

Each lever fits a different risk

Cap when the risk is the total

A cap fits a pilot with a fixed budget, contractors, a tool you haven't priced yet, or any spend nobody reviews each week. Treat it as a backstop. A reasonable starting rule is about twice your heaviest normal month, per person and per tool, so ordinary heavy use never touches it. Make raising it take minutes.

What it misses: whether the spend under the ceiling was any good.

Alert when the risk is a runaway

An agent stuck in a loop overnight, or a session that rereads a huge context on every turn, can run up a bill while nobody is watching. Alert on a jump against the person's own baseline, because a fixed dollar level fires every week for your heaviest users. Something like three times that person's typical daily spend is a reasonable first threshold. Send it to the engineer first, because the person who ran the session can usually explain it in one line.

What it misses: steady overspend. A team can spend twice what it should every day without setting one off.

Coach when the risk is that spend isn't working

Once agents are part of daily work, most of the bill is ordinary sessions, not spikes. Coaching means looking at the sessions behind the bill on a fixed schedule, say monthly, and giving finance two numbers to watch:

  • Spend per authored pull request for each team: the period's agent spend divided by the PRs that team authored.
  • Share of spend in heavy-rework sessions: sessions that redid their own work, as a percentage of the total.

Behind those sit the questions that lead to fixes: which kinds of work cost the most, whether a premium model is doing routine edits, and how often engineers stop the agent to correct it. Read them by repo and team, not by person. A repo where most of the spend sits in rework sessions usually needs a missing instruction or a broken test fixed.

What it misses: a runaway tonight. That's the alert's job.

Pick by the question you're asking

  • "We might blow the budget." Set a high cap as a backstop.
  • "Something might run away overnight." Add a spike alert.
  • "We spend a lot and can't tell if it's working." Coach, and report the two numbers above.
  • "Some people shouldn't have this tool yet." That's about access, not spend. Decide who gets it first, then use the levers for everyone who does.

Worked example: the cap that raised cost per PR

Fernhollow Freight is fictional. It has 40 engineers and spent $54,000 on agents in a month while authoring 270 PRs, or $200 per PR. About 30% of that spend, $16,200, sat in heavy-rework sessions.

After a surprise bill, finance asks for a $1,200 cap per person per tool. The next month spend falls to $43,200, but authored PRs fall to 200. Cost per PR goes up to $216. Six engineers, each of whom usually spent about $3,000 a month in their main tool, hit the cap by the second week and did the rest by hand. The $1,800 each of them couldn't spend, times six, is the $10,800 drop. One of them owns the payments service, where most sessions end in rework because a test fixture is out of date. The cap cut the waste and the useful work together.

The lead changes course. She raises the cap to $6,000, about twice the heaviest normal month, so only a runaway would reach it. She adds a spike alert and spends an hour with the payments team fixing the fixture and adding a short repo instruction. The month after, spend is $50,400 across 280 PRs, or $180 per PR, and the rework share is down to 15%, about $7,560. The bill is lower than before the cap, and so is the cost of each PR.

What Uber, Shopify and Amazon chose

As of November 2026, public reporting gives one example of each lever.

  • Uber capped. In June 2026 Bloomberg reported, and TechCrunch followed, that Uber had capped spending at $1,500 per employee per month for each agentic coding tool, such as Claude Code and Cursor, and that the cap could be exceeded with permission. TechCrunch also noted that Uber's CTO had said in April, as The Information reported, that the company had used up its annual AI budget in four months.
  • Shopify trips a breaker on spikes. In an April 2026 issue of The Pragmatic Engineer, Shopify's head of engineering, Farhan Thawar, said the company can cut off a person's access when their spend spikes within a day, and the developer can renew it if the spike was deliberate.
  • Amazon chose judgment over caps. On October 27, 2026, CNBC reported that an internal Amazon memo on AI use, posted to its website that day, calls token usage, adoption rates and code changes or reviews "deeply flawed" ways to measure AI usage, and says token usage and code generation should be weighed "with care and judgment" alongside other data. A spokesperson said Amazon hasn't capped employees' token usage.

Access is a separate decision. On November 2, 2026, The Decoder, citing Bloomberg, reported that Goldman Sachs had cut most employees off from AI coding tools such as Claude Code, leaving them to engineers only. A spokesperson cited "productivity and risk management."

Where VibeCheck fits

VibeCheck doesn't set caps or send spend alerts. Your vendor consoles and cloud billing do that, and here's how VibeCheck compares with them. VibeCheck is for coaching. It captures Claude Code, Codex and Cursor sessions on each engineer's laptop and estimates each session's cost at published reference prices. Those are estimates, not invoices. It shows how much spend landed in heavy-rework sessions and, with the GitHub App connected, cost per authored PR. In Sessions you can filter to heavy rework, sort by cost and open any one to read what went wrong. Use it to find patterns, not to rank people; our tokenmaxxing post explains why.

The free plan covers up to five engineers. Team views and cost per PR come with Pro, at $30 per engineer per month billed annually. See pricing, or get started for free.

Ready to transform your engineering organization?

Start making data-driven decisions about your engineering processes with AI-powered insights.