If your team uses more than one coding agent, a single agent usage number is not enough. It cannot tell you whether a rollout is reaching developers, whether two tools are serving the same users, or whether a new agent is actually replacing an older one. GitHub's August 7, 2026 update adds that missing breakdown to the Copilot usage metrics API. The GitHub changelog entry describes a new optional array called totals_by_3rd_party_agent in the daily and 28-day reports.
What changed
The new array contains one entry for each recognized agent app. Each entry includes:
- agent_name: the display name shown in the report.
- agent_id: the stable identifier to use when joining data between reporting periods.
- user_initiated_interaction_count: the number of user-started agent app jobs.
- session_count: the number of sessions in aggregated enterprise and organization reports.
The user-level entries do not include session_count. Reports also omit the array entirely when there is no recognized third-party agent activity for that period.
Why agent_id matters more than agent_name
Display names are for people. They can change, so do not use agent_name as the primary key in a warehouse or dashboard. Store both fields, but group and join on agent_id. Keep the name as the latest label so a report remains readable after a rename.
{
"agent_name": "Example Agent",
"agent_id": "agent-123",
"user_initiated_interaction_count": 42,
"session_count": 18
}Pull the report from the API
The Copilot usage metrics API documentation provides enterprise and organization report endpoints. For a current 28-day organization report, request the report metadata first:
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $GITHUB_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/orgs/ORG/copilot/metrics/reports/organization-28-day/latest"The response contains signed download links and the report date range. Download the NDJSON file from those links, then parse each record. The API is not a live counter, so build your reporting job around the report's available date rather than assuming today's data is complete.
A simple aggregation pattern
When you load the report into a warehouse, keep the report day, scope, agent ID, agent name, and each metric as separate columns. A practical table might look like this:
create table copilot_agent_daily (
report_day date not null,
scope text not null,
agent_id text not null,
agent_name text not null,
interaction_count integer not null,
session_count integer,
primary key (report_day, scope, agent_id)
);Use an upsert keyed by report_day, report scope, and agent_id. That makes reruns safe and preserves the ability to compare the same agent across report windows.
Do not add the two interaction counts together
The new nested user_initiated_interaction_count counts agent app job starts. The top-level field with the same name represents explicit prompts from other supported telemetry. GitHub says they are distinct. Do not sum them or present the result as one measure of all prompts.
What the data can and cannot tell you
- You can compare recognized agent apps by users, job starts, and sessions where the report includes session_count.
- You can measure whether a rollout changes adoption across reporting periods by joining on agent_id.
- You cannot assume an unrecognized agent was unused. GitHub says unidentified agent activity is omitted.
- You should not compare a user-level session total with an organization-level session total because the user-level field is not present.
Permissions and policy
The Copilot usage metrics reference says the metrics policy must be enabled. Access depends on the report scope: enterprise owners and billing managers, organization owners, and custom roles with the required Copilot metrics permission can retrieve the data. For organization reports, use a token with the permissions documented for that endpoint, and keep the token in your reporting system's secret store.
A useful dashboard design
Start with three views instead of one giant adoption score:
- Agent reach: distinct users or active users per agent ID over time.
- Agent activity: job starts and sessions, with scope clearly labeled.
- Agent mix: the share of recognized activity by agent ID, plus a visible unknown or omitted-data note.
Keep report dates and freshness next to every chart. A 28-day report is useful for rollout trends, while a one-day report is better for checking a specific launch or policy change. Neither should be presented as a real-time usage feed.
The short implementation checklist
- Enable the Copilot usage metrics policy at the required scope.
- Grant the reporting job only the read permission needed for its endpoint.
- Fetch daily or 28-day report metadata, then download the signed NDJSON files.
- Flatten totals_by_3rd_party_agent and key records by report date, scope, and agent_id.
- Label unknown agents and missing optional arrays instead of turning them into zeros.
The useful shift here is not another adoption score. It is the ability to see which agent apps are actually being used and how that changes over time. Store the stable ID, keep the report scope visible, and treat missing or non-comparable fields as data-quality conditions rather than silent zeros.