September 25 update: GitHub separates human review wait from review work
GitHub has added pull-request review-stage timing to its Copilot usage-metrics API. The enterprise and organization repos-1-day reports can now return a pull_request_review_times object with median and 90th-percentile minutes for three intervals: ready for review to first human review, first to final human review, and final human review to merge. This separates the queue before anyone responds from the discussion and follow-up before the final review, then from the merge delay after that review.
October 3 update: review requests have APIs and Default means Balanced
GitHub now supports requesting Copilot code reviews through REST and GraphQL, with optional effort selection for each request. The feature is generally available on Pro, Pro+, Max, Business and Enterprise. GitHub also confirms that Default has meant Balanced since September 28, 2026; explicitly selected Lite settings were respected.
Check the effective effort before comparing review outcomes across that date. An inherited setting can change the workload without a repository owner explicitly choosing a new value. Record the request, commit and actual effort alongside findings. API acceptance, completed review and a safe merge remain separate checks. Read GitHub’s October 2 API and default-effort announcement.
These fields do not measure Copilot’s review speed. GitHub counts only pull requests with human reviews; it excludes Copilot and other bot reviews. A returned empty array means that no qualifying pull requests were observed, not that review time was zero. The new fields have no historical backfill, and pull requests that became ready before September 21, 2026, are excluded. Do not splice the new series into an older trend line as though the definition had stayed constant.
For a useful dashboard, show each stage’s median and p90 beside its qualifying pull-request count and the separate pull_requests.total_merged figure. Those denominators need not match: a merged pull request may have no qualifying human review. Segment by repository and review policy, then investigate whether the longest delay sits before first review, during iterations, or after final review. A shorter interval is not, by itself, proof of better code quality or a causal Copilot benefit.
September 23 review settings update
GitHub has expanded Copilot code review controls. A dedicated page under a user’s Copilot settings is now available on every Copilot plan, including Business and Enterprise. Users can enable automatic reviews when they create or coauthor a pull request, or move one out of draft. Separate switches cover new pushes and draft pull requests. The personal default review effort is Lite or Balanced, and a user can choose a different effort when manually requesting a review.
Enterprise administrators can also set an enterprise-wide default of Lite, Balanced, or the GitHub default for organization-owned repositories. Organizations and repositories can override that inherited choice. This is a configuration change, not evidence that every review has become more accurate: teams should compare review coverage, useful findings, false positives, and usage after changing defaults.
September 18 update: Copilot review now keeps a clearer issue ledger
GitHub has made a redesigned Copilot code-review overview generally available. The overview now separates findings into Open, Resolved since last review, and Previously missed. Each item includes severity and a link to the relevant inline comment, while the overview retains the review effort level and the pull request assessment.
The Previously missed group deserves attention. It covers issues that were already present in the change but appeared only in a later Copilot review. That is useful evidence about review variance. It also means a clean first pass should not be treated as proof that the pull request was issue-free.
Copilot now gives review comments short titles and handles resolution state with more context. If a developer replies that an issue should stay open, Copilot is meant to preserve it. Later commits can close a comment with a reason such as Won't Fix or Incorrect. Teams should sample those automated resolutions during rollout because a tidy overview can still hide a mistaken closure.
Batch acceptance also generates commit titles and optional descriptions based on the selected changes. The convenience is real, but the resulting message still needs to describe the intent of the human-approved patch. Review the diff, not the message’s fluency.
Read GitHub’s improved Copilot code-review announcement.
Update checked on September 18, 2026. Feature status and behavior come from GitHub. Governance advice is MustHave.ai analysis. Marker: copilot-review-ledger-20260918.
Update, August 29, 2026: Balanced becomes the default as retention expands
GitHub has now attached review effort to a larger September 28 policy migration. Copilot code review will default to Balanced unless an organization explicitly selects Lite. On the same date, GitHub says its unified agent and chat policy will be enabled by default for existing Business and Enterprise customers, and Copilot Chat conversations will move from 28-day retention to the life of the user’s account.
The setting is therefore no longer only a review-depth dial. It belongs in an administrative change record with repository scope, retention, user notice, and policy ownership. GitHub also announced upfront seat billing for affected card and PayPal customers and says it will not refund revoked seats for the remaining period. Read our separate Copilot billing, retention and policy checklist for the September 1, September 28 and October 1 dates.
Update, August 12, 2026: GitHub adds per-model token reporting
GitHub’s usage report can now break out input, output, cache-read, and cache-write tokens by model, alongside AI credits. Business and Enterprise administrators and individual users can view it.
| Metric | Useful question | Common misread |
|---|---|---|
| Input tokens | How much context are workflows sending? | More context means better answers |
| Output tokens | Which models generate the most material? | More output means more productivity |
| Cache read/write | Are repeated contexts being reused efficiently? | A high cache rate proves low total cost |
| AI credits | Which models consume the allowance? | Low credits mean low review burden |
This makes the article’s warning more actionable: do not turn usage into a performance grade. Join the report to pull-request cycle time, accepted changes, defects, reverts, and reviewer hours. Read GitHub’s per-model token reporting announcement.
GitHub just gave engineering leaders two controls they have been missing: a dial for how deeply Copilot reviews a pull request, and a counter for which coding agents people actually use.
The releases arrived together on August 7. GitHub Copilot review effort now has Lite and Balanced levels, while the Copilot usage metrics API can break out activity from third-party agents. One changes the work. The other makes adoption visible.
That pairing matters more than either changelog item alone. Teams can spend more inference on repositories where review depth matters, keep routine changes lighter, and then check whether Claude, Codex, or another integrated agent is earning a place in the workflow.
Lite and Balanced are policy choices, not quality grades
Lite
Fast pass for ordinary risk
Use the lighter setting for small, familiar, well-tested changes where latency and cost matter more than exhaustive analysis.
Balanced
More reasoning for consequential changes
GitHub says this level uses a higher-reasoning model. Reserve it for security boundaries, migrations, shared libraries, and changes with a larger failure radius.
An organization can set a default and a repository can override it. The selected effort level appears in the pull-request timeline or review comment, which gives reviewers a visible record of what kind of automated pass ran.
Do not read Balanced as “approved” or Lite as “careless.” GitHub’s own documentation says Copilot can miss problems and make mistakes. Human review, tests, code scanning, and repository-specific instructions still carry the decision.
The new metric counts agent activity without inventing impact
The second release adds an optional totals_by_3rd_party_agent array to aggregated organization and enterprise reports. Each recognized agent can include a stableagent_id, a display name, a count of user-initiated interactions, and a session count.
| Field | Useful for | Does not prove |
|---|---|---|
agent_id | Joining the same agent across reporting windows. | That two differently named agents are technically equivalent. |
agent_name | Human-readable dashboards and adoption reports. | A stable key; names can change. |
user_initiated_interaction_count | Seeing deliberate user engagement. | Completed work, accepted code, or quality. |
session_count | Comparing repeat use at aggregate level. | Business value or developer time saved. |
There are important caveats. GitHub says per-user entries omitsession_count, unrecognized agents are omitted, and nested interaction counts should not be added to an equivalent top-level field. A dashboard that ignores those notes can double-count activity or turn missing data into a false zero.
Usage is not value
A session count answers “was this used?” It does not answer “did this help?” A team can generate many sessions because an agent is useful. After all, it keeps failing, or because its workflow fragments one job into many starts.
Pair adoption data with delivery evidence: accepted suggestions, defects found before merge, escaped defects, review latency, rework, and the percentage of agent-authored changes that pass without human correction. GitHub has been expanding its Copilot metrics around review cycles and adoption phases, but administrators still have to define the outcome that matters.
A simple rollout: control depth, then measure the result
The four-week experiment I would run
- Classify repositories by consequence. Put small internal tools and low-risk libraries in a Lite cohort. Put authentication, payments, infrastructure, and shared APIs in Balanced.
- Freeze the policy for a full reporting window. Avoid changing defaults every few days or the comparison becomes noise.
- Track agent activity beside review outcomes. Use stable agent IDs, then join sessions and interactions to defects caught, review time, and rework.
- Change one variable. If Balanced finds more actionable defects but adds unacceptable delay, narrow it to high-risk paths instead of declaring the whole setting good or bad.
This is the same discipline we recommended when GitHub paused the Kimi K3 Copilot rollout: stage the model, preserve a fallback, and treat production behavior as evidence. It also complements our guide to how coding agents change software work, because adoption only becomes meaningful when the job and acceptance criteria are explicit.
Update: GitHub adds an ROI model and labels it directional
Update, August 9, 2026: GitHub has added a “Potential return on investment” section to the Copilot impact dashboard. It compares developers in Passive and Phase 1 cohorts with agent-first developers in Phase 2 and Phase 3.
| Card | Input | What it cannot prove |
|---|---|---|
| Cost per developer per month | Estimated from actual AI credit consumption. | Fully loaded operating cost or causal productivity. |
| Percent of payroll per month | Copilot cost divided by the salary band selected by the administrator. | Actual payroll; the salary value is a modeling input. |
| Pull requests per month | Average pull requests per developer in each adoption group. | Quality, difficulty, business value, or work that never became a pull request. |
The dashboard puts spend and output side by side. That is useful scenario planning, not proof that deeper Copilot adoption caused more pull requests. Team composition, repository type, work mix, review policy, and who chooses to use agents can all affect both adoption and outcomes.
GitHub also corrected an important counting problem. Impact-dashboard cohorts now include everyone active during the full 28-day window, not just people active on the final day. Reports ending on a weekend or holiday could previously show sharply lower cohort counts. GitHub says the change affects the dashboard, not the usage metrics API or NDJSON exports.
Use the new section to form a hypothesis: “Agent-first teams cost this much and merge this many pull requests under this salary assumption.” Then test the missing outcomes, including defects, review time, rework, incidents, developer satisfaction, and delivered customer value, before calling the difference ROI.
Read GitHub’s official Copilot ROI dashboard announcement.
Update: web Copilot exposes conversation history and token spend
Update, August 10, 2026: GitHub has expanded Copilot Chat on github.com with easier access to recent conversations, a minimized chat state that can be reopened while a response is in progress, and token-spend indicators. Clicking the token icon shows per-session and per-message quota. GitHub says the controls are generally available across all Copilot plans.
These are useful operating controls, but they measure different things. Conversation history helps a developer resume context. Minimizing the panel reduces interruption. Token indicators expose consumption. None of the three proves that an answer was correct, that the work was worth the cost, or that a long conversation should keep access to the same repository context.
| Control | What it helps | What teams still need |
|---|---|---|
| Recent conversations | Resume earlier work without rebuilding the thread. | A retention and access policy for sensitive repository context. |
| Minimized chat | Browse GitHub while Copilot finishes a response. | Clear cancellation and permission boundaries for consequential actions. |
| Token-spend indicators | See per-session and per-message quota. | Accepted changes, review time, rework, defects, and delivered value beside spend. |
The practical move is to treat token spend as an input, not an outcome. If a session consumes more quota, ask whether it also reduced review time or rework without increasing defects. Keep conversation retention and repository access in the governance review, because a resumable thread is also a resumable context boundary.
Read GitHub’s official Copilot web conversation-controls announcement.
The governance gap is now easier to see
GitHub Copilot review effort is visible on the review, but agent usage data is aggregated. That is a healthy boundary for trend reporting, but it means the metrics aren’t a forensic log. Teams still need repository audit events, pull-request history, and their own evidence trail when a specific change matters.
Agent identity also needs governance. A stable ID is useful only if administrators maintain an approved-agent register, know what repositories each agent may reach, and remove integrations that no longer have an owner. Our review of Claude Code cross-session messaging reaches the same conclusion: transport and visibility do not create ownership.
September 3 update: Copilot can count as an approval
GitHub Copilot code review now includes an approval assessment in every overview comment. That assessment is advice and does not satisfy a merge requirement. A separate approval action can count toward required approvals only when an administrator enables it. The feature is in public preview and remains off by default.
Controls exist at enterprise, organization, and repository level. Repository administrators can limit when an approval counts toward merge requirements using file-path patterns. This is separate from allowing Copilot to submit an approving review. If a new commit arrives after Copilot approves, GitHub dismisses the approval just as it would dismiss a human review, and a fresh review is required.
Keep high-risk paths out of the first rollout. Start with generated files or low-consequence repositories, require tests and code-owner rules independently, and audit false approvals as closely as useful findings. “Copilot says ready” and “Copilot approval satisfies policy” are two different states.
Read GitHub’s official approval announcement.
September 6 clarification: approval and merge credit are separate controls
In repository Settings → Copilot → Code review, GitHub documents two controls: allowing Copilot to approve pull requests, and allowing those approvals to count toward merge requirements. Enabling the first does not mean the second has been enabled. The feature remains a public preview.
For path-scoped counting, every changed file must match at least one allowed glob. GitHub supports up to 15 patterns, one per line. A blank path field covers all files. See the current configuration documentation; organization and enterprise policy can also constrain repository choices.
For example, if the only allowed pattern is docs/**, a pull request changing docs/start.md alone fits that scope. A pull request also changing src/auth.ts does not meet the all-files condition. This illustrates the documented rule, not a live configuration test.
Before rollout, test an in-scope change and a mixed-path change in a disposable repository. Confirm the effective policy rather than judging by the presence of an approval badge. Keep required tests and the human ownership of consequential changes explicit.
September 18 update: the impact dashboard now separates feature engagement
GitHub has added feature-level engagement to the Copilot impact dashboard. Administrators can now see 28-day engagement for code completion, agent edit, passive code review, active code review, the cloud coding agent, Copilot CLI, and the Copilot app.
| Dashboard rule | What it means | What it does not mean |
|---|---|---|
| Two active days in 28 | A user counts as engaged after activity on at least two days in the window. | Daily use, sustained proficiency or completed work. |
| Multiple feature counts | The same user can appear in more than one feature category. | Feature counts can be added to estimate unique users. |
| Aggregate reporting | Leaders can compare adoption patterns without a user-level leaderboard. | A forensic record of one developer’s actions or output quality. |
| Null or absent data | A metric can be unavailable when GitHub cannot calculate it. | Zero engagement. |
The two-day threshold makes the cards an adoption signal, not a productivity score. A user can engage with a feature because it works well. After all, a task requires repeated correction, or because policy makes the feature available by default. Compare the dashboard with accepted changes, review latency, rework, defects, and delivered outcomes before attributing value.
Do not sum the feature cards to estimate total users. One developer can use completion, agent edit, and CLI in the same window. Treat unavailable data as unknown rather than zero, and confirm that the organization has the permissions and usage-policy configuration GitHub requires for the report.
Read GitHub’s official feature-engagement announcement.
September 18 update: CLI customization counts have new double-counting traps
GitHub has added agentic CLI customization fields to the Copilot usage metrics API. The new totals cover skills, custom agents, MCP servers, slash commands, and plugins. They help administrators see which extension surfaces are being used, but they are adoption counters rather than task-quality or return-on-investment measures.
| Field group | What it records | Counting warning |
|---|---|---|
totals_by_skill | Usage grouped by skill | A plugin interaction can also appear as a skill interaction. |
totals_by_custom_agent | Usage grouped by custom agent | Use does not establish that the agent completed a task successfully. |
totals_by_mcp | Connection and reconnection attempts by MCP server | interaction_count includes failed attempts and is not a tool-call count. |
totals_by_slash_cmd | Usage grouped by slash command | Repeated invocation can reflect correction or confusion. |
totals_by_plugin | Usage grouped by plugin | Do not add plugin totals to skill totals. |
The MCP definition is especially easy to misread. GitHub says interaction_count records connection or reconnection attempts, including failures. A high value may indicate active use, an unstable server, or repeated authentication problems. Pair it with connection success, tool execution, task completion, and error metrics before calling the integration adopted.
Plugin and skill counts overlap because plugin interactions are also skill interactions. Adding the two totals inflates activity. Keep each array as a separate lens, report distinct users where GitHub supplies that measure, and document the time window used for every comparison.
The same rule applies to the new copilot_feature_engagement field and its totals_by_feature breakdown: a user counts after activity on at least two days in a rolling 28-day period, and one user may engage with several features. The dashboard can show where attention is moving, but accepted changes, defects, rework, and delivered outcomes still determine whether the activity was valuable.
Read GitHub’s official CLI customization metrics announcement and its feature-engagement announcement.
My verdict: spend reasoning where failure is expensive
The useful move is not to switch every repository to Balanced or crown the agent with the most sessions. Use review effort to control risk. Use agent metrics as an adoption signal. Then attach both to outcomes a team would care about even if AI disappeared tomorrow.
Start with the repositories where failure is expensive. Give them the deeper review pass. Measure whether it finds issues people act on. Watch which agents earn repeat use. Retire the ones that create motion without better software.
Read the source record.
- Read GitHub’s review effort GA announcement.
- Read the third-party agent metrics announcement.
- Check GitHub’s Copilot code review documentation, including its validation warning.
- Compare the policy with our overnight coding-agent handoff checklist.
Which repository deserves your deepest automated review, and what result would prove the extra effort was worth it?
Checked August 8, 2026. Product behavior and field definitions come from GitHub’s official changelog and documentation. GitHub does not claim that session or interaction counts measure code quality; the rollout framework above is Musthave.ai’s recommendation.
September 11 update: Copilot can auto-resolve addressed comments
GitHub Copilot code review can now mark a review comment resolved when a re-review determines that a new commit addressed it. GitHub also adds a generated commit message when a developer applies a suggested change from Copilot.
Auto-resolved is a workflow state, not proof that the change is correct. The later review decided the specific comment was addressed. Tests, code owners, branch rules, and human approval still determine whether the pull request should merge.
GitHub reports more addressed findings at lower cost
| GitHub-reported experiment result | Change | Interpretation limit |
|---|---|---|
| High-severity findings addressed | 47% higher | Vendor experiment, not an independent reproduction |
| Medium-severity findings addressed | 31% higher | Depends on finding and workflow mix |
| Low-severity findings addressed | 11% higher | Does not measure downstream defects |
| Cost | 8% lower | Experiment configuration and pricing matter |
GitHub says Copilot code review can run builds, tests, scripts, tools, and APIs behind an agent firewall. It also says Lite now uses an ensemble of agents. These changes expand what an automated review can execute, so repository owners should audit network, secret, and tool permissions in addition to quality.
Measure reopened comments before trusting auto-resolution
A useful rollout measures four outcomes: comments auto-resolved, comments reopened by a person, related tests that later fail, and defects that escape after merge. A high resolution rate with a high reopen rate signals workflow motion, not better review.
Start with repositories that have deterministic tests and clear ownership. Sample resolved high-severity comments every week, and preserve the original comment, fixing commit, re-review result, and final human decision in the audit record.
VS Code Agents now have their own usage window
GitHub’s Copilot usage metrics now include VS Code Agents. The metrics are separate from editor Agent Mode, so administrators should not merge the two labels into one series.
| VS Code Agents field | What it measures | What it does not prove |
|---|---|---|
| Daily active users | People who used VS Code Agents that day | Completed or accepted work |
session_count | Agent sessions in the window | Productivity or task difficulty |
total_user_messages | User messages sent in sessions | Quality, efficiency or business value |
| Per-user used flag | Whether a person used the feature | How much value the person received |
Join review state to outcomes, not activity.
Create one report with review effort, findings, auto-resolutions, reopened comments, test outcomes, and merge decisions. Create a separate adoption report for VS Code Agents. Join them only at an appropriate aggregate level and never treat messages or sessions as completed work.
For another organization-level rollout control, see our GitHub AI Scan pull-request APIs guide. The Copilot agentic autofix analysis covers the boundary between a generated fix and a verified remediation.
Read the September 11 sources.
Update checked on September 12, 2026. Product behavior and experiment figures are attributed to GitHub. Measurement guidance is from MustHave.ai analysis.
