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 revoked seats will not be refunded 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. The view is available to Business and Enterprise administrators and to individual users.
| 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 the repositories where review depth is valuable, keep routine changes lighter, and then check whether Claude, Codex, or another integrated agent is actually 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 stable agent_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 edges. GitHub says per-user entries omit session_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, because 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 the adoption phase and the outcome.
GitHub also corrected an important counting problem. Impact-dashboard cohorts now include everyone active during the full 28-day window instead of only 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—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, yet it means the metrics are not 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.
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 as a risk control. 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.
