GitHub is pushing Copilot measurement down to the repository level, and the move matters more than it looks. Two new REST API endpoints, now generally available, return daily per-repository breakdowns of pull request activity for both Copilot coding agent and Copilot code review, covering pull requests created, merged, and reviewed along with suggestion counts by comment type. The repository-level Copilot usage metrics API<\/a> is accessible to enterprise owners, billing managers, and anyone holding the View Copilot Metrics permission at the org or enterprise role level.<\/p>\n Before this, Copilot adoption data stopped at the organization and user level, which meant you could tell how many engineers touched the tool but not which codebases actually benefited. That’s the difference between measuring gym membership and measuring fitness. With per-repository data, engineering leaders can identify where Copilot coding agent is genuinely closing pull requests versus where adoption is nominal and act on that gap directly.<\/p>\n The framing GitHub uses, “AI-readiness reporting,” is doing real work here. The implied claim is that repositories vary in how amenable they are to AI-assisted development, and that variance is measurable. That’s almost certainly true. Codebases with clear test coverage, well-scoped issues, and consistent commit hygiene will produce more Copilot-closed PRs than sprawling legacy monoliths. Repository-level metrics make that variation visible, which means CTOs can prioritize remediation investment in the repositories that are suppressing AI productivity rather than blaming the tool broadly.<\/p>\n The signal worth watching: GitHub is building the instrumentation layer that enterprise AI governance will eventually require. Once you can report AI activity by repository, the next step is tying that activity to outcomes like deployment frequency, defect rates, and cycle time. That’s the data model that turns a line-item AI subscription into a defensible productivity claim. Any team not already thinking about connecting these data streams will find themselves explaining seat costs to a skeptical CFO with no evidence to counter the question.<\/p>\nWhat this means for your business<\/h2>\n