A 2027 AI coding budget your CFO will sign starts from what last quarter's tokens bought. Split that spend by team and kind of work, mark how much went into sessions that redid their own work, then price next year's planned work at those rates, add a visible growth line and set a target for the rework.
As of November 2026. The figures below come from reports published between June and October 2026. Vendor prices and plans change often.
Seat math broke this year
A per-seat budget was a headcount forecast with a price attached. That worked while the price was flat. It stopped working once coding agents started billing by the token, because spend per engineer now moves on its own.
Jellyfish's AI Engineering Trends report (October 2026) found that "the median company ended the third quarter at 98% of its first-quarter headcount while spending 3.8x as much per engineer." Headcount was flat. The bill wasn't.
Finance has noticed. In Pigment's Q3 CFO Index, released October 7 and based on 2,000 finance executives, 83% said consumption-based AI costs had pushed spending above expectations and 13% stayed within budget. The typical overrun was 11 to 25%.
Gartner predicted on June 24 that AI coding costs will surpass the average developer's salary by 2028. Its analyst Nitish Tyagi warned, as IT Brief reported, that "token discipline will not emerge through developer choice alone". And Uber, as PYMNTS reported on June 2, used up its AI budget for the full year by April, then capped spending at $1,500 a month per employee for each AI coding tool.
Multiplying seats by a growth factor is a guess at the slope of that curve.
Rework is the one line you can shrink without cutting the plan
Every other line in an AI coding budget tracks work you've already decided to do. Cut those and you get less of the work.
Rework is different. Some sessions redo their own work: the agent guesses, a test fails, it rewrites, it fails again. A session that rewrites the same change four times pays for it four times and leaves one change behind. The redo part of that spend can come down with no change to the plan, usually through something dull, like a missing repo instruction or a flaky test nobody owns. So give it a line of its own, with a target and a date. It's the only line in the budget where you promise a smaller number.
Build it in four passes
Pull last quarter by team and kind of work. Use your invoices for the total and your session data for the split. Some sessions do two kinds of work at once. Give each one its main kind, or scale the rows so they add up to the invoiced total.
Mark the rework. For each kind of work, how much spend sat in sessions with heavy rework? The share will differ a lot by row, and the row with the most rework dollars, not the highest share, is where to look first.
Attach drivers from the roadmap. You already have a 2027 plan in units of work: features, a migration, an on-call load. Give each row a volume factor from that plan.
Add usage growth as its own line. Jellyfish's 2027 budgeting guide calls "a flat monthly line" the riskiest assumption in a plan. Don't hide growth inside each row. Size it from your own per-engineer trend, show the trend, and keep the line separate so you can check it against actuals every month.
Fernhollow's 2027 budget, row by row
Fernhollow is a fictional 40-engineer company. Its agent spend in Q3 averaged $24,000 a month, or $600 per engineer. Per-engineer spend ran $480, $550 and $600 a month across Q1 to Q3, so growth is slowing: about 15% from Q1 to Q2, then 9%.
| Kind of work | Q3 monthly spend | In heavy-rework sessions | 2027 driver | 2027 monthly |
|---|---|---|---|---|
| Feature work | $10,000 | $1,500 (15%) | ×1.3, roadmap has 30% more feature work | $13,000 |
| Bug fixing and debugging | $6,000 | $2,100 (35%) | ×1.0 | $6,000 |
| Refactors and migrations | $4,000 | $1,000 (25%) | ×1.5, database migration in H1 | $6,000 |
| Infrastructure | $2,000 | $200 (10%) | ×1.0 | $2,000 |
| Review and exploration | $2,000 | $200 (10%) | ×1.25, more agent review on PRs | $2,500 |
| Subtotal | $24,000 | $5,000 (21%) | $29,500 | |
| Rework target: halve the redo in debugging | −$525 | |||
| Usage growth, from Fernhollow's own trend | +20% of subtotal | +$5,900 | ||
| 2027 monthly budget | $34,875 |
That's $418,500 for the year, about $872 per engineer per month at today's 40 engineers.
The debugging row is where the rework target comes from. It carries $2,100 of heavy-rework spend, the largest of any row, and 35% of its own total. Fernhollow's engineering lead read a sample of those sessions. Most got stuck on the same undocumented local setup step, and they still fixed the bug in the end, at about twice the cost of a clean debugging session. So roughly half the $2,100, $1,050, is redo. Her target is to halve that: $525 a month. If the debugging rework share hasn't dropped by the end of Q1, the $525 comes back into the budget and she says so in the quarterly review. A target with a date and a reversal rule is one finance can hold you to.
The 20% growth line assumes the slowdown continues, to roughly 5% a quarter. At a steady 9% a quarter, 2027 would average about 36% above Q3, roughly $4,700 a month more than this budget. That's the figure to re-forecast to if Q1 runs hot.
The seat version of this budget is a single line, and it might even land near $34,875. But in March, when actuals run 15% over, the seat line can't tell you whether the migration started early, debugging got worse or everyone simply leaned on agents harder. Fernhollow's table can, row by row.
Four questions finance will ask, and the row that answers each
Why is it going up? Point at the drivers column. $5,500 of the increase comes from planned work, and you can name each project.
What if usage jumps again? That's the growth line. Compare it to actuals monthly, and agree in advance that two straight months over it triggers a re-forecast.
What are we getting for it? Report spend per authored pull request by team, quarterly. It's crude, and finance can check it against GitHub. For scale, Jellyfish's data puts AI's direct slice of the all-in cost of a merged PR (salary plus AI usage) at "about $18 of the $799 average." So ask whether the $18 is moving the other $781.
Where's the waste? The rework line, with its target and its date.
Budget by team, never by person
A per-engineer allocation looks fair and does damage. Jellyfish found that the heaviest users consume "an order of magnitude more than the median developer." A per-head allocation starves the people doing the most agent-heavy work, and a per-head league table turns into tokenmaxxing. When one person's spend stands out, read their sessions before drawing any conclusion. A high number can be a migration, a loop or someone carrying the team's hardest work.
Getting the rework column without reading every session
Invoices and a spreadsheet get you most of Fernhollow's table. The rework column needs the sessions themselves. VibeCheck captures Claude Code, Codex and Cursor sessions on each engineer's laptop through a stop hook and background sync, installed with one command or through your MDM. It estimates each session's cost at published reference prices. Those are estimates, not invoices, so use them for the split and your invoices for the total. In Sessions you can filter by kind of work and see what the matched sessions cost, and Usage shows the token mix by kind of work. Kinds overlap, because a session can carry more than one, so those figures don't add up to the bill. Give each session its main kind, or scale the rows to the invoiced total yourself.
The free plan covers up to five engineers and shows spend by model. Pro ($30 per engineer per month, billed annually) adds spend by person, team and skill, the token mix by kind of work, and, once the GitHub App is connected, cost per authored PR. In Sessions you can filter to heavy rework and see what those sessions cost, then open a session to see why it redid its work. See pricing, compare it with provider consoles, or get started for free.