Copilot Usage Metrics Move Beyond Active User Counts

GitHub's new Copilot usage cohorts help organizations distinguish basic activity from deeper agent workflow adoption.

2026-06-02 GIGATAP Team #security
#GitHub#GitHub Copilot#Developer Tools

Copilot Usage Metrics Now Show How AI Adoption Evolves

GitHub has expanded its Copilot usage metrics API with a new layer of adoption reporting. Instead of showing only who is active, the API now classifies engaged users into AI adoption phases based on how they use Copilot across different product surfaces over a rolling 28-day period.

For teams trying to understand whether Copilot is becoming part of daily engineering work rather than generating occasional activity spikes, this is a more useful signal than raw active-user counts.

Source: https://github.blog/changelog/2026-05-29-copilot-usage-metrics-api-adds-cohorts-for-ai-adoption

What Changed#

GitHub now assigns each engaged user to one of four AI adoption phases. The classification is based on Copilot product usage observed on at least two days during the previous 28 days.

The new classification appears as a user-level field in reporting, while enterprise and organization reports gain a new totals_by_ai_adoption_phase structure that aggregates metrics by cohort.

The phases are designed to reflect increasing use of agent-oriented workflows:

  • Users who do not meet engagement requirements.
  • Users primarily working with code completion or IDE agent features.
  • Users engaging with a single GitHub-based agent surface such as cloud agents, code review, or CLI workflows.
  • Users engaging with multiple agent surfaces or the GitHub Copilot app.

GitHub notes that the system is intentionally phase-based rather than tied to specific product names. That allows the classification model to evolve as new Copilot capabilities appear without making historical trend data difficult to compare.

Why It Matters for Copilot Usage Analysis#

Many organizations have spent the past two years measuring AI adoption through a simple question: how many users are active?

That metric is useful, but increasingly incomplete.

A developer who occasionally accepts code completions and a developer who regularly uses multiple AI agents may both appear as active users. From an operational perspective, those are very different behaviors.

The new cohort model attempts to separate those cases.

This gives engineering leaders a way to answer more meaningful questions:

  • Is adoption moving beyond autocomplete?
  • Are developers experimenting with agent workflows or incorporating them into regular work?
  • Which teams are progressing and which remain stuck at basic usage?
  • Where should enablement or training efforts focus?

The change reflects a broader shift occurring across developer tooling. As AI products expand from single features into collections of agents, chat interfaces, review systems, and automation workflows, usage measurement becomes more difficult. Counting active users no longer explains how deeply a tool influences engineering work.

The Metrics Become More Operational#

The update does more than add labels.

Enterprise and organization reports can now group several activity metrics by adoption phase, including engagement levels, user interactions, code generation activity, acceptance behavior, code changes, pull request activity, and merge timing.

An important detail is that GitHub reports averages per user within a cohort rather than simple totals.

That distinction matters because large teams can otherwise distort interpretation. A department with many lightly engaged users may generate impressive aggregate numbers while producing relatively little behavioral change at the individual level.

Per-user cohort metrics make comparisons more meaningful. Organizations can examine whether higher adoption phases correlate with different development patterns rather than assuming more usage automatically produces better outcomes.

What to Check Before Acting on the Data#

The new reporting creates better visibility, but it should not be treated as proof of productivity gains.

The cohorts measure product adoption, not engineering effectiveness.

A team moving from code completion to multi-agent workflows may indicate growing confidence in Copilot. It does not automatically mean faster delivery, better software quality, fewer vulnerabilities, or stronger security operations.

Organizations should compare cohort progression against their own operational metrics before drawing conclusions.

Useful comparisons may include:

  • Review cycle duration.
  • Deployment frequency.
  • Defect rates.
  • Security findings.
  • Documentation quality.
  • Developer onboarding speed.

Without that second layer of measurement, adoption data risks becoming another vanity metric.

This is particularly relevant in open source security and internal platform engineering, where increased automation can reduce manual effort while simultaneously introducing new trust, review, and governance requirements. Adoption alone does not answer whether those trade-offs are being managed well.

Readers interested in that broader operational perspective may also find value in related discussions such as OpenSSF’s push toward operational security artifacts and the wider argument that open source security requires more than code alone.

What Not to Overclaim#

The update does not reveal developer quality.

It does not rank teams.

It does not establish return on investment by itself.

It does not indicate that one adoption phase is inherently better than another.

What it does provide is a more granular picture of how Copilot usage changes over time.

For organizations already investing in AI-assisted development, that visibility is likely more useful than another active-user chart. The most valuable outcome is not knowing who opened Copilot. It is understanding whether usage is progressing from isolated features toward broader workflow integration, and whether that progression aligns with measurable engineering outcomes.