Average AI coding spend per engineer is a misleading number because coding-agent spend is heavily skewed. A small share of sessions carries a large share of the bill, so the mean is set by a few outliers and describes almost nobody. Look at the distribution instead: the median, the most expensive sessions, what they were for and what they bought.
As of November 2026. The team in this post is fictional; the one public figure is linked and dated.
The mean mostly measures your tail
Take a fictional 20-engineer team, call it Fernway Health, that spends $12,000 on coding agents in a month across 1,000 sessions.
- Mean spend per engineer: $600. Mean cost per session: $12.
- Median engineer: about $410. Median session: $3.
- The 50 most expensive sessions, 5% of the total, cost $6,000. That's half the bill.
The mean is about 1.5 times what the typical engineer spent and four times the typical session. It sits above most of the team partly because two people had expensive months. One spent $2,000, $1,500 of it on a database migration. The other spent $1,900, and $1,100 of it was one week of an agent rewriting the same failing integration test.
So when the mean moves, assume a handful of sessions moved, not the whole team. If Fernway's mean rises 20% next month, from $600 to $720, that's $2,400 more in total. Sixteen sessions at $150 each would do it. Before anyone asks whether the whole team is getting less efficient, find those 16 sessions.
Public numbers show the same shape. In its S-1 filed with the SEC on October 26, 2026, Anthropic said that in the quarter ended September 30, 2026, Claude Enterprise users who didn't use Claude Code spent less than $75 a month on average, while "the top 5% of Claude Enterprise users who used Claude Code spent approximately 20 times that amount." Those are two different groups, and the filing uses the comparison to show customer expansion, not cost discipline. But notice what it took to show the gap: a top slice set against an average. One average over everyone would have hidden it.
Per-person numbers can't tell a migration from a loop
Seat math takes the mean and multiplies it. If Fernway hires five engineers and budgets 25 × $600 = $15,000 a month, it's assuming each new hire brings a share of migrations and rework loops. They might not. A steadier method splits the base from the tail. Fernway's other 950 sessions cost $6,000, or $300 per engineer. At 25 engineers that's a $7,500 base, plus a named line for each migration-sized project and an allowance for the rework you haven't fixed yet. The 2027 budget post covers the rest of that exercise. A number per person has two more problems.
It points at people instead of sessions. The migration engineer and the rework engineer have nearly the same monthly total. One bought a finished migration. The other mostly bought retries. A per-person number can't tell them apart, and a per-person cap would stop both. (The post on caps, alerts and coaching goes into that choice.)
It invites a ranking. Once there's a number per engineer, someone sorts by it. As the tokenmaxxing post covers, people then manage the number. In a skewed distribution the ranking mostly tells you who had the big project this month.
Five readings that show where the tail is
You need cost per session, not just cost per person per day. With that, five readings cover most of it.
- Median next to mean. Report both. When the mean is well above the median, the tail is driving the total, and the rest of this list is where to look.
- Top-sessions share. Sort sessions by cost, add up the top 5%, divide by the total. Fernway's is 50%. Track the trend, not the level. If the share rises while the median holds steady, the tail is growing.
- The top 20 sessions, read one by one. Open each and note what it was for, which model ran it, whether it led to a merged change and whether the agent redid its own work.
- Spend by kind of work. Feature, bugfix, debugging, refactor and exploration sessions should cost different amounts. Compare each one's share of spend with its share of sessions. If bugfixes are 30% of sessions and 55% of spend, that's worth an hour.
- Rework share. How much of the period's spend sat in sessions that needed heavy rework. This is the one number on the list that's almost always worth pushing down.
None of these need a name next to them. Look at teams, repos, models and kinds of work first. When you do open one person's sessions, compare that person with their own last month.
What's usually in the tail, and what to do about it
When Fernway's lead read the top 50, they fell into four groups.
Legitimately large work: 18 sessions, $2,700. The migration took six sessions and $1,500. Two big features and a refactor of the billing module took the other 12 and $1,200. Each led to a merged pull request. Decision rule: if a top session produced a merged change someone would have paid an engineer days to make, leave it alone. Budget work of that size as a project line rather than spreading it into the per-seat number.
Rework loops: 11 sessions, $1,700. Mostly the failing integration test, plus a code generator whose output the agent kept fixing by hand. These sessions run long and leave little behind. Decision rule: when several top sessions in one repo share a cause, fix the cause, usually a missing instruction, a flaky test or an undocumented setup step. Don't coach the person. Next month, check that repo's rework share.
A premium model on routine work: 14 sessions, $900. Small bugfixes and code reviews run on the most expensive model because it was the default. Decision rule: if a kind of work rarely needs the top model, make a cheaper one the default for it and let people opt up. If that halved the cost of these sessions, it would save $450 a month. Small, but it recurs every month.
Runaway subagents: 7 sessions, $700. A parent session handed work to subagents, and some of those handed off again. In Claude Code, a standard (non-forked) subagent starts with a fresh context and doesn't see the files its parent already read, so a wide fan-out pays to load much the same context many times over. Decision rule: if a session's subagents cost more than the work it delivered, narrow the instruction that launches them or run fewer in parallel. Claude Code also lets you limit how deep subagents can nest.
Add it up: $3,300 of the $6,000 tail was rework, the wrong model or runaway fan-out, and the biggest single slice, $2,700, was work the team wanted done. Cutting the top sessions across the board would have hit the migration first.
Where VibeCheck fits
VibeCheck captures Claude Code, Codex and Cursor sessions on each engineer's laptop and prices each session from its own tokens. The costs are estimates at published reference prices, not invoice amounts. In Sessions you can sort by highest estimated cost to get the top-sessions list. Filter by kind of work, model, repo or heavy rework, and the strip above the list shows what that slice cost, per session and per person, by model and by repo. Then open a session to see what it was for, how much it redid its work and where the engineer corrected the agent. Usage rolls spend up by person, team, model and skill, shows the token mix by kind of work, and with the GitHub App connected it adds cost per authored PR.
It doesn't compute medians or percentiles for you. Sorting by cost and reading each slice's total gets you most of the way. A provider console gives you totals per person; here's how that compares.
The free plan covers up to five engineers, with every session's estimated cost and your org's spend by model. Spend by person, team and skill, the token mix by kind of work, and cost per PR come with Pro. See pricing, or get started for free.