Set an AI Coding Budget Your Team Keeps
Why per-seat caps break on agentic workloads, how to budget by workload instead, and the weekly fifteen-minute review that keeps the number honest.
Every team that adopts Claude Code writes the same line into its budget: "$X per developer per month." Three months later, that line is either ignored or fought over — because agent spend doesn't behave like a per-seat cost. It behaves like a workload cost. This post is the budget that survives contact with how agents actually bill.
Disclosure up front: I operate Teapot Router, a team gateway for GPT and Claude Code with per-key quotas and org-level spend rollups. The method below works on any endpoint that meters per request — nothing here depends on using ours.
Per-seat caps break first
A flat cap per developer is the first budget everyone tries and the first one that fails, for a structural reason: agent spend varies by assignment, not by person. The same developer can run 5x their normal spend for one week purely because the task changed — a big refactor with hundreds of turns, or a codebase with poor cache behavior. The cap punishes the workload, not the person, and the three standard failure modes follow:
- The cap strangles the heavy assignments — the exact work that justified buying the tools in the first place.
- The cap never binds on light users — so the average means nothing and finance stops trusting the whole line.
- Enforcement lands in spreadsheets, weeks late, when the money is already spent and the argument is already stale.
Budget the workload, not the seat
Take the three variables that actually decide agent spend — turns, re-sent context, cache hit rate — and allocate against them at team scale:
- Model per-dev monthly cost from real shape, not averages: daily turns × context size × cache behavior. Two weeks of observed data beats any industry benchmark.
- Allocate by project or task class, not by headcount: boilerplate-heavy maintenance and hard architectural work deserve different lanes, and routing them accordingly is the biggest honest saving.
- Set caps at the 80th percentile of observed shape, not the mean — a cap the workload hits in a normal week is a cap nobody respects.
Enforce where the metering happens
A budget enforced in a spreadsheet is a wish. The requests are already metered somewhere — model, tokens, cache hits, cost, per request — so the budget should live in the same place: per-key quotas that throttle instead of silently overrunning, alerts on anomaly rather than on every line, and an org-level rollup so finance sees one number that reconciles with the invoice. When the thing that bills you is also the thing that enforces the budget, the budget stops being an argument.
The fifteen-minute weekly review
Three questions, once a week, keep the budget alive: Is the cache hit-rate trend flat or sliding? Which key or project moved the most, and did the workload actually change? Does the cap need rebalancing before someone hits it for a legitimate reason? This is not a meeting — it's a glance at a ledger with three columns, and it replaces the quarterly fire drill entirely.
Budgets fail when they're guesses enforced by spreadsheets. They hold when they're models of the real workload, enforced where the metering already happens, and corrected weekly in fifteen minutes instead of quarterly in a fire drill.
FAQ
How much should we budget per developer?
There is no universal number — model your own shape (daily turns, context size, cache hit rate; the calculator at teapotrouter.com/en/claude-code-cost-calculator does the math), observe two weeks, and cap at the 80th percentile of what you actually saw.
What happens when someone exceeds their budget?
The key throttles and an alert fires — no drama, no shame. An overage is information about workload shape: either the assignment changed, the caching degraded, or the cap was a guess. All three are fixable in the weekly review.
We're on subscription plans — does this still apply?
Plans are the right call for some shapes (the break-even math is its own topic), but they hide per-request data, which means no audit trail. If your finance needs the line items, usage-based metering is the only format that reconciles.