Six GitHub updates in three days, from August 6th to 8th, paint a picture that goes beyond the usual product changelog. GitHub Copilot adds a dashboard with an ROI section, code review effort levels become generally available, and the usage metrics API now separates activity per individual agent (Claude, Codex, others).

Why this matters to you. If you’ve deployed agents to production, you know the problem isn’t whether they work anymore. The problem is: which agent is consuming what, how much does it cost, and where’s the return. Until yesterday, GitHub’s metrics threw everything into one bucket: you couldn’t distinguish the work of Copilot’s coding agent from what was done through Claude or Codex. Now you can. For anyone who needs to justify a spend or decide which agent to renew, the difference between an aggregated total and per-agent data is the difference between a guess and a decision.

The other updates follow the same thread. Enterprise-level MCP allowlists control which servers an agent can call, and effort levels in code review classify how much work a PR requires. Governance shifts from “allow or deny” to “measure and decide.”

If you want to try it, the metrics endpoint is documented in the Copilot usage metrics API. The novelty is the totals_by_3rd_party_agent field, which reports an entry for each recognized agent.

In detail

Until this week, if an organization used multiple agents on GitHub, consumption metrics were a single number. The API returned an aggregate total for “agent activity,” without distinguishing who did what. For a team that just rolled out Claude alongside Codex, answering the question “which one do they use more” required external tools or manual estimates.

The new totals_by_3rd_party_agent field changes that. Each recognized agent gets its own entry: name, stable identifier, number of jobs initiated by the user, number of sessions. The data is available in reports at the enterprise level, organization level, and per individual user, across 1-day and 28-day windows.

One detail that matters for data people: the user_initiated_interaction_count field inside the agents array counts job starts, and is different from the same-named field at the higher level that counts explicit prompts. GitHub explicitly states this in the notes: don’t sum them, don’t mix them up. This is the kind of distinction anyone building dashboards needs to know before presenting numbers to budget decision-makers.

The ROI dashboard and effort levels. The impact dashboard adds a dedicated ROI section, and code review effort levels move from preview to general availability. Effort levels classify PRs by complexity: a distinction that matters when you have dozens of reviews a day and need to choose where to focus human attention.

MCP allowlists. Enterprise managed settings now include allowedMcpServers and deniedMcpServers. Security teams can block or permit specific MCP servers at a centralized level, rather than relying on the discipline of individual developers. It’s the same pattern we saw this week on Claude Code, where operational controls shifted from chat to gateway.

What remains unclear. GitHub doesn’t say how wide the adoption of agent apps is, nor does it provide numbers on real usage. Effort levels are GA but the ROI dashboard is new: the calculation criteria aren’t documented in the changelog. For anyone wanting to take these numbers to a budget decision, it’s worth verifying what’s behind “ROI” before citing it in a presentation.

This is the thread running through the week: agent governance stops being a policy document and becomes infrastructure. We saw it on Bedrock AgentCore with temporal rules and rate limiting, and on Claude Code with spend-limit and workspace trust. GitHub does it from the platform side: the place where agents run becomes the place where they’re measured.