GitHub announced on July 17, 2026 that the Copilot usage metrics REST API now supports repository-level activity. Enterprises and organizations can use new daily reports to see Pull Request activity from Copilot coding agent and Copilot code review by repository.
The update adds two daily endpoints: /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD at the enterprise level and /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD at the organization level. The responses report Pull Requests created and merged by the coding agent, along with Pull Requests reviewed by code review and suggestion counts broken down by comment type.
Copilot usage metrics previously stopped mainly at the organization and user levels. Administrators could see who was using Copilot, but not necessarily where that activity was concentrated in the codebase. Repository-level data brings the view closer to engineering work. GitHub describes it as a foundation for repository insights and AI-readiness reporting, helping teams target enablement where it is most needed.
This level of data has two implications for agent governance. Teams can now connect how much AI is used with which repositories actually receive Pull Requests from coding agents or code review. But Pull Request volume is not a productivity answer on its own. A useful assessment also needs review turnaround, change-failure rate, security alerts, rework, human approval time, and the quality of the final delivery.
GitHub lists the access requirements as well. Enterprise owners, billing managers, organization owners, and custom roles with the View Copilot Metrics permission can access the reports, and the Copilot usage metrics policy must be enabled. Organizations should settle data scope, role access, and retention before connecting the metrics to an internal dashboard. Otherwise, the metrics layer can become another data-governance problem.
For teams adopting AI coding agents, the value of this update is that it provides an observation surface closer to work outcomes. Seat count, message count, and token usage can describe cost, while repository-level Pull Request activity shows where the workflow is actually happening. The next step is to interpret those signals alongside code review, CI, security, and human judgment rather than using one number as a substitute for engineering decisions.
