Skip to content
NewsProduct launch

GitHub Copilot ships four updates: code review effort levels go GA, CLI gets concurrent sessions, ROI dashboard, and per-agent usage metrics

· by Pondero Newsdesk

The short version

GitHub promoted code review effort levels to general availability on August 7, 2026, renamed the tiers from Low/Medium to Lite/Balanced, and shipped three other updates covering CLI session management, impact dashboard ROI calculations, and per-agent activity in the usage metrics API.

GitHub Copilot ships four updates: code review effort levels go GA, CLI gets concurrent sessions, ROI dashboard, and per-agent usage metrics

GitHub Copilot's code review effort levels exited public preview on August 7, 2026 with a rename that signals a more substantive difference between the two tiers: Lite targets routine changes, and Balanced routes pull requests through a higher-reasoning model for deeper analysis. Three companion updates landed the same day: a Sessions sidebar in the CLI, an ROI section in the impact dashboard, and per-agent-app breakdowns in the usage metrics API.

What

The Lite and Balanced effort levels replace the preview-era names Low and Medium, per the GitHub Changelog. Existing configurations carry forward automatically under the new names. Developers choose an effort level when requesting a review, and the choice applies only to that review. Organization admins can set an org-wide default that repositories inherit; individual repos or reviewers can override it per request. The feature is available on Copilot Pro, Pro+, Max, Business, and Enterprise plans. Pull request timelines and the overview comment now display which effort level ran, giving teams an audit trail of review depth across repositories.

The CLI update, covered in the August 3 weekly release, adds a Sessions sidebar that lets developers manage multiple concurrent sessions from inside the terminal. Keyboard shortcuts open a new session (n), close the current one (x), and move between sessions. An experimental /worktree command spins up an isolated worktree for a separate conversation without disrupting the active task. A /rewind command restores conversation state and files that Copilot changed, per GitHub's changelog, even when no Git history is available.

The impact dashboard gained a "Potential return on investment" section that compares passive Copilot users against agent-first developers across three metrics: average monthly cost per developer (derived from actual AI credit consumption), that cost expressed as a share of developer compensation, and pull requests per developer per month. A salary selector lets admins adjust the compensation band and see the cost-to-output ratio recalculate, per the changelog.

The usage metrics API now includes a totals_by_3rd_party_agent array that breaks out activity by individual agent app, such as Claude or Codex, per GitHub's announcement. Each entry carries the agent name, a stable agent ID for cross-period joins, user-initiated interaction counts, and session counts. The data appears in enterprise, organization, enterprise-user, and organization-user reports on 1-day and 28-day intervals. Existing fields are unchanged; the new array is additive and optional.

Why it matters

The effort-level GA removes the main reason an enterprise admin might delay enabling Copilot code review at scale. Preview features carry roadmap risk; GA features do not. Organizations that piloted Lite on documentation PRs and Balanced on security-sensitive branches during the preview period can now treat that configuration as stable policy.

The ROI section answers a question that procurement teams ask in every renewal cycle: what is the cost per developer at each adoption phase, and does higher adoption actually produce more output? GitHub frames the answer using pull request throughput rather than survey-based time-savings estimates. That methodology is more concrete, though it relies on GitHub's own definition of adoption phase and does not account for PR quality or size variance.

The per-agent metrics matter for any organization running more than one third-party agent in GitHub workflows. Until this update, all agent activity aggregated into a single bucket. Teams can now see which agents are actually being used and by how many developers, which grounds rollout decisions in observed behavior.

What to watch next

GitHub has not announced pricing changes accompanying the effort-level GA. If Balanced's higher-reasoning model carries additional per-review cost, that information has not been published. The ROI dashboard methodology will also face scrutiny from organizations whose PR volume patterns do not match GitHub's passive-versus-agent-first segmentation.

Sources