Quick answer
Per-developer Copilot usage comes from two places: the seat list in your GitHub organization and the usage metrics GitHub reports for each seat. Organization owners can open the Copilot usage or metrics view, or pull the metrics API, to see activity and premium requests by user. A local tracker only covers your own machine.
Two reports answer different questions
GitHub splits per-developer data into assignment and consumption. Assignment tells you who holds a seat and which plan that seat draws from. Consumption tells you what the seat used: accepted suggestions, chat turns, agent runs, and premium requests. Neither report is complete on its own, and reading one without the other produces confident wrong answers.
An idle seat and a cheap seat look identical on a billing export. A developer burning premium requests on agent runs can look quiet on a chart that only counts accepted completions. Match the two views before you conclude anything about a person.
| Signal | Where it lives | What it misses |
|---|---|---|
| Seat and plan | Organization settings, Copilot access page | Any usage at all |
| Daily activity | Copilot usage report or metrics API | Which feature drove it |
| Premium requests | Organization billing and usage pages | Free-tier chat and completions |
| Local tokens | Editor logs, trackers on each machine | Every teammate |
Pull the numbers without guessing
Order matters here, because each export identifies people differently and the date ranges rarely line up by default.
- Export the seat list from organization settings and resolve each entry to a person, not just a handle.
- Open the usage or metrics view for the same dates. If your plan exposes the metrics API, pull it daily so you keep history past the retention window.
- Export billing for premium requests over the same period.
- Join all three on the person, then compare ratios rather than raw totals.
Do the join in a spreadsheet the first time. You are looking for two patterns: seats that are paid for and never active, and seats whose premium request share sits far above the team median. Those are different problems with different fixes, and only one of them is about how someone works.
The Copilot usage report guide covers the export columns. Copilot analytics for teams explains the organization-level view, including what the metrics API returns and how long the data stays available.
Act on the pattern, not the ranking
- Idle seat: reclaim it or reassign it before the next billing cycle.
- Heavy premium requests: check whether agent runs, retries, or a strong model are the cause.
- Wide spread across the team: compare task mix first. Agent work costs more than inline completion.
- No data at all: the seat may be on a plan that does not report usage, or the person signed in with a personal account.
Per-developer numbers are a starting point, not a scoreboard. Someone who accepts more suggestions is not automatically producing more value than someone who spends the day reviewing agent output. Use the data to find wasted seats and surprise overages, then talk to the people behind the numbers before you change a plan.
For your own side of the picture, UsageAtlas reads local editor session files on Windows, macOS, and Linux and shows Copilot usage next to thirteen other providers. It cannot see your teammates, and it does not pretend to.
Questions, answered
Can I see Copilot usage for one developer?
Organization owners can filter the Copilot usage and metrics views by user, and the metrics API returns per-user records when the plan supports it. Developers can see their own premium request usage in personal GitHub billing settings.
Does Copilot report token counts per developer?
Not in the standard organization reports, which count requests and acceptances. Token-level detail sits in editor session logs on each machine, so a local tracker is the practical way to see it.
How do I stop paying for unused Copilot seats?
Compare the seat list against activity for the last 30 days, then remove or reassign seats with no activity. Changes take effect at the next billing cycle.