Before calling Copilot adoption down, check IDE attribution

A drop can reflect lost attribution rather than lower use

Before changing a rollout or judging adoption, check whether the reporting system still captures comparable activity. In its October 6 announcement, GitHub says several IDEs moved Copilot agent sessions to the Copilot SDK without identifying the originating IDE. Most of that activity was left out of usage reports; some was counted as Copilot CLI activity. The issue affects IDE versions using the SDK for agent mode. GitHub says developers on earlier versions are still counted. It does not give a first affected version or incident start date for each IDE. [1]

GitHub names agent interactions and agent-edit line counts, including loc_added_sum and loc_deleted_sum for agent_edit, as undercounted until affected clients update. Enterprise, organization and user reports are affected, including both 1-day and 28-day reports. This is a credible explanation for a reporting decline, not evidence that every team's decline is artificial. [1]

GitHub says billing is unaffected: the incident changed attribution in usage metrics, not what customers were charged. Do not turn a lower activity count into a cost-saving claim or use it to reconstruct a bill. [1]

Separate an announced fix from an expected release

The linked supported-IDE documentation lists VS Code 1.107.1 as a generic minimum for metrics support. That is a different threshold from the incident-specific fix at 1.139.0. Meeting a minimum support requirement does not establish that an SDK-based client has the attribution fix. The documentation checked for this briefing does not confirm shipment of the other named fixes. Check current official release and support documentation before deploying one; a forecast month is not an installation target. [1][2]

Do not classify every version below the fix as affected. The announcement distinguishes earlier, unaffected versions from SDK-based agent-mode versions but leaves their exact boundary unspecified. Classify an uncertain client as needing verification, rather than inventing a version range. [1]

An update restores future capture, not the missing history

GitHub says missing agent activity cannot be backfilled because those sessions did not identify their IDE. Historical CLI overcounts also cannot be corrected: the misattributed events cannot be separated from genuine CLI use. Copilot CLI users do not need to update for this incident. Preserve an annotation on affected periods instead of subtracting apparent CLI growth from IDE losses or applying an estimated correction factor. [1]

Stable active-user totals do not settle the agent-usage question. GitHub combines client and server telemetry: server-side signals can count active users whom client telemetry misses, while feature and lines-of-code breakdowns can remain empty. A person can therefore be visible as active without their editor activity being fully represented. Active users measure participation across covered Copilot surfaces, not complete agent-edit capture. [1][2]

Build a comparison you can defend

Use the following procedure before presenting the trend as an adoption finding. It is a proposed audit, not an audit performed on a customer fleet.

• Save the metric definition, report surface, user cohort, scope and UTC dates. Keep active users, IDE-agent events and CLI activity separate. Organization reports follow membership, so one user's activity can appear in multiple organizations while enterprise totals deduplicate users; do not sum organizations into an enterprise comparison. [2]
• Join per-user totals_by_ide entries, including last_known_ide_version and last_known_plugin_version, to managed-device inventory and rollout records. Treat these as last-known observations, not a complete session history. Separate verified fixed clients, verified unaffected earlier clients, potentially affected SDK-based clients and clients whose status is unknown. Record actual installation dates, not expected release dates. [1][2]
• Check that IDE telemetry is enabled, extensions are supported and telemetry can reach GitHub through the existing network configuration. Investigate a missing detail field as a coverage question before treating it as zero use. Server-side active-user counts are a cross-check, not replacement editor events. [1][2]
• Mark periods with missing agent activity or inseparable CLI overcounts as unsuitable for an exact historical adoption comparison. Retain the original report and explain its limit; do not manufacture corrected totals. [1]
• For a new baseline, choose equal-length, preferably non-overlapping UTC periods within the same verified client cohort and report scope after its fix rollout and telemetry checks. A fully post-fix 28-day window avoids carrying pre-fix days into that report. Allow GitHub's documented processing lag of up to two full UTC days after each reporting day closes. Mixed or incomplete windows should not be presented as comparable. [1][2]
• Check delivery evidence separately. Reviewed and merged work, defects, rework and task mix can help interpret whether activity produced useful output. Even a clean interaction or editor-line trend does not establish accepted business output or a causal productivity effect. [2]

This comparison design reduces known reporting differences; it does not guarantee complete capture or isolate the effect of Copilot. A decline that persists across mature, coverage-checked periods still needs investigation as a possible behavioral change.

Worked comparison: recovery is not automatically growth

Hypothetical example, not observed team data: an enterprise sees steady active-user totals, fewer reported IDE-agent edits and more CLI activity after an SDK-based IDE update. It then verifies a fixed-client rollout, and reported IDE-agent activity rises.

• Comparing the affected period with the pre-update period cannot establish an adoption decline: capture and attribution changed. The size of the true usage change remains unknown.
• Comparing the affected period with the first post-fix period cannot establish adoption growth either. Restored capture can explain part of the rise, and the historical CLI excess cannot be reassigned precisely.
• Comparing two mature, equal-length post-fix periods for the same coverage-checked cohort is a better basis for a reported activity trend. If using 28-day reports, wait for full post-fix windows and the processing lag rather than treating rollout day as a clean boundary.

The defensible conclusion is that the earlier reports are not comparable enough to quantify adoption change. Establish a new baseline, keep the historical qualification beside the chart, and assess useful delivered work separately before making a productivity claim.