What good AI seat utilization actually looks like

Utilization is the share of the seats you pay for that somebody actually uses. Above about 85%, your seats are fine and your money is somewhere else. Between 60% and 85%, you have ordinary drift, worth a clean-up each quarter. Below about 60%, you have a rollout that outran adoption — routinely 10–20% of that tool's bill.

Those cut-offs are useful, and they are not measurements. Where they come from matters more than the numbers, so start there.

Define utilization before you benchmark it

A seat is active if the person holding it used the tool at all in the last 30 days. Utilization is active seats divided by paid seats. No weighting. No scoring.

Pick that definition, write it in the same sentence as the number, and never move it. A utilization figure whose definition sits in a footnote falls over at the first question from a salesperson.

Two bars are worth tracking, and the gap between them is the interesting part.

• Used in the last 30 days. Has this seat been touched at all? A generous bar. Good at finding dead seats, useless for proving a seat is alive.
• Really used. Has this seat been used on most working days? A much harder bar, and the one that tells you whether the tool is in the work or on the shelf.

Where the 85 and 60 cut-offs come from

They are rules of thumb, worked out from how people take leave. They are not counted data from a population. Nobody has published how AI seat use is spread across companies. Anyone quoting you a figure to three digits is making it up. Here is the reasoning, and you should feel free to reject it.

In any 30-day window, some share of an engineering team will not touch a coding tool at all, for good reasons. Parental and medical leave. Sabbatical. Holiday that clusters. A sprint on architecture or on incidents. A contractor between projects. Someone who moved into management last month. Across a normal team that runs around 8–15%. So a rollout with genuinely full adoption still should not read 100%. It should read in the high eighties. 85% is the floor of what full adoption looks like, once you allow for people being people.

Sixty is where leave stops explaining it. Two seats in five dead for a full month cannot be absorbed by holiday and architecture sprints. Something bigger is going on: a rollout handed out by team rather than by request, a migration where the old tool was never cancelled, or a tool that never landed.

The only published figure anywhere near this is Opsera's 2026 AI Coding Impact Benchmark, which reports 21% of AI coding licenses underutilized across more than 250,000 developers. It is vendor-published and never says how it was worked out, and "underutilized" is not the same test as "no activity in 30 days". Read as a rough population signal, it puts the typical company near 79% — inside the drift band, below healthy. That is the closest thing to evidence these cut-offs have.

The gap between active and really used

Run both bars and the second number is usually much worse. Take 120 Cursor Business seats at $40, across a 21-working-day month.

| Band | Days used | Seats | Share | |---|---|---|---| | Dormant | 0 | 16 | 13% | | Occasional | 1–5 | 25 | 21% | | Regular | 6–11 | 18 | 15% | | Daily | 12+ | 61 | 51% |

Utilization by the 30-day bar: 104 of 120, or 87% — healthy. Really used: 61 of 120, or 51%.

The 43 seats in between are the finding, and they are not a cancel list. Those are people who have the tool, opened it a few times, and never got it into their working day. At $40 that band is $1,720 a month, but the answer there is help, not cancellation. The 16 dead seats are the cancel conversation. The 25 occasional ones are an adoption conversation. One number loses that difference.

What to do when your utilization is already healthy

Plenty of companies run this and land above 85%. If that is you, the conclusion is not that you are done. It is that seats have stopped being where your money is. Three things become the finding instead.

The meter. The meter is the part of the bill that goes up with use. Seat spend is capped by headcount. Usage is not. Vendors bill agent work by the token — the unit they charge for, roughly a few characters of text — and a well-adopted rollout can double that bill in a quarter with a flat seat count. The causes are built in, not accidental: allowance cliffs, shared limits, model choice, agent loops. DX's June 2026 pricing analysis puts all-in cost per engineer at $200–600 a month for teams mixing autocomplete and agent tools, a band no seat price explains. The metered traps hiding in AI tool pricing covers all four. High utilization makes this *more* likely, not less. Engaged users burn tokens.

Duplication. High utilization on one tool says nothing about whether you need both. An engineer active daily in Copilot and daily in Cursor reads as 100% used on both. That is either two tools doing two real jobs, or a migration nobody finished. Do you need both Copilot and Cursor? works through where that line falls.

Plan fit. GitHub's published plans put Copilot Enterprise at $39, but it requires GitHub Enterprise Cloud at about $21. A fully used Enterprise seat costs about $60 all in, above Cursor Business list price. Full use of a plan you never needed is expensive adoption, not a win. Cursor vs Copilot vs Claude Code has the arithmetic.

A 90% utilization number does not mean you are done. It means your money moved to the meter.

Why the view across every vendor is the one that matters

Utilization for one vendor is a rollout number. Utilization across every vendor is a spend number, and only one of them finds the expensive thing.

A developer at 0% on Copilot and 100% on Cursor reads as waste in GitHub's console and as success in Cursor's. Neither can see the other. GitHub has no view of your Cursor roster and no reason to build one. The finding lives in the join. The hidden cost of idle AI seats covers how to build it. What each vendor's admin console actually exposes shows where each one stops.

Show the evidence. Let a human decide.

What this work produces is a list with names, dates and dollar amounts on it. It is not an action. Send it to engineering managers, ask them to confirm or contest each person, and take back what comes back unclaimed. Cancel automatically on a 30-day signal and you will be wrong about a real person nearly every time you run it. Being wrong about a person costs more trust than the seat costs money.

The honest caveats

The 85 and 60 cut-offs are rules of thumb with the reasoning shown, not findings. That reasoning assumes a leave and work pattern typical of a mid-size product engineering team. A consultancy or a seasonal team should work out its own floor. The only published figure nearby comes from a vendor and never says how it was produced.

Activity data is rough everywhere, and every vendor defines it differently, so utilization numbers from two vendors are not strictly comparable. Say so when you report them. Small teams give unstable rates: at 8 seats, one person on leave moves utilization by 12.5 points. And utilization tells you whether a tool gets touched. It never tells you whether it helps.

Find your recoverable AI spend

Spendassay hands you one page that shows what your AI tools cost and what you get back. A utilization number only belongs on it when it is worked out the same way for every vendor, with the definition written next to it. We do that join read-only, report at team level with a minimum of eight people per team, and never rank individual developers.

`Start free` → /login?src=blog_ai-seat-utilization-benchmark