Copilot API now grades AI adoption by user phase

GitHub added AI adoption phase cohorts to the Copilot usage metrics API in a May 29, 2026 Changelog post. The API no longer treats every engaged user as the same kind of active user. It now classifies people by the Copilot surfaces they used during the last 28 days, including code-first, agent-first, and multi-agent patterns. That matters because an organization using Copilot only for IDE autocomplete is no longer measured in the same bucket as an organization using cloud agents, code review, the CLI, and the Copilot app.

The new reporting surface splits into two paths. User-level reports now include ai_adoption_phase. Enterprise and organization reports now include a totals_by_ai_adoption_phase array. GitHub describes that array as a phase-level view of engagement and activity metrics, including engaged users, average user-initiated interactions, code generation activity, and code acceptance activity. The same phase grouping also covers average lines added or deleted, pull requests created or merged or reviewed, and average median time to merge.

The classification uses a rolling 28-day window. GitHub's Changelog says each engaged user is evaluated by whether they used the relevant Copilot surfaces on at least two days within that window. That threshold prevents a one-day experiment with agent mode from immediately changing a user's cohort. It also means that two repeated uses inside the 28-day window can become a signal in training programs, adoption reports, or internal rollout dashboards.

GitHub's use of names such as code first and agent first says something about the product direction. In earlier Copilot adoption reporting, the first numbers administrators usually watched were active users, completion acceptance, and usage by IDE or language. This field asks a different question: not just how many people use Copilot, but how far they moved across the Copilot product family. The path runs from code completion into code review, cloud agents, CLI usage, and the Copilot app.

The Copilot usage metrics REST API documentation says an enterprise must set its Copilot usage metrics policy to Enabled everywhere before the API is available. The endpoints separate one-day reports, 28-day reports, user reports, and team join reports. Access is also tied to enterprise owners, billing managers, or users with the required fine-grained permissions. The report does not simply return a large payload in every call; the API provides a time-limited signed URL for the report artifact. That shape makes the data more likely to feed internal analytics pipelines than a product dashboard alone.

For administrators, the practical value is more specific budget allocation. If active usage is high but Phase 2 and Phase 3 remain low, an enablement team can design training around cloud agents or Copilot code review instead of repeating autocomplete onboarding. If one team moves quickly into Phase 3 but its pull request median time to merge does not improve, the next investigation is probably review policy, test bottlenecks, or repository workflow rather than more agent usage. Adoption phase is closer to a rollout operations table than a marketing claim that "AI usage is up."

The same field can also become a pressure mechanism. ai_adoption_phase appears in user-level reporting, and that is sensitive information for developers. If managers turn phase into a personal target, the organization may train people to touch agent surfaces just to move a metric. A developer can run the CLI again, invoke a code review agent in a low-value situation, or open the Copilot app to satisfy a dashboard. Once that behavior counts as adoption, the metric stops measuring product utility and starts measuring compliance with a reporting system.

GitHub also attaches a version field to each ai_adoption_phase, beginning with v1. That small detail is useful because Copilot's surface area is still changing. The new Copilot app already participates in the Phase 3 definition, and future surfaces such as Spaces, custom agents, repository automation, or additional review workflows could change how the same raw usage maps into a phase. The version field is a warning not to flatten May 2026 cohorts and later cohorts into one long chart without checking the classification logic.

The enterprise and organization reports also need careful reading because the phase-level metrics are per-user averages, not sums. A raw total would make the largest cohort look dominant by default. GitHub instead describes average interactions, average code generation, average acceptance activity, average lines added or deleted, PR activity, and average median time to merge within each phase. That design is closer to asking whether Phase 3 users behave differently per person, even if the Phase 3 cohort is smaller than Phase 1.

Many development organizations will be tempted to combine this metric with seat optimization. Phase 0 users can look like license reclamation candidates. Phase 1 users can become training targets. Phase 2 and Phase 3 users can become internal champions. That operating model is not inherently wrong, but phase is not a direct measure of individual skill or productivity. Some repositories benefit more from short completions and disciplined review than from cloud-agent workflows. Some teams may restrict CLI or cloud-agent use because of security policy, compliance rules, or source-code handling requirements.

That is why the phase field should be read next to the rest of the Copilot usage metrics reference. GitHub's documentation also covers lines of code changed with AI, agent contribution, model usage by chat mode, monthly active users, Copilot code review users, and CLI usage. Adoption phase alone can make "more agent usage" look like a success condition. Combining it with pull request merge time, review activity, generated-code acceptance, and deleted lines gives a better picture of whether agents changed the workflow in a useful way or simply added another visible action.

The API update also shows GitHub managing Copilot as a product family rather than a single feature. Code completion, IDE agent mode, cloud agent, code review, CLI, and the Copilot app are different work surfaces. A few years ago, that difference mostly lived in product copy. Now it appears as an enterprise report field. If administrator dashboards follow this structure, AI adoption meetings will move from "How many Copilot seats are active?" to "Which agent surfaces are teams using responsibly, and where does the workflow still break?"

Teams adopting this metric should decide four things before wiring it into dashboards. First, confirm whether the enterprise Copilot usage metrics policy is enabled. Second, write down that user-level reports will not be used as individual performance evaluation. Third, normalize phase-level pull request and code-change metrics by team size, repository type, and security constraints. Fourth, pilot Phase 2 and Phase 3 workflows in repositories where agent use is actually valuable instead of forcing every developer toward multi-agent usage.

The May 29 Changelog is a small API-field update, but it captures a larger move in AI coding tools. GitHub is turning Copilot adoption into a measurable operating system for administrators: four cohorts, a 28-day repeat-use window, per-user averages, and versioned classification logic. The next enterprise buying question will not only be which model writes better code. It will also be which product can explain AI use in a way that helps rollout teams without turning developers into targets for a phase scoreboard.