The new counters are scoped better than the average dashboard.
GitHub’s September 11 changelog adds generally available Copilot usage fields for the dedicated VS Code Agents window. Aggregate reports can include daily active window users plus session and user-message totals; user-level reports can include whether a person used the window and their session/message totals. The fields cover 1-day and 28-day reports.[1]
The most important line is the boundary: GitHub says these fields cover the dedicated Agents window only. They remain separate from editor-window Agent Mode and generic rollups. Missing values can also be absent or null. That is good instrumentation hygiene. A named surface and explicit missingness beat a mystery “AI usage” number.
A counter becomes dangerous when its label is wider than its evidence.
The traffic is about to get heavier.
VS Code 1.137 makes the Agents window a more persistent operating surface. Its release notes describe scheduled automations, quick chats that can become workspace sessions without losing their current request or history, agent messages queued behind busy chats, and an agent host that can expose the same session across multiple VS Code windows.[2]
Those are product capabilities, not proof of benefit or harm. But they change the shape of measurement. A person can trigger recurring work, maintain longer sessions, and coordinate parallel chats. Raw sessions and messages may rise because the surface can now sustain more traffic—not because the work became more useful.
Even a resolved comment is not automatically an outcome.
Another September 11 GitHub update says Copilot code review can automatically resolve its own comments when a later commit addresses the feedback. GitHub also says the reviewer now has broader shell tooling behind its agent firewall, and Lite reviews use an ensemble of agents.[3]
GitHub reports experiment results for that review change: more addressed comments at high, medium, and low severity, plus lower review cost. Those are vendor-reported product measurements, not a general guarantee for every repository. More importantly, “comment addressed” is closer to work than “message sent,” but it still is not the same as fewer escaped defects, less rollback pain, or easier maintenance six months later.
Build a four-gear measurement stack.
- Attendance. Who used the named surface? Keep the denominator, reporting window, role, and missing-data rule attached.
- Traffic. How many sessions, messages, tool calls, review comments, or automation runs moved through it? Treat volume as workload shape, not value.
- Flow. What accepted change, review-cycle reduction, lead-time shift, or completed task moved through the delivery system? Compare like work with a baseline.
- Outcome. What happened to escaped defects, rework, rollback frequency, incident recovery, maintainability, and developer understanding?
No single metric gets custody of the story. Adoption without flow may mean curiosity, friction, or training. Flow without outcomes may be faster production of repair work. Outcomes without a baseline may be weather. The measurement contract needs all the labels the dashboard wants to hide.
Refuse surveillance cosplay.
The presence of user-level fields does not make a leaderboard intelligent. GitHub documents access controls around these reports; your organization still owns the decision about why it measures individuals, who can see the data, and what decisions the data may influence.[1]
Default to aggregate team learning. If a metric can affect performance evaluation, compensation, or staffing, document that purpose before collection, involve the people being measured, and prohibit proxy ranking from activity volume. A developer who sends fewer messages because they frame a task well should not look “less engaged” than someone wrestling the agent for forty turns.