GitHub Copilot adoption is no longer limited to measuring how many developers have a Copilot license or how many code completions they accept.
As AI-assisted development expands from inline suggestions to chat, agent mode, code review, CLI workflows, and dedicated agent experiences, engineering teams need more detailed metrics to understand how developers actually use these capabilities.
GitHub Copilot usage metrics provide enterprise and organization-level visibility into adoption, engagement, code generation, agent activity, and pull request trends. GitHub has also added metrics specifically for the dedicated VS Code Agents window, making it possible to measure adoption of that workflow separately from traditional editor Agent Mode.
This distinction is important.
A developer using Copilot Chat is not necessarily using an agent. A developer using Agent Mode is not necessarily using the dedicated VS Code Agents window. Treating all of these activities as one metric can hide important differences in how teams are adopting AI-assisted development.
This article explains how to measure Copilot adoption effectively, how VS Code Agent metrics fit into the larger Copilot metrics model, and how engineering teams can turn the raw data into useful adoption insights.
Why Copilot Adoption Needs Better Metrics
A simple license count tells you how many developers have access to Copilot.
It does not tell you whether they actually use it.
For example:
100 developers have Copilot licenses
|
+--> 80 used Copilot
|
+--> 55 used Chat
|
+--> 30 used Agent
|
+--> 18 used VS Code Agents
These numbers represent very different levels of adoption.
A team with 100 licensed developers and 10 active users has a different rollout problem from a team with 100 licensed developers and 80 active users but only 5 developers using agent workflows.
Therefore, a useful measurement strategy should separate:
License availability
Active usage
Code completion activity
Chat usage
Agent adoption
VS Code Agent usage
Code generation
Pull request activity
Adoption progression
What Are GitHub Copilot Usage Metrics?
GitHub Copilot usage metrics provide data through GitHub's dashboards and APIs.
The available metrics cover areas such as:
The data can be viewed at enterprise and organization scopes, while API reports can provide aggregated, user-level, and repository-level information.
The important distinction is that usage metrics are not simply a count of generated code. They are intended to describe how developers engage with different Copilot capabilities.
VS Code Agents Are a Separate Signal
A particularly important recent addition is the dedicated VS Code Agents window.
GitHub's Copilot metrics now include fields for activity in this dedicated window, including:
daily_active_vscode_agent_users
used_vscode_agent
totals_by_vscode_agent
The aggregate data can include:
At the individual-user level, the data can indicate whether a user used the VS Code Agents window and provide session and message totals.
This data is separate from editor-window Agent Mode.
That distinction matters when analyzing adoption.
For example:
Copilot Agent Activity
|
+-- Editor Agent Mode
|
+-- Dedicated VS Code Agents Window
|
+-- Copilot CLI
|
+-- Copilot Cloud Agent
|
+-- Copilot Code Review
A dashboard that combines these signals without distinguishing their source can make adoption appear simpler than it actually is.
Understanding Active Users
One of the first metrics most teams should monitor is active users.
An active user is not simply a user who owns a Copilot license.
It represents actual Copilot interaction during the reporting period.
Useful measurements include:
Metric | What It Tells You |
|---|
Licensed users | Potential Copilot audience |
Daily active users | Daily engagement |
Weekly active users | Consistent short-term adoption |
Monthly active users | Broader recurring adoption |
Agent users | Adoption of agent workflows |
VS Code Agent users | Adoption of the dedicated VS Code Agent experience |
Suppose an organization has:
200 Copilot licenses
150 monthly active users
100 weekly active users
65 agent users
30 VS Code Agent users
The license count alone would hide the adoption progression.
The organization can instead see that:
Licenses
|
v
Active usage
|
v
Agent adoption
|
v
Dedicated agent workflow adoption
This is much more useful for an engineering enablement program.
Measuring VS Code Agent Adoption
A basic VS Code Agent adoption rate can be calculated as:
VS Code Agent Adoption Rate =
Active VS Code Agent Users
--------------------------------
Copilot Active Users
For example:
VS Code Agent users = 30
Copilot active users = 150
30 / 150 × 100 = 20%
This tells you that 20% of active Copilot users used the dedicated VS Code Agents window during the selected period.
Do not confuse this with overall Copilot adoption.
A separate metric can measure Copilot activation:
Copilot Adoption =
Active Copilot Users
--------------------
Licensed Copilot Users
Using the same example:
150 / 200 × 100 = 75%
Now the organization has two useful signals:
Copilot adoption: 75%
VS Code Agent adoption: 20%
These numbers answer different questions.
Measuring Agent Engagement
Adoption alone is not enough.
A user who opens an agent once is different from a developer who uses it every day.
This is where session and message data becomes useful.
For example:
Developer A
1 VS Code Agent session
2 messages
Developer B
18 VS Code Agent sessions
140 messages
Both developers count as users, but their engagement levels are very different.
A team can calculate average messages per session:
Average Messages per Session =
Total User Messages
-------------------
Total Sessions
Suppose:
Total sessions = 500
Total messages = 4,000
Then:
4,000 / 500 = 8 messages per session
This does not prove productivity improvement, but it provides a useful signal for understanding how deeply developers are engaging with the workflow.
Measuring Adoption by Team
GitHub does not provide one pre-aggregated team-level usage report for every Copilot metric.
Instead, team-level metrics can be constructed by joining user-team data with per-user usage data.
Conceptually:
User-Team Report
|
| user_id
v
Per-User Usage Report
|
v
Join
|
v
Team-Level Metrics
For example:
User A -> Team Payments
User B -> Team Payments
User C -> Team Platform
User D -> Team Platform
The corresponding Copilot activity can then be aggregated by team.
A simplified dataset might look like:
User | Team | Copilot Active | Agent Used | VS Code Agent |
|---|
User A | Payments | Yes | Yes | Yes |
User B | Payments | Yes | No | No |
User C | Platform | Yes | Yes | Yes |
User D | Platform | Yes | Yes | No |
The organization can then calculate team-specific adoption.
Example Team Dashboard
A useful engineering dashboard might contain:
Team | Copilot Adoption | Agent Adoption | VS Code Agent Adoption | Avg. Sessions |
|---|
Payments | 86% | 52% | 31% | 9.4 |
Platform | 92% | 71% | 48% | 12.7 |
Mobile | 74% | 35% | 18% | 6.1 |
Data | 81% | 47% | 29% | 7.8 |
The purpose of this dashboard is not to rank developers.
It should help engineering leaders identify where enablement, training, documentation, or workflow improvements are needed.
Code Completion Acceptance Rate
Traditional Copilot adoption analysis often focuses on completion acceptance.
The basic calculation is:
Acceptance Rate =
Accepted Suggestions
--------------------
Suggested Completions
For example:
Suggested completions = 10,000
Accepted completions = 3,500
Acceptance Rate = 35%
A higher acceptance rate can indicate that suggestions are relevant to the developer's workflow.
However, acceptance rate should not be treated as a direct productivity metric.
A developer may accept fewer suggestions because they use Agent Mode extensively.
Another developer may have a high completion acceptance rate while spending little time using other Copilot features.
Therefore:
Acceptance Rate
+
Agent Adoption
+
Usage Frequency
+
Engineering Outcomes
provides a more complete picture.
Measuring Code Generation
Copilot usage metrics also expose directional lines-of-code measurements.
These can include:
For example:
Suggested LOC
|
v
Accepted / Added LOC
|
v
Deleted LOC
These numbers can help understand the scale of AI-assisted code generation.
However, lines of code should not be treated as a direct measurement of developer productivity.
Producing more code is not automatically better.
A well-designed refactoring can reduce thousands of lines of code while improving the system.
Therefore, LOC metrics should be treated as activity indicators rather than quality or business-value metrics.
Adoption Phases
GitHub's usage metrics also provide AI adoption phases.
The current model groups users according to engagement with different Copilot capabilities.
Conceptually, adoption can progress from:
Passive / No Cohort
|
v
Phase 1: Code First
|
v
Phase 2: Agent First
|
v
Phase 3: Multi-Agent
The classification is based on feature engagement over a rolling period rather than simply whether a user owns a license.
This allows an organization to understand how developers are progressing through Copilot capabilities.
For example:
Team A
Phase 1: 60%
Phase 2: 30%
Phase 3: 10%
might indicate that most developers are still primarily using code completion and basic AI-assisted workflows.
Another team might have:
Phase 1: 25%
Phase 2: 45%
Phase 3: 30%
indicating deeper adoption of agent-oriented workflows.
Do Not Measure Adoption as a Competition
One of the biggest mistakes engineering organizations can make is turning Copilot metrics into developer rankings.
For example, avoid creating a leaderboard such as:
Developer A: 8,000 generated lines
Developer B: 6,500 generated lines
Developer C: 4,100 generated lines
This encourages the wrong behavior.
Instead, use metrics to answer questions such as:
Which teams have low activation?
Which teams are adopting agents?
Which workflows are most commonly used?
Where is additional training required?
Are developers moving from basic completion toward agent-assisted workflows?
Are engineering outcomes improving alongside adoption?
Metrics should support enablement rather than surveillance.
Combining Copilot Metrics With Engineering Metrics
Copilot metrics become much more useful when combined with normal software delivery metrics.
For example:
Copilot Metrics
|
+--> Adoption
+--> Agent Usage
+--> Code Generation
|
v
Engineering Metrics
|
+--> Pull Requests
+--> Review Time
+--> Merge Time
+--> Defect Rate
+--> Deployment Frequency
This allows teams to ask better questions.
For example:
Did increased agent adoption coincide with:
- Faster pull request completion?
- Stable or improved defect rates?
- Reduced review bottlenecks?
- More frequent deployments?
These correlations do not automatically establish causation, but they provide a much stronger evaluation framework than raw Copilot usage alone.
Pull Request Metrics
GitHub's metrics ecosystem can also provide pull request lifecycle information.
Useful measurements include:
A useful dashboard might compare:
Metric | Before Rollout | After Rollout |
|---|
Pull requests merged | 420 | 465 |
Median time to merge | 2.4 days | 2.0 days |
Agent adoption | 12% | 38% |
VS Code Agent adoption | 4% | 21% |
Again, these numbers should be interpreted carefully.
Changes in team size, project complexity, release schedules, and engineering processes can influence the results.
Building a Practical Measurement Pipeline
For larger organizations, the API is more useful than manually reading dashboards.
A typical pipeline looks like:
GitHub Copilot Metrics API
|
v
Download Reports
|
v
NDJSON Processing
|
v
Data Warehouse
|
v
BI Dashboard
|
v
Engineering Leadership
The reports can be retrieved for enterprise or organization scopes depending on the permissions and reporting requirements.
A data pipeline might normalize records into a structure such as:
Date
UserId
Organization
Team
IDE
Feature
AgentUsed
VSCodeAgentUsed
Sessions
Messages
CodeGenerated
PullRequests
This makes downstream analysis easier.
Example Data Processing Model
Suppose a daily user record contains:
{
"user_id": 12345,
"day": "2026-09-14",
"used_agent": true,
"used_vscode_agent": true,
"loc_added_sum": 42
}
A reporting pipeline can transform that into:
Date: 2026-09-14
User: 12345
Agent Used: Yes
VS Code Agent Used: Yes
LOC Added: 42
Team membership can then be joined from the user-team report.
The resulting dataset can support custom reporting without changing the original GitHub telemetry.
Data Freshness Matters
Usage metrics are not necessarily real-time operational telemetry.
Reports are generated and processed on a schedule.
Therefore, an executive dashboard should clearly display:
Reporting Period
Last Updated
Data Coverage
For example:
Reporting Period: Last 28 Days
Data Updated: 14 Sept 2026
This prevents users from interpreting a reporting dashboard as a live activity monitor.
Important Metric Definitions
Different Copilot reports can use different scopes and aggregation levels.
For example:
Enterprise
|
+--> Organization
|
+--> User
|
+--> Repository
A metric calculated at enterprise level may not be directly comparable with a user-level record without considering the aggregation method.
Similarly, dashboard metrics and API fields should be reconciled using their documented definitions.
Before creating custom KPIs, document:
Metric Name
Definition
Data Source
Time Window
Aggregation
Population
For example:
Metric:
VS Code Agent Adoption
Definition:
Unique active users of the dedicated VS Code Agents
window during the reporting period.
Denominator:
Copilot active users.
Window:
28 days.
This makes the KPI reproducible.
Common Mistakes
Counting Licenses as Adoption
Having a Copilot license does not mean the developer actively uses Copilot.
Measure active users separately.
Combining Different Agent Surfaces
Editor Agent Mode, VS Code Agents, Copilot CLI, cloud agent, and code review represent different workflows.
Keep their signals distinct when the business question requires it.
Treating LOC as Productivity
More generated code does not automatically mean more value.
Use code-generation metrics as directional activity indicators.
Ignoring Team Context
Enterprise-wide adoption can hide teams with very low engagement.
Use team-level reporting when enablement decisions are team-specific.
Ranking Individual Developers
Usage metrics should not become a competition.
High usage does not automatically mean high productivity or high-quality engineering.
Comparing Incompatible Windows
Do not compare a seven-day active-user metric with a 28-day agent metric without accounting for the different populations and windows.
Ignoring Data Freshness
Dashboards based on delayed reports should not be presented as real-time monitoring systems.
Recommended Copilot KPI Framework
A practical enterprise KPI model can use four layers.
Layer 1: Availability
Licensed Users
Activated Users
This measures whether Copilot is actually available and activated.
Layer 2: Engagement
DAU
WAU
MAU
Chat Requests
Completion Acceptance
This measures recurring usage.
Layer 3: Agent Adoption
Agent Users
VS Code Agent Users
CLI Users
Cloud Agent Users
Code Review Users
This measures progression toward more advanced workflows.
Layer 4: Engineering Outcomes
Pull Requests
Time to Merge
Review Activity
Deployment Frequency
Defect Trends
This measures whether adoption is associated with meaningful engineering outcomes.
The layers can be visualized as:
Engineering Outcomes
^
|
Agent Adoption
^
|
Usage
^
|
Activation
^
|
Licenses
This is a better measurement model than focusing on a single Copilot metric.
Best Practices
Measure active usage rather than licenses alone.
Track agent adoption separately from basic Copilot usage.
Treat the dedicated VS Code Agents window as its own signal.
Measure adoption by team when enablement decisions are team-specific.
Use rolling windows consistently.
Document every custom KPI's denominator and reporting period.
Combine Copilot telemetry with engineering delivery metrics.
Treat LOC as a directional metric, not a productivity score.
Avoid individual developer leaderboards.
Account for data freshness when presenting dashboards.
Keep different Copilot agent surfaces distinguishable.
Reconcile dashboard and API definitions before building custom reports.
Use adoption phases to understand progression rather than simply measuring feature usage.
Review qualitative developer feedback alongside quantitative metrics.
Conclusion
GitHub Copilot usage metrics provide engineering organizations with a much richer view of AI-assisted development than license counts or code-completion acceptance rates alone.
The addition of dedicated VS Code Agent metrics makes this analysis even more useful because teams can distinguish the dedicated VS Code Agents workflow from other forms of agent usage.
A mature measurement strategy should therefore move through several layers:
Licenses
|
v
Active Users
|
v
Feature Engagement
|
v
Agent Adoption
|
v
Team Adoption
|
v
Engineering Outcomes
The goal is not to determine which developer uses the most AI.
The goal is to understand whether teams are adopting Copilot effectively, which workflows are gaining traction, where developers need support, and whether increased AI adoption is accompanied by meaningful improvements in software delivery.
When Copilot usage data is combined with team structure, pull request activity, delivery metrics, and qualitative feedback, engineering leaders can move from simply asking "Are developers using Copilot?" to much more useful questions such as "Where is Copilot changing the development workflow, and is that change producing measurable engineering value?"
Join the conversation! Your thoughts help the community grow.