On 7 August GitHub added a potential return on investment section to the Copilot impact dashboard. It shows comparison cards for adoption cohorts with cost per developer per month, that cost as a share of payroll, and pull requests opened per month, plus a salary selector so you can model against your own compensation.
This is a real improvement — the cost side is derived from actual AI credit consumption rather than list price. It is also the kind of dashboard that produces a slide, and slides made from dashboards have a way of losing their caveats on the walk to the meeting.
What the numbers actually are
Two of the three inputs are measured and one is invented, and it matters which is which.
- Cost per developer per month — measured, derived from real AI credit consumption for that group
- Pull requests per month — measured, and a genuine output signal
- Salary — not measured. It is a selector you set, and GitHub is explicit that it is a modelling input rather than actual payroll data
Who can see it
Enterprise owners, billing managers, organization owners, and anyone with a custom role carrying the View Copilot Metrics permission. The Copilot usage metrics policy has to be enabled for any of it to populate.
That access list is worth noting before you present the numbers: several of the people in the room can pull the dashboard up themselves and check what you did with it.
The cohort change will move your numbers on its own
GitHub also refined how adoption cohorts are counted, to include everyone active during the full 28-day reporting window. The stated effect is noticeably higher cohort counts going forward.
This is the single most important line in the announcement for anyone tracking a trend. If you compare this month's dashboard against a screenshot from June and report the difference as improved adoption, you will be reporting a change in GitHub's counting method as though it were a change in your team's behaviour.
Rebase your baseline. Any before-and-after that straddles 7 August needs a footnote or it is wrong.
Pull requests per month is an output, not a value
The dashboard compares PR volume across adoption cohorts, and the causal story writes itself: high adopters open more pull requests, therefore Copilot produced the difference.
Be careful with that. Adoption is not randomly assigned. The developers who adopt a new tool fastest tend to be the ones already shipping most, working on the most active services, and least blocked by review queues — so some of the gap you are looking at existed before Copilot did.
And PR count is a volume measure. It says nothing about whether those pull requests were merged, reverted, or spent three days in review. This month's other release is relevant here: effort levels are now recorded on the pull request, so review depth is finally something you can join against volume. A jump in PRs alongside a shift toward lighter review is a different story from a jump in PRs at constant review depth.
How to use it well
Treat the ROI section as a source of questions rather than a source of answers. Used that way it is one of the more useful things GitHub has shipped for engineering managers this year.
- Use the measured cost figure — it is the most trustworthy number on the page, and it is usually the one people were guessing at
- Set the salary selector to a real, defensible figure once, and keep it fixed; a moving assumption makes every trend meaningless
- Compare cohorts within the same month rather than the same cohort across months, until you have a post-7-August baseline
- Pair the PR count with a merge or revert rate from somewhere else before drawing a conclusion about output
- Never present the ROI number without GitHub's own caveat attached: these are estimates and a model, not accounting