GitHub Copilot Usage Metrics Need an IDE Update to Count Agent Activity

A team can look at its GitHub Copilot dashboard and conclude that agent usage is falling even while developers are clearly using Copilot more. That sounds contradictory, but the problem may not be developer behavior at all.

GitHub has identified a telemetry issue affecting Copilot usage metrics after several IDEs moved Copilot agent sessions to the Copilot SDK. Those sessions did not identify the IDE they came from correctly, so some agent activity was missing from usage reports and some activity was attributed to Copilot CLI instead. GitHub has released a fix in Visual Studio Code and is rolling the correction into other supported IDEs.

For organizations that use Copilot metrics to measure adoption, this is more than a version-update recommendation. It is a reminder that AI development metrics depend heavily on where the telemetry originates and how the client reports that activity.

Why Copilot Agent Metrics Can Suddenly Look Wrong

Copilot usage metrics are built from more than one source.

GitHub collects client-side telemetry from supported IDEs and also uses server-side telemetry for some activity. Client-side telemetry provides richer information because the IDE knows what happened inside the editor. It can report information such as the IDE, feature used, language, model, and lines of code changed.

Server-side telemetry can help identify active users when detailed client telemetry is unavailable, but it cannot see everything that happened inside the editor.

That difference matters for agent activity.

An agent can modify files directly inside the IDE, and those edits contribute to metrics such as agent-initiated lines of code. If the IDE does not send the expected telemetry, the server may know that the developer was active without being able to reconstruct all of the detailed editor activity.

The result is a report that can look incomplete even though Copilot itself is working normally.

What Changed With the Copilot SDK

The immediate issue came from a change in how several IDEs handled Copilot agent sessions.

Some IDEs moved those sessions to the Copilot SDK. The affected sessions did not identify which IDE they originated from, which meant GitHub could not attribute the activity correctly in its usage metrics. Much of the activity was therefore omitted from reports, while some activity could appear as Copilot CLI activity.

The distinction is important because this is a reporting problem, not a Copilot billing problem.

GitHub states that billing was not affected. The problem changed how agent activity was attributed in usage metrics, including agent interactions and agent lines-of-code measurements.

So if an engineering manager noticed something like this:

Copilot usage:          Increasing
Agent adoption:         Increasing
Agent lines of code:    Decreasing

the numbers should not automatically be interpreted as developers becoming less productive with agents.

The telemetry path itself may be responsible.

Which IDE Versions Are Affected?

GitHub has started rolling out fixes by IDE.

Visual Studio Code already has the fix in version 1.139.0 and later. Visual Studio 18.12 is expected to receive the fix in October 2026, while JetBrains, Eclipse, and Xcode fixes are expected through October and November.

The current rollout information is:

The practical implication for organizations is straightforward: if Copilot metrics are important to your reporting, IDE version management is part of your metrics strategy.

Why Updating the IDE Matters

It is easy to treat IDE updates as a developer-experience concern. In an organization using Copilot analytics, they can also affect management data.

Suppose a company has 500 developers and relies on agent usage metrics to understand adoption. If a portion of those developers remain on affected IDE versions, their agent activity can remain undercounted until they update.

GitHub also states that the missing activity cannot be backfilled. Because the affected telemetry did not identify the originating IDE correctly, GitHub cannot reliably reconstruct and attribute the historical activity later.

That means delaying the update does not simply postpone accurate reporting. It can permanently leave a gap in the historical dataset.

For organizations comparing month-over-month adoption, this matters.

A sudden increase after an IDE rollout may partly represent restored telemetry, rather than an equivalent increase in actual developer behavior.

What Happens to Copilot CLI Metrics?

There is another side effect worth understanding.

Some activity that should have been associated with IDE-based agent sessions was attributed to Copilot CLI. GitHub says this can cause Copilot CLI metrics to appear inflated. Those historical CLI metrics cannot be corrected because the affected activity cannot be separated reliably from genuine CLI usage.

This creates an important reporting trap.

If you see:

IDE agent activity ↓
CLI activity ↑

during the affected period, it would be risky to conclude that developers suddenly moved from IDE agents to the CLI.

The numbers may reflect attribution problems rather than an actual workflow change.

Agent Activity Is Not the Same as Active Users

Another common source of confusion is mixing high-level active-user metrics with detailed agent metrics.

GitHub's current usage metrics combine client-side and server-side telemetry to identify active Copilot users. Server-side signals can therefore help keep active-user totals more complete even when IDE telemetry is missing.

But detailed metrics are different.

For example, lines of code and feature-level breakdowns depend on richer client-side information. If that information is unavailable, the active-user count may still be present while detailed agent metrics are incomplete.

Think about the distinction this way:

Server-side telemetry
        |
        +-- "This user was active"
        |
        X-- Cannot see every editor-level operation

Client-side IDE telemetry
        |
        +-- IDE
        +-- Feature
        +-- Language
        +-- Agent edits
        +-- Lines of code

This explains why two Copilot reports can appear to disagree without either one necessarily being broken.

What Copilot Metrics Actually Measure

Copilot usage metrics include several different categories.

Adoption metrics measure how many licensed developers actively use Copilot. Engagement metrics describe interactions with Copilot features. Other reports provide code-generation and agent-specific information. GitHub's current metrics include fields such as used_agent, loc_added_sum, loc_deleted_sum, and monthly_active_agent_users.

For example, the per-user reports can indicate whether a user used agent mode and how many lines were added or deleted through supported Copilot activity.

The distinction between these fields matters when building internal dashboards.

A metric such as:

monthly_active_agent_users

answers a different question from:

