Visual Studio 2026 18.9: A Practical Guide to Copilot Thinking Effort, Git Review, and Token Control
> A verification-first guide to Visual Studio 2026 18.9: Copilot thinking effort, Git review, organization custom agents, model controls, usage visibility, and the 18.9.1 fixes.
🎧 Listen — ~12 min
Ready · Visual Studio 2026 18.9: A Pract
Visual Studio 2026 18.9: A Practical Guide to Copilot Thinking Effort, Git Review, and Token Control
Visual Studio 2026 version 18.9, released on August 11, 2026, gives GitHub Copilot users a new way to choose how much reasoning effort a supported model should use: Low, Medium, or High. Microsoft followed it with version 18.9.1 on August 18, which fixes a scroll problem in the Copilot Command preview dialog and a Test Agent issue.
The important developer takeaway is not that a slider magically makes code correct. It is that Visual Studio now exposes a useful control surface for matching model effort to task risk, while adding local Git review, organization-level custom agents, model cost visibility, worktrees, and richer usage reporting. Used together, these features support a verification-first workflow: spend fewer tokens on routine edits, reserve deeper reasoning for risky changes, and review the resulting diff before it reaches a pull request.
Key takeaways
- Visual Studio 18.9 supports Low, Medium, and High thinking effort for compatible Copilot models.
- Low is appropriate for quick suggestions and straightforward questions; High is better suited to difficult debugging, architecture, and security-sensitive review.
- Thinking effort is a manual control, not an automatic task classifier. Developers still have to select the level.
- The new Git agent can review uncommitted changes and commits, with comments shown inline in the editor.
- Organization-level custom agents help teams distribute shared workflows across repositories, but require a GitHub organization.
- Visual Studio exposes model capabilities, context-window sizes, cost information, and plan usage so teams can reason about quality and spend together.
- Version 18.9.1 is the safer baseline because it includes the post-release fixes documented by Microsoft.
What changed in Visual Studio 18.9
Microsoft’s official Visual Studio 2026 release notes describe the August update as a deeper integration of AI into the IDE. For Copilot users, the release is best understood as several connected improvements rather than one isolated reasoning dial.
| Capability | What it does | Best first use | Main trade-off |
|---|---|---|---|
| Thinking effort | Chooses Low, Medium, or High effort for supported models | Match effort to task complexity | Higher effort can consume more tokens and take longer |
| Git agent | Reviews uncommitted changes or commits and adds inline comments | Pre-PR verification | Findings still require human judgment and tests |
| Organization custom agents | Shares custom agents across repositories | Standardize team workflows | Requires organization administration and review of agent definitions |
| Model management | Shows model details, capabilities, context size, and cost information | Choose a model deliberately | Availability varies by plan and model |
| Usage visibility | Opens plan usage from the context window or badge menu | Monitor limits and consumption | Usage reporting does not replace project-level budgets |
| Worktrees and submodules | Manages more complex Git layouts inside the IDE | Parallel branches and multi-repository work | More repository state means more context to audit |
The release notes state that Low uses fewer tokens, Medium balances speed and depth, and High uses more effort for complex problems. They also make an important limitation clear: only some Copilot models support adjustable thinking levels. The model picker and management view are therefore the source of truth for what is available in a particular installation and plan.
How the thinking-effort control works
Open Copilot Chat in Visual Studio 18.9, open the model picker, and select a supported model. The effort control is available from the picker or the expanded Model management view. The names are simple, but the operational policy behind them matters.
Visual: an original task-to-verification workflow for using thinking effort. It is a workflow recommendation, not a claim that Visual Studio automatically selects the level. Feature details are based on Microsoft’s release notes.
Low: fast, bounded assistance
Use Low for autocomplete-like work, small refactors with clear acceptance criteria, naming suggestions, documentation edits, and direct questions about code you already understand. The goal is not maximum intelligence; it is keeping a routine interaction quick and economical.
Low is a poor default for an unfamiliar authentication flow, a database migration, or a change that touches authorization. A fast answer can still be wrong, and the cost of a mistaken assumption is often much larger than the token savings.
Medium: the practical daily setting
Medium is the sensible starting point for ordinary implementation work: writing a unit test, explaining a function, adding a small endpoint, or converting a well-understood pattern. It gives the model more room to reason without making every prompt a high-cost investigation.
Treat Medium as a productivity setting, not a correctness guarantee. The same verification loop still applies: inspect the patch, run tests, and check the result against the repository’s conventions.
High: reserve it for expensive uncertainty
High is designed for harder problems such as architectural decisions, complex debugging, algorithm design, and security review. It can be useful when the model needs to compare multiple paths, trace behavior across files, or reason through edge cases.
High should not become a substitute for expertise. For security-sensitive changes, ask for an explicit threat model, list the assumptions, and verify claims against tests, documentation, and code. Do not accept a polished explanation as evidence that an issue is fixed.
A verification-first Copilot workflow
The most useful way to adopt the setting is to connect it to a repeatable review policy.
- Classify the task before opening Copilot. Identify whether it is routine, implementation-level, or high-risk. This prevents High from becoming a reflex.
- Choose the effort level manually. Visual Studio does not automatically infer the right level from context, so make the decision explicit.
- Constrain the request. Name the files, acceptance criteria, non-goals, test command, and security boundaries. Smaller scopes make review easier.
- Inspect the generated diff. Look for unrelated edits, changed behavior outside the task, missing error handling, and new dependencies.
- Use the Git agent as a second pass. Ask it to review uncommitted changes or attach a commit for review. Treat comments as hypotheses to investigate.
- Run deterministic checks. Tests, type checks, linters, static analysis, and targeted manual checks should decide whether the patch is acceptable.
- Record the reason for the chosen effort. In a team, a short note such as “High: authorization boundary changed” makes spend and risk visible.
This complements a broader verification-first approach to AI-assisted software engineering: let the model accelerate exploration, but let evidence determine acceptance.
Using the new Git agent before a pull request
Visual Studio 18.9 lets you switch to the Git agent in Copilot Chat and ask it to review uncommitted work. Findings appear as inline comments in the editor, with a navigable list in the Git Changes view. You can also review a specific commit, where comments appear in a commit-specific view separate from the working files.
That placement is valuable because it shortens the loop between generation and inspection. A developer can ask for a review while the change is still local, investigate a finding, apply a fix, and run the tests again before creating a pull request.
The review does not replace a CI review or a human owner. It can miss a business invariant, misunderstand an intentional behavior, or flag a harmless pattern. Use it as an additional reviewer with a different failure mode, not as an approval gate by itself.
For teams already using agentic development, pair this with a sandbox and least-privilege policy. The site’s AI sandboxing guide explains why generated code and tool actions should run inside controlled boundaries rather than receiving unrestricted access to a developer machine.
Organization-level custom agents: consistency with an audit trail
Organization owners can now add custom agents that are available across repositories in the organization. Visual Studio detects them in repositories that belong to the organization, shows their description and source, and lets developers open the agent definition.
This can standardize tasks such as:
- reviewing API changes against an internal checklist;
- generating tests with a required framework and naming convention;
- checking a pull request for privacy or logging regressions;
- explaining a service using approved architecture vocabulary.
The risk is centralization without review. Treat an organization-level agent definition like executable workflow policy: version it, assign an owner, document the tools and data it can access, and test it against representative repositories. A shared prompt that quietly changes behavior across dozens of projects deserves the same change-management discipline as a shared CI action.
Teams building richer agent applications can also compare this pattern with the GitHub Copilot SDK guide, especially when an IDE workflow needs to become a service, bot, or custom developer experience.
Token budgets, model choice, and context windows
The redesigned model picker and Model management view expose cost information, capabilities, and context-window sizes for available models. The context window indicator also links to plan usage details, making it easier to notice when a long conversation is consuming the available budget.
That visibility changes the optimization question. The goal is not simply “use the smartest model.” Instead, choose the least expensive configuration that can meet the task’s evidence standard:
- use Low for narrow, reversible actions;
- use Medium for normal implementation with tests;
- use High when uncertainty or risk justifies deeper analysis;
- start a fresh, focused conversation when old context is no longer relevant;
- keep the actual repository diff and test output as the authoritative record.
Context size is not the same as useful context. Passing a huge project history can hide the files and constraints that matter. A concise task brief plus the relevant code and test output is usually easier to audit than an unbounded chat transcript.
What version should developers install?
If you are adopting the August feature set, use Visual Studio 2026 version 18.9.1 or later when available. Microsoft lists 18.9.1 as released on August 18, 2026, with a fix for a Copilot Command preview dialog that could not be scrolled far enough to reach allow or deny actions, plus a Test Agent fix.
The first release also added Git submodule support, worktree management, multi-file summary diffs, commit reviews, and improved pull-request controls. These features are useful for complex repositories, but they increase the amount of state an AI-assisted workflow can inspect. Keep repository boundaries clear and review what context is attached to each request.
Common mistakes and debugging checks
The effort control is missing
The feature only applies to supported Copilot models. Check the model picker and Model management view, confirm that Visual Studio is updated, and verify that the selected model and plan expose adjustable reasoning. Do not infer support from a model’s marketing name.
High effort produces a longer but not better answer
More reasoning effort can increase analysis without fixing a bad prompt or missing evidence. Add acceptance criteria, provide the failing test or error trace, constrain the files, and ask the model to state assumptions. If the task is ambiguous, resolve the ambiguity yourself rather than paying for more speculation.
The Git agent flags too many issues
Narrow the review scope and tell it whether you are reviewing uncommitted changes, one commit, or a specific risk category. Then classify findings as real defect, intentional behavior, style suggestion, or false positive. Keep a human-reviewed checklist for recurring false positives.
Usage rises unexpectedly
Check the selected effort level, model, context-window indicator, and plan usage details. Long conversations and repeated high-effort retries can dominate spend. Split unrelated tasks, remove stale context, and use a lower setting when the acceptance criteria are simple.
A custom agent behaves inconsistently
Open its definition, compare the repository context it receives, and test it against a small fixture. Look for hidden assumptions about branch state, tool availability, permissions, or organization policy. Pin changes to a reviewed version before broad rollout.
FAQ
Does High thinking effort make Copilot code correct?
No. It gives a supported model more reasoning effort, but correctness still depends on the prompt, context, model, repository, and verification. Tests and review remain necessary.
Does Visual Studio automatically choose Low, Medium, or High?
No. Microsoft documents the levels as a developer-controlled setting. Choose the level from the model picker or Model management view.
Can every Copilot model use the control?
No. Adjustable thinking levels are available only for supported models. The installed model picker is the current practical reference.
Can the Git agent review a committed change?
Yes. Visual Studio 18.9 supports reviewing a commit, or a range of changes, with comments shown in a commit-specific view. It also supports review of uncommitted changes.
Are organization custom agents available to every GitHub user?
The organization-level feature requires a GitHub organization and administrative setup. Availability can also depend on the relevant Copilot plan and organization configuration.
Should teams standardize on High for security work?
High can be a reasonable starting point for complex security review, but it is not a security control. Pair it with least privilege, tests, static analysis, threat modeling, and human approval.
Conclusion
Visual Studio 2026 18.9 makes Copilot more tunable and more inspectable. The thinking-effort setting gives developers a manual quality-and-cost control; the Git agent shortens the review loop; organization custom agents make shared workflows easier to distribute; and model and usage views make consumption more visible.
The best adoption pattern is deliberately boring: choose effort based on task risk, keep the request bounded, inspect the diff, run deterministic checks, and use agent review as another signal. The dial is useful because it puts a decision in the developer’s hands. It becomes genuinely valuable only when that decision is connected to evidence.
Sources and visual credits
- Microsoft Learn: Visual Studio 2026 release notes — primary source for version 18.9, 18.9.1, thinking effort, Git agent, organization custom agents, model management, and usage features.
- GitHub Changelog: GitHub Copilot in Visual Studio — July update — primary source for the preceding Copilot agent, built-in skills, selected-code review, and organization-level instructions.
- BetaNews: Visual Studio 2026 lets developers dial up or down Copilot’s thinking — independent secondary reporting on the release and its developer implications.
- Mermaid workflow diagram: original diagram by the author, based on the Microsoft release notes; no external image assets used.
- Comparison table: original editorial synthesis of documented features; source links are provided above.
This article contains no runnable code because the documented changes are Visual Studio and Copilot UI/workflow features rather than a public SDK or API surface. The practical implementation is configuration and review procedure, not a code snippet that could be copied and executed reliably across plans and model availability.
Keep reading
Related reading
⚡ Daily AI Model Drop — Get Kimi K3 benchmarks before Twitter
Join 2,400+ AI engineers. 1 email/day, no spam, unsubscribe anytime