Copilot Code Review in Azure Repos: Setup, Cost, Limits

Your developers have seen Copilot review pull requests on GitHub, and now they want it in Azure Repos too. Since early September they can have it: GitHub Copilot code review for Azure Repos is in public preview, and on September 30 Microsoft announced effort levels, audit events and faster comment resolution, rolling out over the following two to three weeks.

The toggles are easy. The hard part is everything around them: a bill that shows up up to 48 hours after the review, budgets that warn you but never stop anything, an organization-wide limit of five concurrent reviews, and a reviewer that never approves or blocks a PR.

I build Azure DevOps extensions for a living, so I spend a lot of time in exactly these settings pages. This post is the rollout plan I would hand an admin: what to enable in which order, how to keep cost predictable, which limits will bite you, and the one thing Copilot cannot check for you, no matter which effort level you pick.

What Copilot code review in Azure Repos actually does

When someone requests a review, Copilot reads the pull request and posts comments as a reviewer called GitHub Copilot. The comments land on specific lines, often with a suggested change you can apply in one click. You can reply to them, react, resolve or hide them, the same as with a human reviewer.

The official setup and behavior are documented on Microsoft Learn in Get started with Copilot code review for pull requests. Read it once; the rest of this post assumes you know where it lives.

What changed on September 30

The September 30 update on the Azure DevOps blog added three things:

• Effort levels. You set a default review effort at project level and can let individual repositories override it. Higher effort means a deeper review and more tokens.
• Bulk comment resolution. When you apply and commit Copilot's suggestions, you can resolve all related comments at once instead of clicking through every thread.
• Audit events. Enabling or disabling the feature, changing the compute pool, editing custom instructions, changing the default effort level and adding the automatic review branch policy now show up in the Azure DevOps audit log.

What it will not do

This is the part people skip, and it shapes everything else:

• It never approves and never requests changes. Copilot always leaves a plain comment review. It cannot block a merge and it cannot satisfy a required reviewer policy.
• It does not re-review automatically. Push new commits and the old review stays the old review. Someone has to press Request again.
• It only sees the code and its instructions. It has no idea whether the change does what the user story asked for. More on that at the end.

So treat it as an extra pair of eyes on the diff, not as a quality gate.

Enable it in the right order

Copilot code review is switched on at three levels, and each level needs the right permission.

Organization, then project, then repository

1. Organization. A Project Collection Administrator goes to Organization settings > Repos > Repositories and turns on Allow repositories in this organization to use Copilot code review. Billing goes to the Azure subscription linked to your organization, so check that link exists first.
2. Project. A Project Administrator goes to Project settings > Repos > Repositories and turns on Enable Copilot code review for this project. This is also where the default effort level lives.
3. Repository. In the same page, select a repository, open the Settings tab and turn on Copilot code review for that repository.

My advice: enable the organization switch, then one project and two or three repositories. Pick one busy repository and one quiet one, so you see both the cost of real traffic and the baseline.

Choose the compute pool

Reviews run on a compute pool you pick under Organization settings > Repos > Repositories > Compute pool. By default that is the Azure Pipelines hosted pool. You can also point it at a Managed DevOps Pool running the latest Ubuntu Server image. Self-hosted agent pools and Windows images are not supported, so if your organization only runs self-hosted agents, plan for that before you promise the feature to anyone.

Manual requests first, branch policy later

There are two ways to trigger a review:

• Manual. A developer opens the PR and selects Request next to GitHub Copilot in the Reviewers section.
• Automatic. Under Repos > Branches > Branch policies you enable Automatically request Copilot code review for a target branch.

Start manual for a week or two. You learn what a review costs on your code and whether the comments are useful before every PR to main starts spending credits.

Understand the bill before the first review

This is where most rollouts go wrong, so set it up before anyone presses Request.

How the cost is calculated

Each completed review consumes tokens, which are converted to GitHub AI credits at $0.01 per credit and charged to the linked Azure subscription. Input, output and cached tokens all count. The documentation names the main cost drivers: the effort level, the size of the pull request, your custom instructions, and changes to the underlying model.

That last one matters: the same PR can cost a different amount next quarter without you changing anything.

Find it in Cost Management

In the Azure portal, open the subscription and go to Cost Management > Cost analysis. Filter on meter category GitHub and meter subcategory GitHub Copilot for AzDO. Charges carry tags for the organization and project, so you can split the cost per team.

Budgets alert, they don't stop reviews

You can create a budget filtered on the product GitHub Copilot for AzDO, optionally per project tag, with alert thresholds. Do it. But understand the two catches:

• A budget only notifies. It does not switch the feature off or stop reviews.
• Charges appear up to 48 hours after the review. By the time an alert fires, two days of spending have already happened.

So set the threshold low, use a Forecasted alert next to an Actual one, and decide in advance who switches the feature off at project level if the forecast jumps. Write that down; a budget alert nobody owns is just an email.