loc_added_sum

The first is about the number of users participating in agent activity. The second is about code changes captured by the telemetry pipeline.

Neither should be treated as a direct measurement of developer productivity.

Do Not Use Lines of Code as a Productivity Score

This issue also highlights a broader problem with AI coding metrics.

A large number of agent-generated lines does not automatically mean better engineering output.

An agent could generate 2,000 lines and then remove most of them after discovering that the implementation was wrong. Another developer might solve the same problem with a small, carefully designed change.

GitHub's metrics can help teams understand adoption and usage patterns, but engineering organizations should be careful about turning individual metrics into performance targets.

For example, this would be a poor management goal:

Increase agent-generated lines of code by 20%.

It creates the wrong incentive.

A better use of the data is to ask questions such as:

Are developers adopting agent workflows?
Which teams are using them?
Which IDEs are being used?
Are agent workflows becoming part of normal development?
Where are developers encountering friction?

The metrics become useful when they help explain engineering behavior rather than rank developers by generated output.

What Engineering Teams Should Check

If your organization depends on Copilot usage reporting, the first step is to identify the IDE versions used by developers.

GitHub specifically recommends keeping IDEs and Copilot extensions current and using device-management tooling to enforce minimum versions where possible. It also recommends ensuring IDE telemetry remains enabled and that network infrastructure does not block the Copilot telemetry endpoint.

A practical checklist is:

1. Identify the IDEs and versions used by your developers.

2. Update affected IDEs as the fixed releases become available.

3. Keep Copilot extensions current.

4. Check whether IDE telemetry is enabled.

5. Verify that corporate proxies and firewalls allow required Copilot telemetry.

6. Review usage metrics after the rollout.

7. Treat historical gaps as known data-quality limitations rather than attempting to reconstruct them from current reports.

The goal is not simply to make the dashboard look better. The goal is to make the data representative of actual development activity.

Common Mistakes

Assuming a Drop in Agent Metrics Means Developers Stopped Using Agents

This is the most obvious interpretation, but it can be wrong.

If agent activity falls at the same time that affected IDE versions are deployed, check the telemetry issue before drawing conclusions about developer adoption.

Comparing CLI and IDE Agent Usage Without Checking Attribution

An increase in CLI metrics combined with a decrease in IDE agent metrics can look like a workflow migration.

During the affected period, however, some IDE-based agent activity could have been incorrectly attributed to Copilot CLI.

Historical comparisons should therefore account for the attribution issue.

Treating the Dashboard as a Complete Source of Truth

Copilot usage metrics are assembled from multiple telemetry sources, and not every metric has the same data requirements.

Active-user counts can benefit from server-side telemetry, while detailed IDE-level and lines-of-code information can still depend on client telemetry.

Understanding that distinction prevents a lot of unnecessary investigation.

Ignoring Version Management

If an organization manages developer machines centrally, leaving IDE versions unmanaged can create recurring reporting gaps.

Minimum supported versions are not only a compatibility concern. For organizations that rely on Copilot analytics, they also affect the quality of the data being collected.

Troubleshooting Unexpected Copilot Metrics

When Copilot usage reports suddenly change, start with the data collection path rather than immediately investigating developer behavior.

Check these areas in order:

IDE version
   ↓
Copilot extension version
   ↓
IDE telemetry
   ↓
Network/proxy configuration
   ↓
Metric processing delay
   ↓
Feature-specific reporting

GitHub notes that usage metrics can take up to two full UTC days to become available, so very recent activity should not necessarily be interpreted as missing.

For per-user reporting, totals_by_ide can also expose the most recently known IDE and Copilot extension versions, which can help identify outdated clients.

This gives administrators a useful way to correlate unusual metrics with client versions instead of investigating every developer individually.

Advantages and Disadvantages

Advantages

More accurate agent reporting after updates: The fixed IDE versions restore attribution for affected agent sessions, making detailed agent activity more representative of actual IDE usage.

Better visibility into AI adoption: When telemetry is working correctly, organizations can distinguish agent usage from other Copilot interactions and analyze adoption across users and teams.

Useful diagnostic information: IDE and extension version information can help administrators identify clients that may be contributing to incomplete metrics.

Disadvantages

Historical data cannot be fully repaired: Activity missed because of the attribution problem cannot be backfilled, so organizations may have a permanent gap in historical reporting.

Metrics depend on client configuration: Telemetry settings, network restrictions, and outdated clients can all affect detailed usage information.

Different metrics have different reliability characteristics: Active-user counts and detailed code-generation metrics can be derived from different telemetry paths, so they should not be interpreted as interchangeable measures.

Attribution problems can distort comparisons: CLI, IDE agent, and other Copilot metrics may appear to change because of telemetry changes rather than because developer behavior actually changed.

Summary

GitHub's Copilot usage metrics recently exposed an important operational reality of AI-assisted development: the accuracy of an organization's AI adoption data depends partly on the software clients collecting that data.

Several IDEs moved Copilot agent sessions to the Copilot SDK without identifying their originating IDE correctly. As a result, some agent activity was missing from reports and some was attributed to Copilot CLI. GitHub has released the fix for Visual Studio Code and is rolling it out to other IDEs.

For engineering teams, the practical response is to keep IDEs and Copilot extensions current, maintain the required telemetry path, and avoid interpreting short-term metric changes without understanding how the data was collected.

Most importantly, Copilot usage metrics should be treated as engineering telemetry, not as a direct measurement of developer productivity. Used correctly, they can show adoption, engagement, and workflow changes. Used without understanding their limitations, they can lead teams to conclusions that the underlying data does not support.