GitHub Copilot Usage Metrics: Measuring VS Code Agent Adoption Across Development Teams

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:

• Daily active users

• Weekly active users

• Total active users

• Code completions

• Completion acceptance rate

• Chat requests

• Agent adoption

• Language usage

• Model usage

• Code generation

• Pull request activity

• AI adoption phases

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:

• Number of active VS Code Agent users

• Agent session count

• Total user messages

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:

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:

The organization can then calculate team-specific adoption.

Example Team Dashboard

A useful engineering dashboard might contain:

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:

• Lines suggested

• Lines accepted or added

• Lines deleted

• Code generated through different Copilot features

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:

• Pull requests created

• Pull requests merged

• Time to merge

• Copilot-related pull request activity

• Code review activity

A useful dashboard might compare:

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

1. Measure active usage rather than licenses alone.

2. Track agent adoption separately from basic Copilot usage.

3. Treat the dedicated VS Code Agents window as its own signal.

4. Measure adoption by team when enablement decisions are team-specific.

5. Use rolling windows consistently.

6. Document every custom KPI's denominator and reporting period.

7. Combine Copilot telemetry with engineering delivery metrics.

8. Treat LOC as a directional metric, not a productivity score.

9. Avoid individual developer leaderboards.

10. Account for data freshness when presenting dashboards.

11. Keep different Copilot agent surfaces distinguishable.

12. Reconcile dashboard and API definitions before building custom reports.

13. Use adoption phases to understand progression rather than simply measuring feature usage.

14. 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?"