Pick an effort level per repository

Project default, repository override

The default effort level is set per project. There is a checkbox to allow individual repositories to set their own default effort level, and a developer can also pick a level when they request a review manually.

One practical warning: the naming is still settling. The September 30 announcement talks about Lite and Balanced, while the Learn page lists Low, Medium and High at the time of writing. Check what your organization shows after the rollout reaches you rather than relying on screenshots in blog posts, including this one.

A practical rule of thumb

• Lower effort as the project default. Most PRs are routine: a config change, a small bug fix, a renamed variable.
• Higher effort only where depth pays off. Authentication code, payment logic, data access layers, anything security sensitive.
• Allow repository overrides, but not per-developer habits. If everybody picks the highest level on every PR because it "feels safer", your cost model is gone.

Preview limits that shape your rollout

Size limits and merge conflicts

A pull request only gets reviewed when it is active, has no merge conflicts, sits in a repository of 10 GB or less, and changes no more than 100 files. Big-bang PRs and monorepos with years of binaries in history simply won't qualify.

The concurrency cap

There are hard concurrency limits during the preview:

• 5 concurrent reviews per organization
• 2 concurrent reviews per user
• 1 review at a time per pull request, and one completed review per merge commit

Five per organization sounds fine until you add the automatic branch policy to every repository on a Monday morning. Then reviews queue and developers wait for a comment that arrives after a human already approved.

The best mitigation is not a setting, it's a habit: small pull requests. They review faster, cost less and fit under every limit. I wrote about the mechanics in how to keep pull requests small for faster, better code reviews, and it matters even more now that every PR has a price tag.

Custom instructions that reduce noise

Out of the box, an AI reviewer comments on everything it notices. Custom instructions tell it what your team actually cares about. Microsoft documents the format in Configure Copilot code review instructions.

Where instructions live and which ones win

You can define instructions at organization, project and repository level. Repository instructions take precedence over project instructions, which take precedence over organization ones. In the repository, the file is .azuredevops/copilot-instructions.md (or .github/copilot-instructions.md), and you can add path-scoped files in an instructions folder with an applyTo pattern:

1---
2applyTo: "**/*.cs"
3---
4
5## C# review focus
6
7- Flag async methods that block with .Result or .Wait().
8- Flag new SQL built by string concatenation.
9- Do not comment on formatting; the build enforces it.
Copy

The last line is the most valuable kind of instruction. Tell Copilot what not to comment on, especially anything your linters and pipeline already catch. Fewer, sharper comments are the difference between a reviewer people read and one they mute.

Instructions are read from the target branch

Copilot reads instructions from the target branch of the pull request. A PR that changes the instructions file does not affect its own review. Merge instruction changes first, then judge the effect on the next PR.

Governance: audit events and Definition of Done

Who watches the audit log

With the new audit events you can see who enabled the feature where, who changed the compute pool, who edited the instructions and who added the branch policy. Point whoever reviews your Azure DevOps audit log at these events, especially custom instruction changes: an instruction like "ignore security findings in this folder" is a quiet way to switch off part of your review.

Copilot checks the code, not the intent

Here is the gap no setting closes. Copilot reviews the diff against your coding standards. It does not know what the user story asked for, which acceptance criteria apply, or whether this is even the right change. A clean review of the wrong feature is still the wrong feature.

That check belongs on the work item, before and after the code:

• Before: the story is ready, with clear acceptance criteria, before anyone (human or AI agent) starts coding. I made that argument in detail in guard AI development at the work item, not the PR.
• After: the Definition of Done includes an explicit item like "Copilot review findings triaged: fixed, or dismissed with a reason", next to "acceptance criteria verified by a human".

Because Copilot never blocks a merge, the only way to make "we looked at the AI findings" mean something is to make it part of Done. In Make "Done" mean done in Azure DevOps Boards I show how to turn a Definition of Done into a checklist that blocks the state transition until every item is ticked. That is exactly what my free Checklist Extension for Azure DevOps does.

Conclusion

Copilot code review in Azure Repos is useful, and for teams that are staying on Azure Repos it closes a gap with GitHub that has been open for a long time. Roll it out like any other paid service:

• Enable it organization, project, repository, starting with a few repositories.
• Set up the budget and forecast alerts first, and remember they don't stop spending and lag up to 48 hours.
• Use low effort by default and higher effort only where depth pays off.
• Keep PRs small to stay under the size and concurrency limits.
• Write custom instructions that say what to ignore, not only what to check.
• Watch the audit log, and put "Copilot findings triaged" in your Definition of Done.

That last step is where the review becomes accountable. If you want your Definition of Done to actually block a work item from closing until those items are checked, install the free Checklist Extension from the Visual Studio Marketplace and add a DoD template to your user stories in a few minutes. You can read more about how it works on the Checklist Extension product page.

Frequently asked questions