Azure Repos Copilot Code Review Adds Lite and Balanced Effort Levels, Audit Logs and Faster Comment Resolution

Dan Hellem, a product manager for Azure DevOps, announced the changes on the Azure DevOps Blog on September 30, 2026. According to his post, the features are rolling out now and should reach all customers within two to three weeks. That puts full availability somewhere in October, but it's an estimate, not a promised date.

Background: the preview so far​

Microsoft opened the feature on August 26. In that announcement, Microsoft said it was announcing the public preview of GitHub Copilot Code Review for Azure Repos, making the feature available to all Azure DevOps customers using the service. There's no longer a need to sign up for early access.

The launch release notes listed the main capabilities: enable Copilot Code Review at the organization, project, or individual repository level, run reviews using a configured Managed DevOps Pool instead of Microsoft-hosted agents, and use branch policies to automatically review new pull requests, including draft pull requests. The same notes listed review failure logs and configurable Lite and Balanced review levels as coming soon.

One of those promised items has now arrived. Keep the label in mind: this is still a preview, not general availability. Microsoft Learn's documentation calls the feature a limited preview and warns that functionality may change or be removed without notice. It also states that preview features have no SLA and only limited support.

Summary: This update adds features to an existing preview. It does not make the service production-grade.

Effort levels: choosing Lite or Balanced​

Effort levels are the headline feature. Microsoft says the setting controls how much time Copilot spends on a pull request. That gives teams control over review depth and can cut costs when a detailed review isn't needed.

Defaults can be set to Lite or Balanced at two levels:

• Project level: project admins set a default for every repository in the project.
• Repository level: a single repository can set its own default when it needs one.

Microsoft's documentation fills in the governance details. A project administrator decides whether repository administrators may override the project default at all. If overrides are turned off, the repository's effort setting becomes read-only and shows the inherited project value. Users can also pick a different effort level for a single review without changing the stored default. According to the docs, Azure DevOps records who requested each review and at what effort level in the pull request activity.

The documented paths are:

1. Project default: Project settings > Repos > Repositories, then under GitHub Copilot code review choose a Default effort level. Tick Allow individual repositories to set their own default effort level if you want to allow overrides.
2. Repository default (only when overrides are allowed): Project settings > Repos > Repositories, pick the repository, open the Settings tab, and choose a Default effort level.
3. One-off review: in a pull request's Reviewers section, open the dropdown next to Request beside GitHub Copilot and pick an effort level. Selecting Request by itself uses the repository default.

Where the Lite and Balanced names come from​

The names come from GitHub. According to GitHub's changelog, Lite and Balanced effort levels for GitHub Copilot code review are now generally available. That changelog is dated August 7, 2026. GitHub also noted that the Low and Medium effort levels introduced during public preview are now named Lite and Balanced. Microsoft's August launch post had said the Azure DevOps levels would be added to align with GitHub's recent announcement.

GitHub's descriptions are the clearest guide to the difference. Choose Lite for feedback on straightforward changes. Choose Balanced when a change warrants deeper analysis from a higher-reasoning model. A Microsoft Tech Community guide on the Azure Repos version describes Balanced the same way: it routes the pull request to a higher-reasoning model for longer analysis of complex logic, security-sensitive code, and subtle interactions. It generally consumes more tokens.

The two implementations differ in one notable way. On GitHub, you can set an organization-wide default that repositories inherit while retaining control over individual reviews. In the Azure DevOps announcement, defaults are set at the project and repository levels only. Organization-level defaults aren't mentioned.

The cost tradeoff​

Microsoft's docs say plainly that higher effort generally uses more tokens and can raise the cost of a review. The cost also depends on pull request size, custom instructions and model changes, so no effort level has a fixed price. An independent write-up at Developers Digest warned that for teams that auto-review every pull request, switching the default from Lite to Balanced can multiply spend on routine changes without proportionally better feedback. That's analysis, not a measurement from Microsoft, but it's a reasonable caution.

Summary: Effort levels mainly let you control cost. A sensible setup is to pick one project default, allow overrides only where teams need them, and use Balanced for the pull requests that justify it.

Resolving comments after applying suggestions​

