On September 11, 2026, GitHub made VS Code Agents activity generally available in Copilot usage metrics reports for enterprises and organizations, in both 1-day and 28-day periods.

New optional GA fields: daily_active_vscode_agent_users, totals_by_vscode_agent (session_count and total_user_messages), and a per-user used_vscode_agent flag. Metrics cover only the dedicated VS Code Agents window and remain separate from editor-window Agent Mode and generic rollups, with backward-compatible absent-field behavior.

Enterprises can finally attribute Copilot adoption to a specific agent surface instead of blended usage. Don't sum the new columns with editor Agent Mode totals — they're deliberately fenced — and strict schema validators on metrics pipelines will need to tolerate absent optional fields.

GitHub Copilot Usage Metrics Now Track VS Code Agents Activity

What shipped

GitHub added VS Code Agents to Copilot usage metrics on September 11 — generally available immediately, no preview flag. Enterprise and organization dashboards that previously lumped the standalone VS Code Agents window into generic rollups can now see it as its own line item.

What changed

Three new GA field families, all optional, across 1-day and 28-day aggregate reports and their per-user counterparts:

daily_active_vscode_agent_users — unique users in the VS Code Agents window per day
totals_by_vscode_agent — aggregate session_count and total_user_messages
used_vscode_agent — per-user boolean flag

The critical detail is in the notes: these metrics cover only the dedicated VS Code Agents window, deliberately excluded from editor-window Agent Mode and generic usage rollups. GitHub now meter-fences three agent surfaces — editor Agent Mode, Copilot CLI, and the VS Code Agents window — into separate columns. Backward-compatible missing-data behavior means the fields simply stay absent on older reports rather than returning zeros.

Why a builder cares

This is the first time enterprises can attribute Copilot spend and engagement to a specific agent surface instead of one blended "AI usage" number. Two traps follow. First, anyone with an existing cost-per-seat or adoption dashboard built on the metrics API should not sum across surfaces — the new columns are intentionally disjoint from editor Agent Mode totals, so naive aggregation double-counts nothing but the old dashboards now silently under-report agent work. Second, if your team is deciding where agents should live (IDE window vs CLI vs headless), the 1-day and 28-day reports finally give you before/after data to settle it. Optional fields that stay absent rather than zeroing out also means any strict schema validation in your reporting pipeline will start failing until you handle absence.

What shipped

What changed

Why a builder cares

Related