Should you cap your team's AI spending?

There is an ongoing debate in many software companies right now about how much AI usage to encourage and how to manage AI usage. Some large companies have started evaluating their employees based in part on token consumption, treating a bigger number as a better one. In a few hastily-adjusted cases, there were even token usage leaderboards available internally for people to see how they stacked up to their peers. Others have started moving in the other direction: after finding that they have blown through their annual AI spend forecasts in just a quarter or two, some companies are putting in place strict budget caps (e.g., “each employee gets $X/month in usage credits”). We get a version of this question a lot, from founders we talk to and from teams inside companies we work with: should there be a fixed, immovable cap on employees’ AI spending?

Our answer is no. To be clear, rewarding people solely based on how many tokens they have burned is plainly a bad idea. (See Goodhart’s law.) It incentivizes activity that, along with being costly, probably includes a lot of waste that is created solely for the purpose of chewing up tokens and has no actual value. We do not want people to be spending without thought. But putting in a strict, low cap and applying it to everyone, including engineers using AI to write/test/debug code, isn’t helpful either. When managed well, token spend, even for an engineer using AI as part of their daily work, is typically small next to the overall cost of the person doing the spending. If you set a tight cap to save a few hundred dollars a month on a senior engineer’s tooling, and if it slows that engineer down even slightly, you’ve economized on the cheap input and taxed the expensive one. The engineer’s time and attention are scarce. By comparison, tokens are cheap and abundant.

We want our engineers to experiment with the latest models and their engineering harness’s latest capabilities. We want the sales team to find new ways to analyze win/loss data and diagnose how we can improve close rates. We want the customer success team to identify new signals for catching customers who are becoming non-renewal risks before it is too late to do anything about it. We don’t want anyone flying too close to the sun — that’s when the risk/reward balance is probably wrong (a topic for another day) — but we do want people to feel empowered to use AI tooling, without trying to calculate how much of their monthly token budget will get eaten up if they try something new. If seeing whether their latest experiment succeeds or fails spectacularly makes them enjoy their day a little bit more (and maybe automates a rote task or two for them in the process), all the better.

Timing is the other reason, and it is specific to right now and the foreseeable future. The tools, adoption patterns, and pricing are all still moving. Vendors are actively changing how they charge and how much they charge, the vendors we prefer today may not be the vendors we prefer in six months, and — most importantly — overall model capabilities are advancing quickly. A rigid internal cap set against today’s tooling stack is premature optimization against a figure that may have moved by the time the cap is set.

So we favor budget flexibility as it relates to AI in the near term. At some point, we presume things will settle down and having a more defined budget will be practicable, but that might be years from now. In the meantime, the position we’ve settled on is to fund thoughtful use, refuse to reward raw consumption, and leave room for people who have found real leverage. When someone’s usage jumps, our instinct is curiosity rather than concern or suspicion. We want to know what they figured out, because it might be something worth copying and spreading to the rest of the team.