The second change removes some tedious clicking. Before, you applied Copilot's suggested changes, committed them, then went back and resolved each related comment one at a time. Now, when you apply and commit suggestions from a Copilot review, you can resolve all the related comments in the same step. Microsoft says this speeds up working through a pull request and makes it clearer what still needs attention.

Microsoft's post doesn't include step-by-step UI instructions, and it doesn't say whether every kind of suggestion is covered. Expect to see the option during the commit flow, but don't count on it for every edge case until it reaches your organization.

It helps to be clear about what resolving comments does and doesn't do. According to Microsoft's documentation, Copilot always leaves a "Comment" review. It never approves a pull request or requests changes, so its review doesn't satisfy required-reviewer policies and doesn't block a merge. The docs also note that Copilot doesn't read replies or follow up. Bulk resolution tidies the comment thread. It doesn't approve anything.

Summary: This is a quality-of-life fix. Human reviewers still make the decisions.

New audit log events​

The third change is aimed at administrators. Copilot Code Review usage is charged to the subscription for each review, so admins need to know where the feature is turned on and when its settings change. Microsoft has added new Azure DevOps audit log events for:

• Copilot Code Review being enabled or disabled at the organization, project, or repository level
• Changes to the configured agent pool
• Changes to custom instructions at the organization or project level
• Changes to the default effort level at the project or repository level
• Branch policies added for automatic code reviews at the project or repository level

The events appear on the Auditing page in Azure DevOps. (Microsoft's post ends the list with a stray "List item" placeholder. It isn't a sixth event category.)

The post doesn't give event names, retention periods or export behavior. It's also worded only as "branch policies added," so don't assume removals of those policies are logged until you've checked your own logs.

Audit logs and cost reports do different jobs, and you'll want both. The audit trail shows who changed what. The bill shows up elsewhere. According to Microsoft's docs, charges go to the Azure subscription linked to your Azure DevOps organization and appear as a separate meter in Azure Cost Management. Charges can take up to 48 hours after a review completes to appear. To track them, filter on meter category GitHub and subcategory GitHub Copilot for AzDO, and group by the organization and project tags. The docs say each review's tokens convert into GitHub AI credits at one credit per US$0.01.

Here's a common scenario. Someone quietly adds an automatic-review branch policy to a busy repository, and a few days later the Cost Management bill jumps. Before, you'd have to piece together what happened. Now the audit log should record the policy being added.

Summary: The new events cover the configuration changes that drive spending. Pair them with Cost Management budgets.

Rollout checklist for Azure DevOps admins​

Based on Microsoft's documentation, a careful rollout looks like this:

1. Check prerequisites. You need an Azure Repos Git repository (TFVC isn't supported) and an Azure subscription linked to the organization.
2. Enable in order. A Project Collection Administrator turns the feature on at the organization level first. Then project and repository scopes can follow.
3. Pilot small. Microsoft suggests enabling it for one or two repositories, comparing effort levels and watching daily usage before a wider rollout.
4. Set a project effort default and decide whether repositories can override it.
5. Watch the Auditing page once the new events reach your organization.
6. Set up budget alerts in Cost Management. The docs note that budgets only send notifications. They don't stop reviews.

Also keep the preview limits in mind. The current documentation says reviews require an active pull request with no merge conflicts, a repository of 10 GB or less, and no more than 100 changed files or 100 changes. Concurrency is capped at one review per pull request, five per organization and two per user. Microsoft says these limits can change during the preview.

Assessment​

This update brings no big new feature, and that's to its credit. Effort levels give teams a direct way to control cost. The commit-and-resolve change fixes a real annoyance. The audit events deal with the obvious problem of an AI reviewer that bills per review: without an audit trail, nobody could easily tell who turned it on.

There are caveats. The feature is still in preview, with limits on pull request size and concurrency that larger codebases will hit. Azure DevOps lags GitHub on effort levels by nearly two months and doesn't offer the organization-wide default GitHub has. Microsoft says more features are coming "over the next couple of months" but hasn't named them. Custom instructions are also capped at 4,000 characters; Hellem said in a comment on the launch post that this matches GitHub's limit.

For organizations that have stayed on Azure DevOps instead of moving to GitHub, the gap is closing steadily. Just keep a human reviewer on every pull request, and set budget alerts before you turn on automatic reviews.