← FinOpsAid blog

How to find and reclaim idle GitHub Copilot seats
Idle Copilot licences are the easiest GitHub cost to cut and the hardest to see. Here's how to spot seats no one is using, reclaim them safely, and stop paying for the same waste next month.
Every GitHub Copilot seat you assign is billed whether or not the developer holding it writes a single line with it. That's the trap: the subscription is charged per assigned user, not per active one, so an engineer who left six months ago, switched teams, or simply never adopted the tool is a full subscription you are funding for nothing. Multiply that by a few dozen forgotten seats and you're paying for a line item nobody would defend if they could see it.
Since GitHub moved Copilot to usage-based billing in June 2026, that subscription also carries an allowance of AI credits — and an idle seat burns none of it. That makes the waste sharper, not smaller: your dormant seats consume the fixed cost and none of the value, while your heaviest users can now exceed their allowance and cost more than the sticker price. The two ends of the distribution moved apart, and reclaiming the dead end is still the cheapest thing you will do this quarter.
The problem isn't that this waste is expensive to fix. Reclaiming a seat takes seconds. The problem is visibility — GitHub's billing page shows you a total, not who's actually using what.
What "idle" actually means
The two gaps need opposite responses. Reclaiming seats above the dashed line is pure margin and takes seconds; closing the gap below it takes enablement, and reclaiming those seats would be a mistake. Illustrative percentages.
A Copilot seat is idle when the licence is assigned but the person isn't generating suggestions or accepting completions. GitHub exposes a last_activity_at timestamp per seat through the Copilot billing API, and that single field is the one that matters. A seat with no activity in 30 days is a strong candidate; 60+ days with no activity is almost always pure waste.
Watch for these patterns specifically:
- Departed employees whose seats were never deprovisioned. Offboarding checklists rarely include "remove Copilot access."
- Team switchers who moved to a role that doesn't touch code but kept the seat.
- Never-adopters — developers who were assigned a seat in a bulk rollout and never turned it on. This is the biggest bucket in most orgs.
- Duplicate coverage, where someone has both an individual subscription and an org-assigned seat.
A five-minute audit you can run today
You don't need a tool to start. Pull the seat list from the Copilot billing API (GET /orgs/{org}/copilot/billing/seats), and for each seat look at last_activity_at against created_at. Sort by last activity, oldest first. The seats at the top of that list — assigned weeks or months ago, no recent activity — are your reclaim candidates.
Before you pull any licence, sanity-check two things: that the developer is still active on GitHub at all (a quiet seat on an otherwise busy account may just be someone who prefers not to use Copilot), and that they're not mid-leave. When in doubt, message them. A seat costs more to leave running for a month than the two minutes it takes to ask.
The reason it comes back every month
Here's what makes idle-seat waste so persistent: it regenerates. You do the audit, reclaim eight seats, feel good — and next quarter the same thing has crept back because onboarding assigns seats in bulk and offboarding forgets to remove them. A one-time cleanup is a one-time saving. What actually moves the number is watching the signal continuously: knowing, every week, which seats have gone quiet and how much that's costing you.
This is exactly the kind of thing FinOpsAid was built to keep an eye on. It snapshots your Copilot seats nightly, surfaces the ones that have gone idle, and — because it keeps history in a versioned warehouse rather than overwriting it — shows you the trend, not just today's number. You see the waste accumulating before it becomes a quarter's worth of forgotten licences.
One principle worth keeping
A usage signal is not a bill. last_activity_at is a strong hint that a seat is wasted, but it's a hint — the authoritative cost still comes from GitHub's billing API, and the two can disagree at the margins (a seat assigned mid-cycle, a proration, a plan change). Good FinOps means reconciling the two: use the activity signal to find candidates, and the billed dollars to quantify the saving. Meter the signal, anchor it to the invoice, and never conflate the two.
Reclaiming idle Copilot seats is the single highest-return, lowest-risk cost action available to most engineering orgs. The money is already being spent; all that's missing is the visibility to stop spending it.
Frequently asked questions
How do I find unused GitHub Copilot seats?
List every assigned seat with its last activity date, then rank by days inactive rather than by cost — every seat costs the same, so the differentiator is confidence. Anything past 90 days with no activity is a high-confidence candidate with a name attached.
Is it safe to revoke an idle Copilot seat automatically?
No. Parental leave, sabbaticals, long-term sickness, a contractor between engagements and a switch to an unmonitored editor all look identical to idleness. Check the top names by hand before acting; a batch revocation without that check produces a support queue and costs you credibility.
Why do idle Copilot seats keep coming back every month?
Because reclaiming seats is cleanup, not prevention. Joiners get seats provisioned by default and leavers are rarely deprovisioned from GitHub specifically, so the population regenerates. The durable fix is tying seat assignment to a lifecycle event rather than running the audit again next quarter.
Want to see your own idle seats without building the audit yourself? Connect your GitHub org — it's read-only and free during beta — or explore the demo dashboard first.