Three Meters and One Brake

Between 6 and 7 August, GitHub shipped four changes across its Copilot and moderation surfaces. Three of them are instruments: they count agent work, attribute it to a specific agent, and attach a cost to it. One of them is a control. The control is scoped to a population the instruments are not measuring, and that gap is the only thing in this week worth rearranging a roadmap over.

The pull request limit moved up to the organization

On 6 August, pull request limits became settable once for an entire organization instead of repository by repository, under organization settings in Moderation tools, Interaction limits. The changelog describes the setting as capping how many open pull requests a user without write access can hold at one time, and frames it as consistent policy at scale for maintainers running many repositories.

The documentation for the underlying feature is more specific than the changelog, and the specifics are the story. Pull request limits apply only to public repositories. They apply to users without write access. Draft pull requests do not count — only open, non-draft ones do. A bypass list holding up to 100 users lets a maintainer exempt a regular outside contributor without handing them collaborator permissions.

The organization-level page adds the sentence that settles it: members of the organization are not affected by any of the limit types. That page also notes that switching on an organization-wide limit removes the ability to set limits on individual repositories, so the roll-up costs you per-repository control rather than adding to it.

Put those together and the shape is clear. This is a moderation tool sitting on drive-by contribution to open repositories. Whatever else it is, the documented scope means it cannot act as a rate limiter on a coding agent working inside your private monorepo with write access.

Usage metrics learned to name the agent

On 7 August, the Copilot usage metrics API gained an optional totals_by_3rd_party_agent array carrying one entry per recognized agent app. Each entry has an agent_id, which is the stable key and the one to group on, and an agent_name, which is a display name that can change underneath you. Entries carry a user_initiated_interaction_count that counts job starts for that agent — the reference is explicit that it is a different quantity from the top-level field sharing its name. A session_count appears in aggregated enterprise and organization reports and is left out of per-user entries.

This is the shipment you can act on soonest. Agent activity that was one undifferentiated bucket now splits by vendor across the 1-day and 28-day reports, which means the question of which agent is actually doing work in your org became answerable with an API call rather than a survey.

Code review got an effort dial

Copilot code review effort levels reached general availability on 7 August. The preview names Low and Medium became Lite and Balanced, with existing configuration carried across. Lite is the default and gives fast targeted feedback on common issues. Balanced routes the pull request to a higher-reasoning model for longer analysis of complex logic, security-sensitive code, and cross-service changes. Organization owners set the default and repository administrators can override it.

The line to plan against is not in the changelog but in the concept docs: Balanced consumes more AI credits and more Actions minutes than Lite. The dial is a spend decision wearing the clothes of a quality decision.

The dashboard prices a developer in pull requests

The fourth change is the one that reframes the other three. The Copilot impact dashboard gained a potential return on investment section that compares developers using chat and completions against agent-first developers. Each comparison card shows cost per developer per month derived from actual AI credit consumption, that cost as a percentage of payroll, and pull requests per month. A salary selector lets you pick a compensation band and recalculates the cost-derived figures. GitHub labels the output directional: the costs are estimates from credit consumption and the salary band is a modeling input, not payroll data. The dashboard documentation describes the whole surface as connecting adoption cohorts to pull request throughput.

So the numerator of the business case for agent adoption is pull requests per developer per month.

The thread

Three meters and one brake, and they do not overlap. GitHub now lets you count agent work per vendor, tune how hard the reviewer thinks, and convert both into a cost per developer justified by pull request throughput. The only new volume control it shipped in the same week cannot reach a private repository and cannot reach anyone with write access — which is to say it cannot reach a single pull request that the ROI section counts.

That is a claim you can falsify cheaply, and you should: if GitHub documents pull request limits applying to private repositories, or to users with write access, the argument here collapses and the brake becomes real. Until that happens, treat the throttle as belonging to your open-source maintainers and the metrics as belonging to your platform team.

The practical consequence is that a metric treating pull requests as the output unit arrived in the same week as a cap that cannot restrain them, and building the missing governor is on you. Tooling arrives instrumented long before it arrives governed, which is one of the reasons enterprise AI stalls after the pilot. Cloudflare, reporting on agent behavior on 7 August, described 206 million client-side behavioral evaluation events across 73,438 zones in a single 24-hour window. Counting autonomous activity has become cheap and industrial. Deciding what it may not do stays local work, and this week it stayed local.

Three things to do this quarter. Pull the per-agent numbers directly rather than reading the dashboard, with gh api /orgs/{org}/copilot/metrics/reports/organization-28-day/latest and a grouping on agent_id — the organization endpoints need the View Organization Copilot Metrics permission or the read:org scope, and the usage metrics policy has to be on. Second, set Balanced on the paths where a missed defect is expensive and leave Lite everywhere else, because the difference is billed in credits and Actions minutes. Third, put the actual limit where it can bind: a merge queue, required reviewers, and a CI check on diff size are governors that apply to principals with write access, and this week did not ship you one. Teams that skip that step end up measuring throughput they cannot absorb.