Do You Cap Your Engineers' Token Budget, or Not?

If you run engineering at any scale, the bill for AI coding agents eventually lands on your desk, and it is larger than anyone planned for. Finance wants to know what you are going to do about it. Nine times out of ten, the answer is a cap: a monthly token budget, per engineer, the same for everyone.

I understand the reflex. You do not want the tap wide open only to find out, a quarter later, that you have spent tens of millions nobody signed off on. A cap feels like control, and control is what you are being asked for.

I have been in this debate for a while. It is now turning into a decision I actually have to make and defend, which is a different thing from having an opinion about it. The more I sit with it, the more I think both camps are partly right, and that is the part most of the argument skips over.

The case for a cap

Take the strongest version of it first, because it deserves more than a strawman.

The sharpest reply to the loudest “never cap your engineers” posts is usually a question: how many engineers do you have? At a few thousand engineers, an uncapped tap is ten or twenty million a month that nobody budgeted. Going uncapped is a luxury of small teams. At scale you cannot run a business with one line item that is unbounded and unwatched.

So the anti-cap purists are wrong when they wave cost away. Spend with nobody watching it is a real problem, and pretending otherwise is how you end up explaining a surprise to your CFO. That argument holds, and I am not going to pretend it doesn’t.

Where a flat cap goes wrong

Watch how engineers actually use these tools and they sort into roughly three groups.

• The first group fights the tool. They blame the model, distrust the output, and finish most of the work by hand anyway. Their spend is close to zero.
• The second group is careful. They approve every step and use the agent like a slightly smarter autocomplete. Their spend is small change.
• The third group is small. These are the people running agents overnight, rewriting their own tooling on a Sunday, working out how the whole building will operate eighteen months from now. Their spend is high, because they are doing the most with the tools.

Now look at what a flat monthly ceiling does to those three groups. It sails clean over the first two and lands on the third. You have built a control that leaves your low-spend engineers untouched and squeezes the exact people you are betting the future on.

And it hands them a signal that is easy to read. A capped power user tends to do one of two things. Some leave for a company that pays for their experiments. Others quietly rejoin the comfortable middle and stop pushing. You lose the people you brought the tools in for, either way.

You could object that “high spend equals high value” is just a flattering story power users tell about themselves. The numbers say otherwise. a16z recently pulled together figures from Ramp showing the top 10% of firms spend roughly fifty times more per employee on AI than the median. Fifty times, not fifty percent. A BCG analysis of 107 public companies found the top two quintiles of token usage posted meaningfully faster revenue growth than the rest. The heavy spenders are, disproportionately, the ones getting value out of the tools, which is what makes cutting them off first such an odd move.

The cost nobody puts in the spreadsheet

There is a second effect, slower and quieter, and I think it is the one that actually hurts.

Give someone a productivity mandate and a tight budget in the same breath, and you have handed them a contradiction. They resolve it the rational way. They spend their allocation to deliver, never to explore. Exploration is the first thing to go when the budget is tight, because it is optional, unmeasured, and has no ticket number attached.

This does not stop at the power users. It reshapes everyone. A flat cap turns the whole org into savers who protect their allocation, spend it only on what was asked, and stop poking at the thing that might change how the team works three weekends from now. You lose the small group inventing the future, and you also lose the conditions for a second such group to appear.

What the companies who have done this at scale actually do

I read a piece from Databricks that put numbers on something I had only been able to argue from conviction. They looked at how the earliest large-scale adopters manage this spend once agentic coding is deployed broadly, cross-checked against Stripe, Coinbase, Uber and Ramp.

The finding that matters: hard budgets, where usage is cut off at a threshold, show up only as a last resort in every company they spoke with. Two reasons. Cutting a developer off mid-task is simply debilitating, so nobody wins. And some of the highest spenders turn out to be the ones who achieved the biggest efficiency gains, so a blunt cap punishes the people who cracked it.

What they converged on instead is a ladder of friction that rises with spend, rather than a wall that stops it:

• Visibility. Near-instant feedback to each person on their own spend across all their tools, often with a nudge toward a cheaper model for the task. People cannot regulate what they cannot see, and it turns out most of them will once they can.
• Spend gates that escalate. The lightest is self-clearing: a prompt mid-task (“this has already cost you ten dollars, keep going?”) that you acknowledge with one click. It does nothing to real work and stops the runaway loop nobody meant to launch. Heavier gates ask for a real approval up the chain.
• Downshifting. When you hit a gate you get moved to a cheaper model, not suspended. The cheapest models cost a fraction of the frontier ones, so the work continues instead of stopping.
• Suspension, kept as the limit case. And even then treated as the start of a conversation about working efficiently, not a punishment.

The principle underneath fits in a line: preserve access, escalate friction. The system informs and nudges long before it blocks anything, and full blocking is a deliberate exception.

This is a different instrument from a cap, not a softer version of one. A cap asks whether you have spent too much. This asks whether you are spending well, and whether the people around you know what good looks like.

The reframe

The question in the title is a bit of a trap, and I set it that way on purpose.

“Cap or no cap” is a false binary. The uncapped purists are right that a flat ceiling teaches your best people the wrong lesson. The cap defenders are right that unbounded, unwatched spend is not a strategy. Both of those hold at once, and the useful answer sits between them.

The real choice is flat cap versus visibility plus differentiated budgets. Meter everything through one point so you can see the spend. Let friction rise with cost instead of dropping a wall at a round number. And stop pretending every engineer should get the same budget, because they are not doing the same work. The middle who will never notice the ceiling and the handful who would hit it in a week are not the same problem, and one number cannot govern both.

One more thing worth knowing before you set any number, because it changes where you should be looking in the first place. That same Databricks piece points out that when someone types “investigate and fix this bug,” the instruction itself is a handful of tokens. By the time the model runs, that instruction is a rounding error next to everything the agent pulled in on its own: the files it read, the tools it called, the context it assembled. Databricks reports that tuning the harness and cache settings alone cut token spend by nearly half, with no drop in quality, touching neither the model nor the prompt.

Which means a good share of the spend you are about to cap comes from the machinery around your engineers running untuned, rather than from the engineers being wasteful. Before you ration the people, it is worth checking whether the cheaper win is in the plumbing.

I will keep the same honesty I try to keep on all of this. Databricks sells the products it credits, and the savings figures are self-reported and directional, not a benchmark. But the pattern is corroborated across several companies, and it matches what I have seen firsthand.

So, do you cap your engineers’ token budget?

If the question is whether spend should go unwatched, then no, and anyone who tells you otherwise has not seen the bill yet. But if the instrument is a flat monthly ceiling applied equally to everyone, you are pointing a blunt tool at the wrong people and teaching your best engineers that curiosity is expensive. There are better instruments. They are just harder to put in a spreadsheet.