Benchmark
AI seat utilization: what good looks like
Utilization is the share of the seats you pay for that somebody actually uses. Below are the thresholds worth working to — and, next to each one, what it actually rests on. Only one number on this page was measured by anybody.
Reviewed 30 Jul 2026 · By Patrick Lambert, founder
How to read this page
A benchmark table is the easiest place to turn a rule of thumb into a statistic. Every figure here says which it is:
- Published benchmark
- Measured and published by a named third party, linked in the source column.
- Rule of thumb
- Reasoned from something checkable, with the reasoning shown. Not a measurement of any population.
- Worked example
- An illustrative example on our own synthetic demo dataset, not a claim about your company or anyone else's.
The three bands
These are reasoned, not measured. In any 30-day window some share of a team legitimately does not touch a coding tool: parental and medical leave, holiday that clusters, a sprint on architecture or incidents, a contractor between projects, someone who moved into management last month. Across a normal team that runs somewhere around a tenth of headcount, which is what puts the healthy line near 85% and makes below 60% too large for leave to explain. Disagree with the reasoning and you should move the lines.
| Band | Utilization | What it means | Basis |
|---|---|---|---|
| Healthy | Above 85% | Seats are fine. Whatever your AI money problem is, it is not the seat count.Stop looking at seats and look at the meter: usage-based charges are not capped by headcount, and a well-adopted rollout grows them fastest. | Rule of thumb |
| Drift | 60% to 85% | Ordinary drift. Leavers, movers, and rollouts that got ahead of adoption by a few seats.A quarterly clean-up. Worth doing before a renewal, not worth a project. | Rule of thumb |
| Rollout outran adoption | Below 60% | Two seats in five untouched for a month is more than leave can absorb. Usually a rollout handed out by team rather than by request, or a migration where the old tool was never cancelled.Treat it as a finding, not a clean-up. This is where the recoverable dollars concentrate. | Rule of thumb |
The one published figure
21% of AI coding licences underutilised
Published benchmarkAcross more than 250,000 developers, per Opsera, 2026 AI Coding Impact Benchmark ↗.
Vendor-published, and it does not say how the figure was worked out. “Underutilised” is also not the same test as “no activity in 30 days”, so it is not directly comparable to the bands above. Read it as a rough population signal, not a threshold.
Two bars, and the gap between them
The low bar
Active = used the tool at all in the last 30 days. Utilisation = active seats ÷ paid seats.
This is the number to take into a renewal, because it is the one a vendor cannot argue with. No weighting, no scoring, no judgement.
The high bar
Really used = active on at least 3 days in a month.
This is the number to run the rollout against. The gap between the two bars is people who have the tool, opened it a few times, and never got it into their working day — an adoption problem, not a cancellation list.
Why one number hides two populations
Worked example120 seats across a 21-working-day month. These counts are illustrative — the point is the shape, not the numbers.
| Band | Days used | Seats | Share |
|---|---|---|---|
| Dormant | 0 | 16 | 13% |
| Occasional | 1 to 5 | 25 | 21% |
| Regular | 6 to 11 | 18 | 15% |
| Daily | 12 or more | 61 | 51% |
On the low bar this reads 104 of 120, or 87% — healthy. On the high bar it reads 61 of 120, or 51%. The 43 seats in between are not a cancellation list: those are people who have the tool, opened it a few times, and never got it into their working day. The 16 dormant seats are the cancellation conversation.
What this is worth
Across public benchmarks and our own sample data, 10 to 15% of seat and subscription spend is typically recoverable within 30 days, and idle seats are where most of it sits. A seat is unused when the licence has had no recorded activity for 60 days and is still being billed — the same threshold our rule engine applies, published so the two cannot drift apart.
One more thing a single vendor's console cannot show you: a developer at 0% in Copilot and 100% in Cursor reads as waste in one and success in the other, and neither vendor can see the other. The finding lives in the join.
Common questions
What is a good AI seat utilization rate?
Above 85% is healthy, 60% to 85% is ordinary drift, and below 60% means the rollout outran adoption. Those cut-offs are rules of thumb reasoned from how much of a team is legitimately away from a tool in any given month — they are not measurements of a population, and nobody has published one.
How is AI seat utilization calculated?
Active seats divided by paid seats, where active means the person used the tool at all in the last 30 days. No weighting and no scoring. Write the definition in the same sentence as the number: a utilization figure whose definition sits in a footnote falls over at the first question from a salesperson.
Is there a published benchmark for AI seat utilization?
Opsera, 2026 AI Coding Impact Benchmark reports 21% of AI coding licences underutilised across more than 250,000 developers. Vendor-published, and it does not say how the figure was worked out. “Underutilised” is also not the same test as “no activity in 30 days”, so it is not directly comparable to the bands above. Read it as a rough population signal, not a threshold.
Our utilization is 90%. Are we done?
No — it means your money moved. Seat spend is capped by headcount and usage-based spend is not, so a well-adopted rollout grows the metered half of the bill fastest. High utilization on one tool also says nothing about whether you needed two: an engineer active daily in both Copilot and Cursor reads as 100% used in each console, and neither vendor can see the other.
Why does one utilization number hide two populations?
Because "used it at all this month" and "uses it most working days" are different tests, and the gap between them is usually large. In the worked example on this page, 87% of seats clear the low bar and 51% clear the high one. The seats in between are an adoption problem, not a cancellation list.
Measure your own, across every vendor at once
Read-only connectors, both bars computed per tool and per team, and a proof level on every figure.
The long version, with the reasoning argued out: what a good AI seat utilization rate actually is. And the money it adds up to: the hidden cost of idle AI seats.