Choosing a model in GitHub Copilot does not answer every question that arises inside Visual Studio. How deeply Copilot should reason, how a team should share specialized behavior, and when code should be reviewed are separate decisions.

The August 2026 update brings controls for all three into the IDE: adjustable thinking effort, organization-level custom agents, and Git agent reviews for changes and commits. It also makes models and plan usage easier to inspect.

The practical question is not whether to enable everything. It is which scope each control belongs to: one task, a whole organization, or one set of code changes.

Visual Studio 18.9 expands Copilot control from tasks to teams and changes

The Visual Studio 2026 release notes place thinking effort, Git agent review, and organization-level custom agents in August Update 18.9.0, released on August 11, 2026. Versions 18.9.1 and 18.9.2 followed on August 18 and August 25.

The August 25 Visual Studio Blog post also presents these features as a Stable Channel update. This is more than the addition of another model: Visual Studio now exposes controls at several points in the Copilot workflow.

Control	Primary scope	Decision it supports
Model and thinking effort	One task	Balance response speed, reasoning depth, and token use
Usage and model management	A person's plan and session	Inspect usage, capabilities, context size, and cost information
Organization-level custom agents	An organization across repositories	Share specialized roles and working conventions
Git agent review	Uncommitted changes or commits	Get feedback before opening a pull request

This separation matters because Copilot is no longer controlled along a single “more or less AI” axis. The smallest and easiest place to start is the individual task.

Match thinking effort to task difficulty, not just the model name

Visual Studio already supported model switching. GitHub Docs lists Visual Studio 2022 version 17.12 or later as the prerequisite for multi-model Copilot Chat. Visual Studio 18.9 adds a second choice for supported models: how much reasoning the selected model should apply.

The available effort levels are Low, Medium, and High. Their documented roles translate into a simple task-based choice:

• Low: straightforward questions and code suggestions where speed and lower token use matter most
• Medium: everyday implementation work that needs a balance of reasoning and response speed
• High: difficult algorithms, architecture decisions, and hard-to-debug problems that benefit from deeper reasoning

High is not a correctness guarantee. It trades more tokens for deeper reasoning, so it is best reserved for work that needs it, with the result still verified independently.

The redesigned model picker can pin favorites, collapse rarely used models, and open a management view with capabilities, context-window sizes, and cost information. The prompt's context indicator also links to full plan usage, making it easier to see the resource side of an effort choice without leaving the workflow.

The update is offered across Copilot plans, but the selectable models and controls are not identical for everyone. The official Copilot plan comparison says that Copilot Free and Student use automatic model selection, and model access can also depend on the client and organization policy. The choices visible in the current Visual Studio environment are therefore the reliable boundary.

Organization-level custom agents share specialized roles across repositories

Thinking effort is a per-task control. Organization-level custom agents operate at the reuse layer: GitHub organization and enterprise owners can publish specialized agents, and Visual Studio detects them for eligible repositories. The agent picker shows both the description and the organization that supplied each agent.

GitHub's organization setup documentation stores organization-level definitions in the /agents directory of the organization's .github or .github-private repository. With .github-private, members can use the agents even when they do not have direct access to that definition repository.

Consider a team that follows the same .NET migration process in several repositories. The checks to perform, expected output, and references to consult could be gathered into one specialized agent rather than repeated in a long prompt in every repository. This does not automatically enforce the process, but it gives the team one reusable place to maintain the role.

The feature requires a GitHub organization and is documented as a public preview. A sensible rollout is to test one narrow role first, verify how its definition appears in Visual Studio, and keep its changes reviewable before making it broadly available.

Put Git agent review into the short loop before a pull request

The Git agent can review uncommitted changes and commits before a pull request exists. For uncommitted work, a review can start from Git Changes. For a commit, it can start by attaching the commit in Copilot Chat or selecting it from Git Repository history. Findings appear inline, with a navigable list that leads back to each location.

The conversation can continue after the initial review, which makes it possible to ask why a finding matters or discuss a fix. The Visual Studio 18.9 documentation says these reviews work with both GitHub and Azure DevOps repositories, while commit-review comments remain local to the Visual Studio session. This places the feature before, not inside, the pull-request approval process.

A practical sequence is:

1. Give the Git agent the uncommitted changes or target commit and collect potential issues in the diff.
2. Check the reasoning behind each finding and apply only the changes that are warranted.
3. Run tests and static analysis, then open the pull request for human review.

Copilot is not guaranteed to find every problem and can make mistakes. GitHub's code review documentation requires careful validation of its feedback and a supplemental human review. The local review fits best as a self-check before existing tests and review gates, not as a new approval gate of its own.

Adopt personal controls first, then add shared agents and review

The answer to the opening question is to choose by scope, not by feature name. Start with Low, Medium, and High effort for personal tasks, then use the model and usage views to understand the resource tradeoff. This part is easy to test without waiting for organization-wide setup.

When a specialized role is repeated across repositories, trial one organization-level custom agent. Because it is a public-preview feature, decide who owns the definition and how updates will be reviewed before expanding it.

Finally, add Git agent review as a pre-PR self-check. With those boundaries, Copilot becomes a tool that connects task-level reasoning, team-level reuse, and change-level feedback—while tests and human review remain responsible for the final decision. That is the practical significance of the August update.

Source

• Title: GitHub Copilot in Visual Studio — August update
• URL: https://github.blog/changelog/2026-08-28-github-copilot-in-visual-studio-august-update-2