Before you cap your AI spend at all, the first thing to do to get the Claude bill under control is understand exactly where the spend is coming from. From there, you can evaluate whether that's "good" usage for you and set caps accordingly. When someone hits the cap, deciding whether they get more is both a data conversation and a human one.
Good usage means something different at every company: saving time, good feedback from the team, or a business outcome where the return on investment (ROI) is positive on the spend. Often the AI project comes with a piece from the CFO: limit our spend.
1. Before you cap AI spend, think about your power users
When IT or another department designs token caps, it usually starts from a top-down budget. Finance says you have a certain amount to spend, you allocate to engineering, then to ops teams, and everybody else gets what they get. For example, if you have a $100,000 token budget and engineering gets $70,000 of it, the other $30,000 gets split over everybody else, and the peanut butter gets spread pretty thin.
The trouble with that is that it takes a fair amount of time to design and implement, especially by hand in Claude. And it doesn't necessarily match the way individuals work today, or the potential they have if they really transform their job function with AI.
Imagine a sales rep who's a terrific citizen builder but hits their usage limit by 10am. From time to time they'll ask their manager for more tokens, and the manager will always say yes.
That loop, where the individual has to make the request, adds a lot of friction and is a really negative experience. It slows down that person's transformation, and if they're leading the way, it slows down the function's.
What not to do: set the cap by following the budget and trying to hit a number, without thinking about the work each person is doing.
There's a better way, and it starts with knowing whose token usage is accretive to the business and who's token-maxxing, burning tokens to burn.
2. Know who spends your AI budget, and on what
The goal of this step is to know who or what drives your spend before you set a single cap: one or two individuals, a whole team, or something running on its own.
In Claude's Analytics settings, the Export spend report gives you one row per person per model, with the product (Chat, Claude Code, Cowork, or Office Agents), tokens, and spend, for month to date, last month, the last 90 days, or a custom range. Owners and Primary Owners can see spend, and on Enterprise, Admins see everything except spend.
A usage-based Enterprise plan also gets per-user cost from the Analytics API. A seat-based plan shows spend only if you've turned on usage credits, and then only the spend beyond your seat allotment.
From there, we recommend separating the power users from the rest of the pack. On non-engineering teams, typically 80 to 90% of people will have relatively low usage, because they haven't truly built skills and agents to get their job done. A couple of people will be doing that building, and you want to treat them differently.
Find them first by raw volume of usage, then by the style of that usage: whether what they build is relevant to their job, gets reused, and drives the right outcomes. Claude's Analytics page shows you the volume but not the style: it counts skill uses, connectors, and pull requests, not what the work was for. The intent and the output of the work come through the endpoints and emitters Anthropic makes available, and that's where SightLift comes in.
3. Then cap most people at the median and power users higher
Give the 80 to 90% the median, or the median plus a little, so they don't hit the cap regularly, and reserve the rest of the budget for your power users. Most of the field won't use their allocated budget in the first place, so they can do with less to enable the people building. Giving your power users higher token budgets, so they look more like engineers from a budgetary standpoint, is often the first step to transforming the function.
Power users who are just burning lots of tokens are a conversation. Burning tokens looks like heavy volume with nothing reused and no plan finished. Productive work looks like skills and agents the team reuses that move a business number. Figure out whether you can get them building the right stuff in the right way, or whether they'll end up more like the median once they change their usage.
4. Use a light human-plus-data process for overage requests
People are still going to hit the cap. When they do, keep the process light, with two halves: the data on how they've used their tokens this month, and a conversation about what they want the extra tokens for.
The human half is intention. You want the person requesting more tokens to have a purpose for them beyond more, more, more.
We recommend that every request name the task the person is working on and the business result it ought to drive. Whoever gives out tokens (management, central ops, or IT) can calibrate whether the intention is valuable, then match it with the data on what the person is actually doing. People often have grand intentions, but maybe their aim is a little off.
Here's a good request from a sales rep, and a bad one:
| Request | Task | Business result |
|---|---|---|
| Good | Building a skill to automate finding new contacts at existing accounts | Capture new points of contact automatically and enrich the data about them |
| Bad | "I need more to do my job" | "Hit my numbers" |
With a request like the good one, you can profile what they're doing in Claude and evaluate how much progress they're making toward that goal on the budget you gave them:
- Burned through the budget without even completing a plan: they may need coaching on model usage, or a whiteboard session with their manager before they go back to the console.
- A good version of the skill already: great, keep going, and send them back to work.
- Transformative work done inefficiently: give them more tokens, and coach them to economize their token usage with model optimization going forward.
The bad one isn't a very helpful statement. If someone uses that much of their cap just to do their job, either they're doing something pretty unusual or, if other people on the team hit the cap all the time too, the cap is wrong. Either way it's a good conversation.
5. Run the cap worksheet before finance sees the bill
| Step | What you do |
|---|---|
| 1. Pull spend | Total spend by day and by person, rolled back up to the total |
| 2. Find the power users | Separate the 80 to 90% with low usage (typical on non-engineering teams) from the few building skills and agents, by volume first, then by whether what they build is relevant, reused, and accretive |
| 3. Set two caps | The median, or a little more, for the field; a higher cap for power users doing the right thing; a conversation for power users just burning tokens. Or start with one consistent cap for the whole company |
| 4. Turn on the alert | Wait and see who hits the cap; the alert triggers the overage conversation |
| 5. Run the overage conversation | Collect the task and the business result, check month-to-date usage, then decide on more tokens and coach on efficiency |
| 6. Reset the cohorts | Rerun this analysis monthly or quarterly, depending on how fast your organization moves |
| 7. Report to finance | The total, tied out to the dollar; if you're over, where it went, who spent it, what it bought, and when you'll report on the result |
Each time you reset your cohorts, you'll see new power users pop up, and the overage conversation is a way to find them as they have their first "AI moment."
At the end of the month, finance will be looking at the bill. You need to hand them a number that ties out in dollars, and if you're over, know where the budget went and have a thoughtful, defensible statement on why.
That means being able to say a certain person went over by $500, and that with that $500 you got a skill everybody now uses to do part of the job better and more efficiently. You believe that by the end of the quarter it will give you a certain lift in the business, and you'll report back on whether it did.
We recognize this is a lot of work, and that's exactly why we built SightLift.