| title | GitHub Copilot usage metrics | |||||||
|---|---|---|---|---|---|---|---|---|
| shortTitle | Copilot usage metrics | |||||||
| intro | {% data variables.product.prodname_copilot_short %} usage metrics provide visibility into how {% data variables.product.prodname_copilot_short %} is adopted and used across your organization, including engagement, activity, code generation, and pull request lifecycle trends. | |||||||
| versions |
|
|||||||
| contentType | concepts | |||||||
| allowTitleToDifferFromFilename | true | |||||||
| redirect_from |
|
|||||||
| category |
|
{% data variables.product.prodname_copilot_short %} usage metrics help key stakeholders and decision-makers understand how their teams are adopting and using {% data variables.product.prodname_copilot_short %}. 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 {% data variables.product.prodname_copilot_short %} usage metrics APIs, which provide detailed, exportable data at the enterprise, organization, repository, and user levels.
- The {% data variables.product.prodname_copilot_short %} 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 {% data variables.product.prodname_copilot_short %} impact dashboard, which groups users into adoption cohorts and connects that adoption to pull request output.
- The {% data variables.product.prodname_copilot_short %} usage metrics NDJSON export, which offers raw data for custom BI tools or long-term storage.
{% data variables.product.prodname_copilot_short %} usage metrics are derived from telemetry across multiple {% data variables.product.prodname_copilot_short %} surfaces, including IDE, {% data variables.copilot.copilot_cli_short %}, and {% data variables.copilot.agent_apps %} 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, {% data variables.product.prodname_copilot_short %} 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 {% data variables.product.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 {% data variables.product.prodname_copilot_short %} 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 {% data variables.product.prodname_copilot_short %} surfaces, such as:
- {% data variables.copilot.copilot_chat_short %} on {% data variables.product.prodname_dotcom_the_website %}
- {% data variables.product.prodname_mobile %}
License and seat management data are not included in {% data variables.product.prodname_copilot_short %} usage metrics reports. To view or manage license assignments, use the {% data variables.product.prodname_copilot_short %} user management API, which is the source of truth for license and seat information. See AUTOTITLE.
Why {% data variables.product.prodname_copilot_short %} usage metrics may differ across API resources
The following API resources expose {% data variables.product.prodname_copilot_short %}-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 {% data variables.product.prodname_copilot_short %} usage metrics API for new integrations and analyses, as it provides the most complete and future-facing view of {% data variables.product.prodname_copilot_short %} usage.
| API resource | Scope | Key capabilities |
|---|---|---|
| AUTOTITLE | 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. |
| AUTOTITLE | License and seat assignment | Lists assigned {% data variables.product.prodname_copilot_short %} 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. |
Note
You can grant organization-only visibility into {% data variables.product.prodname_copilot_short %} usage metrics without providing enterprise-level access.
You can do this by creating an organization custom role that includes the "View organization {% data variables.product.prodname_copilot_short %} metrics" permission, and assigning that role to users who need visibility into metrics for a single organization. See AUTOTITLE.
Organization-level {% data variables.product.prodname_copilot_short %} 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 {% data variables.product.prodname_copilot_short %} 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 {% data variables.product.prodname_copilot_short %} 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 {% data variables.product.prodname_copilot_short %} 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 {% data variables.product.prodname_copilot_short %} seat or where the activity originated.
To be included in the {% data variables.product.prodname_copilot_short %} usage metrics, end users must use one of the following IDEs and {% data variables.copilot.copilot_chat_short %} extension versions.
| IDE | Minimum IDE version | Minimum {% data variables.copilot.copilot_chat_short %} extension version |
|---|---|---|
| Eclipse | 4.31 | 0.9.3.202507240902 |
| JetBrains / IntelliJ | 2024.2.6 | 1.5.52-241 |
| {% data variables.product.prodname_vs %} | 17.14.13 | 18.0.471.29466 |
| {% data variables.product.prodname_vscode_shortname %} | 1.107.1 | 0.35.3 |
| Xcode | 13.2.1 | 0.40.0 |
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.
{% data variables.product.prodname_copilot_short %} 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 {% data variables.product.prodname_copilot_short %}. For example, daily active users (DAU) tells you how many unique users interacted with {% data variables.product.prodname_copilot_short %} on a given day. Ideally, you'll see a consistent upward trend in these metrics during rollout. {% data variables.copilot.copilot_code-review_short %} adoption is tracked separately, with distinct active and passive user counts. Active users manually requested a review or applied a suggestion; passive users had {% data variables.copilot.copilot_code-review_short %} 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 {% data variables.product.prodname_copilot_short %} 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 {% data variables.copilot.copilot_chat_short %}. You'd want to see regular and increasing chat use across languages and IDEs.
Acceptance rate measures how often developers accept {% data variables.product.prodname_copilot_short %}’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 {% data variables.product.prodname_copilot_short %} suggested, added, or deleted in the editor, providing a directional view of {% data variables.product.prodname_copilot_short %}’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 {% data variables.product.prodname_copilot_short %} 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 {% data variables.product.prodname_copilot_short %}, you can evaluate how AI-assisted workflows influence throughput and cycle time at the organization or enterprise level.
Rather than measuring adoption as a single active-user count, {% data variables.product.prodname_copilot_short %} groups users into adoption cohorts based on how they engage with {% data variables.product.prodname_copilot_short %}, 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. A passive user may still be using {% data variables.product.prodname_copilot_short %} regularly, for example by asking questions in {% data variables.copilot.copilot_chat_short %} or agent mode without applying any code edits. In the API, this phase is labeled No Cohort. |
| Phase 1: Code first | The user engaged with code completions and/or agent edits, where {% data variables.product.prodname_copilot_short %} writes changes directly into files in the IDE. Using {% data variables.copilot.copilot_chat_short %} or agent mode without producing code completion or agent edit activity does not qualify on its own. |
| Phase 2: Agent first | The user engaged with a single {% data variables.product.github %}-based agent surface, such as {% data variables.copilot.copilot_cloud_agent %}, {% data variables.copilot.copilot_code-review_short %}, or {% data variables.copilot.copilot_cli_short %}. Both active engagement with {% data variables.copilot.copilot_code-review_short %} and having it automatically assigned to review a pull request count as the same surface. |
| Phase 3: Multi-agent | The user engaged with two or more {% data variables.product.github %}-based agent surfaces, or with the {% data variables.copilot.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.
The impact dashboard counts every user who was active during the trailing 28-day window and groups each user by their current phase. The phase classification rules are the same, but the dashboard population is broader than the totals_by_ai_adoption_phase.total_engaged_users field in API and NDJSON reports, which counts users who were active on a specific day.
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 {% data variables.copilot.copilot_chat_short %} on {% data variables.product.prodname_dotcom_the_website %}, 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.
The impact dashboard's Potential return on investment section provides a comparison of cost and pull request output between Phase 0-1 Passive and Code First Users and Phase 2-3 Agent First Users.
For each phase group, the dashboard shows the monthly {% data variables.product.prodname_copilot_short %} cost per developer, based on actual {% data variables.product.prodname_ai_credits_short %} consumption, and that cost as a percentage of developer compensation. It also shows average pull requests per developer per month.
You can select a compensation band to update estimates that depend on developer compensation. These figures are estimates rather than exact financial results, so interpret them alongside the adoption multiplier's code-shipped and time-to-merge comparisons. The return-on-investment estimates are available only in the dashboard and are not included in the {% data variables.product.prodname_copilot_short %} usage metrics API or NDJSON exports.
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.
These metrics can be used together to answer key questions about your teams' usage of {% data variables.product.prodname_copilot_short %}.
| Question | Use these metrics |
|---|---|
| Are my teams using {% data variables.product.prodname_copilot_short %} regularly? | Daily and weekly active users |
| Which features deliver the most value? | Requests per chat mode, agent adoption |
| Do developers trust {% data variables.product.prodname_copilot_short %}’s output? | Acceptance rate trends |
| Are enablement efforts working? | Growth in adoption and engagement after training or communication campaigns |
| Is {% data variables.product.prodname_copilot_short %} influencing delivery speed or pull request throughput? | Pull request merge counts and median time to merge |
| How is {% data variables.copilot.copilot_code-review_short %} 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 AUTOTITLE |
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.