About Copilot usage metrics
Copilot usage metrics help key stakeholders and decision-makers understand how their teams are adopting and using Copilot. By tracking usage patterns across the enterprise, you can measure engagement, identify opportunities to increase value, and assess how AI-assisted workflows influence pull request throughput and time to merge.
Metrics are available through:
- The Copilot usage metrics APIs, which provide detailed, exportable data at the enterprise, organization, repository, and user levels.
- The Copilot usage metrics dashboard, which visualizes 28-day usage trends across your enterprise and organizations.
- The code generation dashboard, which breaks down how code is being generated by users and agents across your enterprise and organizations.
- The Copilot impact dashboard, which groups users into adoption cohorts and connects that adoption to pull request output.
- The Copilot usage metrics NDJSON export, which offers raw data for custom BI tools or long-term storage.
Which usage is included?
Copilot usage metrics are derived from telemetry across multiple Copilot surfaces, including IDE and Copilot CLI activity. Most metrics come from client-side IDE telemetry, and end users need telemetry enabled in their IDE for the richest data in these metrics.
In addition, Copilot usage metrics incorporate server-side telemetry to identify active users that client-side telemetry alone may miss. Network conditions, proxy configurations, and client settings can prevent client telemetry from reaching GitHub, so server-side signals ensure those users still appear in your reports.
Users surfaced through server-side telemetry are fully counted toward your active user totals (such as daily active users, daily_active_users ). When available, they may also appear in totals_by_ide (including the most recently detected IDE and Copilot extension versions in per-user reports). However, other dimensional breakdowns—such as totals_by_feature and lines-of-code metrics—remain empty until richer telemetry is available for them. Top-level totals and breakdowns for users already captured by client telemetry are unchanged.
The data does not include activity from other Copilot surfaces, such as:
- Copilot Chat on GitHub.com
- GitHub Mobile
License and seat management data are not included in Copilot usage metrics reports. To view or manage license assignments, use the Copilot user management API, which is the source of truth for license and seat information. See REST API endpoints for Copilot user management.
Why Copilot usage metrics may differ across API resources
The following API resources expose Copilot-related data, but they are not interchangeable and should not be compared directly. Each API resource is designed for a specific use case and data model, and differences in totals or coverage are expected. Use this table to understand which API resource best fits your reporting needs.
Note
We strongly recommend using the Copilot usage metrics API for new integrations and analyses, as it provides the most complete and future-facing view of Copilot usage.
| API resource | Scope | Key capabilities |
|---|---|---|
| REST API endpoints for Copilot usage metrics | Advanced enterprise- and organization-scoped event telemetry with repository- and user-level reports | Provides unified telemetry across completions, chat, and agent modes. Includes usage and lines of code metrics across all IDE modes, languages, and models. Supports detailed breakdowns by feature, IDE, language, model, and user, as well as repository-level pull request activity reports, and is the primary API resource being actively developed and maintained. |
| REST API endpoints for Copilot user management | License and seat assignment | Lists assigned Copilot seats for an organization or enterprise, including license state, user association, and last_activity_at. This API resource is the source of truth for license and seat information. |
How are metrics attributed across organizations?
Note
You can grant organization-only visibility into Copilot usage metrics without providing enterprise-level access.
You can do this by creating an organization custom role that includes the "View organization Copilot metrics" permission, and assigning that role to users who need visibility into metrics for a single organization. See Permissions of custom organization roles.
Organization-level Copilot usage metrics are based on organization membership, not on where individual actions occur. To appear in an enterprise’s metrics, a user must have an active Copilot seat assigned within that enterprise (in any organization that belongs to the enterprise). As a result, a single user’s usage may appear in multiple organization dashboards, while that same user is counted only once in the enterprise-level total. Organization-level analytics are intended for visibility into adoption and usage within an organization and are not designed to be directly compared to enterprise-level totals.
Organization-level Copilot analytics are available starting December 12, 2025. This is the first date for which organization-level reports are provided.
Once a user has a seat in the enterprise, their usage is attributed to every organization they belong to, regardless of where the seat is assigned.
This means:
- If licenses are assigned in a dedicated “shell” organization for administrative purposes within the enterprise, users still appear in the metrics for all other organizations in the enterprise they belong to.
- If a user also has a Copilot seat in a separate organization outside the enterprise, their activity is still included in the enterprise’s organization-level metrics as long as they have at least one seat within the enterprise.
In short: users must be licensed somewhere in the enterprise to appear in its metrics. Once they are, metrics reflect where they work (their organization membership), not which organization provides the Copilot seat or where the activity originated.
Supported IDEs
To be included in the Copilot usage metrics, end users must use one of the following IDEs and Copilot Chat extension versions.
| IDE | Minimum IDE version | Minimum Copilot Chat extension version |
|---|---|---|
| Eclipse | 4.31 | 0.9.3.202507240902 |
| JetBrains / IntelliJ | 2024.2.6 | 1.5.52-241 |
| Visual Studio | 17.14.13 | 18.0.471.29466 |
| VS Code | 1.107.1 | 0.35.3 |
| Xcode | 13.2.1 | 0.40.0 |
Data freshness
The data in the dashboards and API reports is updated on a regular schedule.
You can expect data to be available within two full days. This means that data for a given day is processed and made available within two full UTC days after that day closes.
What does the data measure?
Copilot usage metrics can be grouped into a few main categories: Adoption, engagement, acceptance rate, Lines of Code (LoC), and pull request lifecycle metrics.
Adoption measures how many licensed developers are actively using Copilot. For example, daily active users (DAU) tells you how many unique users interacted with Copilot on a given day. Ideally, you'll see a consistent upward trend in these metrics during rollout. Copilot code review adoption is tracked separately, with distinct active and passive user counts. Active users manually requested a review or applied a suggestion; passive users had Copilot code review automatically assigned to review their pull request. When a user has both signals in the same period, they are counted as active only. For a deeper view of adoption depth, users are also grouped into adoption cohorts. See Understanding adoption cohorts.
Engagement measures describe how deeply developers use Copilot once they’ve adopted it. Key engagement metrics show not only frequency of use but also breadth across features. For example, average chat requests per active user measures how often users open and interact with Copilot Chat. You'd want to see regular and increasing chat use across languages and IDEs.
Acceptance rate measures how often developers accept Copilot’s suggestions. This helps you understand whether suggestions are relevant and trusted. For example, a high inline suggestions acceptance rate indicates that suggestions are relevant and useful.
Lines of Code (LoC) metrics measure the number of lines Copilot suggested, added, or deleted in the editor, providing a directional view of Copilot’s tangible output. For example, "Lines added" shows how much code was actually accepted and inserted into the editor.
Pull request lifecycle metrics measure how Copilot activity relates to pull request outcomes and delivery flow. These metrics include pull request creation and merge counts, median time to merge, and review suggestion activity. By comparing overall pull request activity with pull requests created by Copilot, you can evaluate how AI-assisted workflows influence throughput and cycle time at the organization or enterprise level.
Understanding adoption cohorts
Rather than measuring adoption as a single active-user count, Copilot groups users into adoption cohorts based on how they engage with Copilot, not just whether they engage at all. A flat active-user count treats someone who occasionally accepts a code completion the same as someone who orchestrates multiple agent-driven workflows throughout the day. Cohorting separates these two users, so you can see whether your organization's usage is deepening over time rather than plateauing at initial trial.
Users are grouped into the following phases:
| Phase | What it represents |
|---|---|
| Passive users | The user has not met the engagement threshold for a phase during the period. In the underlying data, this phase is labeled No Cohort. |
| Phase 1: Code first | The user engaged with code completions and/or IDE agent mode. |
| Phase 2: Agent first | The user engaged with a single GitHub-based agent surface, such as Copilot cloud agent, Copilot code review, or Copilot CLI. Only active engagement with Copilot code review counts here; having it automatically assigned to review a pull request without further engagement does not. |
| Phase 3: Multi-agent | The user engaged with two or more GitHub-based agent surfaces, or with the GitHub Copilot app. |
To be grouped into a phase, a user must meet an engagement threshold of at least two active days out of the trailing 28-day window, using the surfaces associated with that phase. A user only needs two qualifying days on a higher phase's surfaces to progress to that phase. Agent usage alone can qualify a user, without separate days of plain completions.
Phase assignment is recalculated daily from the trailing 28-day window, so a user's phase can shift from one day to the next as their activity within that window changes. This is expected behavior, not a data error.
Users who haven't met any phase's threshold are grouped into Passive users, which is not a measure of inactivity, but a signal that a user's engagement hasn't yet reached the level needed to reliably classify their adoption depth. For example, a user with fewer than two active days in the trailing 28-day window, or one who only lightly uses a surface like Copilot Chat on GitHub.com, shows as a passive user.
Because phase assignment is based on which surfaces a user engages with, not simply how many actions they take, a user with high completion volume but no agent usage stays in Phase 1, while a user with lighter but broader usage across agent surfaces progresses to Phase 2 or Phase 3.
For the underlying schema fields, see AI adoption phase fields.
The impact dashboard's adoption multiplier divides the average amount of pull requests merged for engaged users, which are ones in Phase 1, 2, or 3, by the amount of pull requests merged for Passive users.
This shows the relative impact of deeper adoption, independent of how many users fall into each phase. This is a measurement to understand the potential lift that becoming a more engaged user can provide.
For example, if users in the engaged cohorts averaged 20 pull requests/user/month and the passive cohort averaged 10, then the equation is 20 / 10 = 2x multiplier.
Interpreting pull request lifecycle metrics across scopes
Pull request lifecycle metrics are available at both the organization and enterprise level. When comparing reports, keep the following in mind:
- Deduplication: Enterprise-level reports deduplicate users across organizations. Organization-level reports do not.
- Pull request-only data: Pull request lifecycle metrics may appear even if IDE usage metrics are absent, since pull request data is derived from repository activity.
- Attribution timing: If a repository or organization is transferred between owners, pull request creation, review, and merge events may be attributed to different entities depending on when each event occurred.
How can I use these metrics?
These metrics can be used together to answer key questions about your teams' usage of Copilot.
| Question | Use these metrics |
|---|---|
| Are my teams using Copilot regularly? | Daily and weekly active users |
| Which features deliver the most value? | Requests per chat mode, agent adoption |
| Do developers trust Copilot’s output? | Acceptance rate trends |
| Are enablement efforts working? | Growth in adoption and engagement after training or communication campaigns |
| Is Copilot influencing delivery speed or pull request throughput? | Pull request merge counts and median time to merge |
| How is Copilot code review being adopted? | Active versus passive code review user counts |
| Is my organization's adoption deepening over time? | Adoption cohort distribution and engagement trends |
| How do I act on the insights from the dashboard? | See Interpreting usage and adoption metrics for GitHub Copilot |
Look for patterns across these signals rather than focusing on any single number. For example, a steady DAU paired with a rising acceptance rate indicates growing trust and value.
Next steps
Now that you understand what each Copilot metric measures and how to use them, you can explore the dashboards to see these metrics in action.
- To view adoption and usage trends across your enterprise and organizations, see Viewing the Copilot usage metrics dashboard.
- To analyze how code is being generated by users and agents, see Viewing the code generation dashboard.
- To view adoption cohorts and depth of adoption, see Viewing the Copilot impact dashboard.
- To access Copilot usage metrics programmatically, see REST API endpoints for Copilot usage metrics.
- To construct team-level metrics by aggregating per-user records, see Team-level Copilot usage metrics.