Weekly GitHub Copilot Roundup - Models, agents, and cost controls

by TechHub

This week's GitHub Copilot roundup focuses on model churn and tighter governance: Gemini deprecations forced admin action, while new default enablement and team-targeted model policies changed how access evolves over time. GitHub Models retired, pushing model operations toward Microsoft Foundry while Copilot stays the developer-facing layer for chat, agents, and review. On the product side, Grok 4.5 and MAI-Code-1-Flash add new tradeoffs around context, latency, and token efficiency, and client updates across VS Code, Visual Studio, JetBrains, and the Copilot app make agent workflows easier to run at scale. We also cover the practical side of adoption, including expanded usage rollups, budget enforcement that can actually stop overages, and managed settings that extend to the Copilot app, cloud agent, and remote control.

This Week's Overview

Copilot model catalog and governance shifts (deprecations, defaults, and policies)

Copilot teams had to react quickly this week as GitHub deprecated Gemini 2.5 Pro and Gemini 3 Flash across Copilot experiences on July 31, 2026, extending last week's “multi-model and more governable” theme from optional choice into mandatory churn that admins have to manage. The recommended replacements are Gemini 3.1 Pro (Preview) and Gemini 3.6 Flash, but Copilot Enterprise admins may need to explicitly allow those models using model policies so they show up in the Copilot Chat model selector in VS Code and on github.com.

At the same time, GitHub rolled out new controls that change how model access evolves over time in Business and Enterprise. A new policy will enable newly generally available models by default (with org/enterprise opt-out), which reduces manual admin work but makes it more important to review governance posture since this does not apply to open-weight models or models outside GitHub's data retention agreement. For finer-grained governance, enterprise teams model policy targeting entered public preview, letting admins set an enterprise-wide default model set and then grant additional models to specific teams rather than the whole enterprise.

GitHub Models retirement pushes teams toward Copilot and Foundry

GitHub Models was retired as of July 30, 2026, which removes the playground, model catalog, inference API, and BYOK capabilities from that product surface, reinforcing last week's enterprise pattern that pushes “model ops” into governed platforms (like Foundry/APIM) while Copilot stays the user-facing workflow layer. If you built internal workflows around the GitHub Models inference API or relied on its catalog as a discovery layer, you now need to re-home those flows quickly.

GitHub's guidance is to use Microsoft Foundry for model access and GitHub Copilot for AI-assisted workflows on GitHub. Practically, this means splitting responsibilities: Foundry becomes the place you deploy and operate models (including routing and cost controls), while Copilot becomes the developer-facing experience for chat, agents, and code review.

New models and performance signals in Copilot

Copilot's model lineup expanded while telemetry and A/B results continued to shape how teams think about “which model for which workflow”, building on last week's push to make model choice a deliberate, governed practice rather than a personal default. The net effect is more choice, but also more admin policy work if you want model availability to be intentional rather than accidental.

Grok 4.5 arrives (500k context, multimodal, configurable reasoning)

Grok 4.5 (xAI) started rolling out as a selectable model in GitHub Copilot, offering up to a 500k-token context window, multimodal inputs, and a configurable reasoning-effort setting. For developers, that larger context window is most relevant for long design docs, big traces/logs, and multi-file refactors where you want to keep more material in a single thread.

Admins should note the operational details: Grok 4.5 is off by default for Business and Enterprise, and enabling it requires a model policy change. It is also usage-based billed, so you will likely want to pair enablement with budget guardrails if you are rolling it out broadly.

MAI-Code-1-Flash early results (faster, lower-token workflow focus)

Microsoft shared early production and A/B “Auto” flight results for MAI-Code-1-Flash inside GitHub Copilot Chat for VS Code, focusing on acceptance and “code/commit survival” along with efficiency metrics like tokens per turn and turns per commit, which ties directly to last week's emphasis on measuring Copilot usage and understanding how model choice affects cost and outcomes. The framing is clear: this is a lightweight coding model intended for fast iteration loops where latency and token efficiency matter.

If your org uses Auto model selection in VS Code Copilot Chat, these kinds of results matter because they influence what “Auto” picks and when. If you enforce model selection through policy, the metrics still help you decide where a smaller model is good enough (routine edits, iterative debugging) versus where you want a heavier model (architecture, complex refactors, deep reasoning).

Copilot clients and workflows: VS Code, Visual Studio, JetBrains, and the Copilot app

This week brought a steady set of client updates that make agent-based workflows more practical day-to-day, continuing last week's storyline that Copilot is spreading across more “client surfaces” (IDE, mobile, app) while admins try to keep policy and model controls consistent. The common thread is tighter integration of agents, model selection, and governance across IDEs and the Copilot app.

Copilot in VS Code: agents workflow polish, multi-chat, Vision GA, and terminal commands

The July 2026 Copilot in VS Code changelog (v1.127-v1.131) emphasized improvements to the Agents window workflow and support for multi-chat sessions, including Claude support. Copilot Vision reached GA in this period, following last week's hints that richer context inputs were becoming a normal expectation rather than an edge feature, and the Agents window picked up BYOK support so teams can bring their own key and still operate within the agent-oriented UI.

One particularly practical addition is the ability to run terminal commands from chat using a ! prefix, which tightens the loop between “discuss” and “do” when troubleshooting or iterating locally. If you run Copilot in locked-down environments, make sure you understand how these features interact with your enterprise policies, since feature availability can vary based on policy and plan configuration.

Visual Studio: Copilot Chat Agent preview, built-in .NET/Azure skills, and org-level instructions

The Visual Studio July update introduced a new Agent (Preview) in Copilot Chat built on the GitHub Copilot SDK, alongside built-in .NET and Azure skills, building directly on last week's Visual Studio push toward reusable skills and governed capabilities inside the IDE. It also added organization-level custom instructions, which helps standardize how Copilot responds across a company (coding standards, security rules, architectural constraints) without relying on each developer to maintain their own prompt boilerplate.

The update also improved ergonomics around context and workflow, including branch attachment for chat context and selected-code review actions. For C++ teams, improved MSVC toolset discovery across installations reduces friction when agent-assisted changes interact with local toolchains.

JetBrains: OpenTelemetry controls and tighter model management

GitHub Copilot for JetBrains shipped improvements focused on running and observing agent workflows, extending last week's BYOK-and-governance thread into more explicit operations controls (telemetry and limits) inside JetBrains. OpenTelemetry export configuration is now easier to manage, which matters if you want end-to-end traces for multi-step agent operations and tool calls.

The release also expanded model-management controls, including token limits for BYOK and custom endpoints, plus MCP servers and custom agents inside Claude agent flows. This is a clear signal that GitHub expects orgs to treat “which models can be used, with what limits, and with what telemetry” as a first-class operations problem, not a per-developer preference.

Copilot app: stacked work, canvases, and voice/dictation-driven prompting

On the workflow side, the Copilot app got more guidance around structuring large changes into smaller deliverables using stacked sessions and stacked pull requests, a natural next step from last week's “app-first” focus as teams start treating the app as a place to run sustained, reviewable work rather than one-off chats. This pattern is useful when you want Copilot to help with an ordered sequence of PRs that are easier to review and less risky to merge than one large PR.

GitHub also published beginner and setup content that highlights core app mechanics: attaching a session to a project for repo context, using Quick Chat threads in parallel, iterating in canvases (including /create-canvas and Canvas Dev Mode), and using Agent Merge to help with PR review, CI failures, and merge conflicts. Voice input and dictation features showed up both as a focused “voice prompting” tip (speech-to-text to draft prompts faster) and as part of broader customization, including transcription model selection and connecting MCP servers or local models through BYOK providers.

MCP and agent skills expand across code review, IDE tooling, and custom agent stacks

This week connected three pieces that teams often treat separately: code review, IDE troubleshooting, and custom agent implementation, continuing last week's pattern that MCP and skills are becoming the shared layer for “safe tool use” and reusable agent behavior across the Copilot ecosystem. MCP (Model Context Protocol) and “skills” are increasingly the shared plumbing across those scenarios.

Copilot code review: agent skills + MCP connections now GA (with read-only tool calls)

Copilot code review gained generally available support for agent skills and MCP server connections across Copilot Pro, Pro+, Business, and Enterprise, building on last week's moves toward more configurable code review behavior and safer MCP integrations by making the connections officially supported. The key implementation detail is that MCP tool calls are read-only in code review, which sets expectations for what reviewers can do (query, analyze, fetch context) without letting the review agent mutate external systems.

Configuration lives where admins and developers will expect it: MCP servers and tokens can be configured, and skills can be expressed using SKILL.md so repos can declare reusable behaviors. If you want consistent review behavior across repositories, treat SKILL.md as part of your developer platform surface and version it alongside your standards.

MSBuild Binlog Analyzer preview: Copilot Chat + a .binlog MCP server

A preview MSBuild Binlog Analyzer for VS Code uses Copilot Chat backed by the Microsoft.AITools.BinlogMcp MCP server to interpret .binlog files, a concrete follow-on to last week's examples of MCP servers returning richer outputs by showing how MCP can expose structured queries over non-text artifacts developers already produce in CI. It focuses on practical build engineering tasks: explaining failures, analyzing performance and the critical path, comparing builds, and spotting regressions.

For .NET teams and anyone maintaining large MSBuild-based repos, this is a concrete example of MCP's value: it turns a specialized artifact (binary build logs) into a tool the agent can query with structure. If you already archive .binlog outputs in CI for diagnosis, this workflow could reduce time-to-triage when a build breaks or slows down.

Building agent teams: Agent Framework + Copilot CLI/SDK + Squad (with tracing)

Microsoft documented how to wrap a Squad multi-agent team as a Microsoft Agent Framework (MAF) AIAgent so it can run with the GitHub Copilot CLI/SDK, reinforcing last week's “enterprise patterns” thread by showing what agent standardization looks like once you care about operational plumbing like tracing. The walkthrough covers practical engineering details like C# dependency injection (DI), session configuration, and OpenTelemetry tracing for subagents, which matters once your agent workflow is more than a single prompt-response loop.

If you are standardizing internal agents, this approach gives you a path to managed composition (multiple subagents with roles) while still integrating into Copilot CLI workflows and MCP-based tooling. The tracing angle is especially relevant because multi-agent systems are hard to debug without consistent spans and correlation IDs.

Budgeting, usage metrics, and cost controls tighten around usage-based billing

As Copilot expands model choice and usage-based billing options, cost visibility and enforcement became more central, directly extending last week's focus on expanded usage metrics and cost attribution into more complete rollups and clearer enforcement mechanics. This week's updates mixed new telemetry with pragmatic guidance on preventing surprise bills while still letting developers work.

Usage metrics API: Copilot app attribution and expanded rollups

GitHub updated the Copilot usage metrics API so Copilot app usage is attributed to individual users and included across feature/model/language rollups, building on last week's addition of Copilot app activity to enterprise and org reports by making that activity show up cleanly in the rollups teams use for cost and adoption analysis. It also expands token and code activity metrics across enterprise-user and organization-user reports, which should make it easier to answer questions like “which client is driving spend” and “which models are used by which teams”.

If you track adoption and cost by cost center, the key practical change is that Copilot app activity no longer sits outside your usual rollups. That makes it easier to compare IDE usage versus Copilot app usage with the same reporting pipeline.

Budget guardrails: precedence rules and “stop usage” enforcement

Community guidance this week drilled into how Copilot's included AI credit pool and metered overages interact with user-level budgets and enterprise or cost-center overage budgets, echoing last week's “measurable and governable” theme by focusing on what actually prevents spend rather than what just reports it. The most actionable point is operational: if you want to prevent uncapped overages, you need to enable “Stop usage when budget limit is reached”, otherwise budgets can alert without actually stopping spend.

A second walkthrough focused on diagnosing unexpected Copilot Enterprise AI-credit spend by SKU, organization, and cost center, then applying guardrails via org budgets, cost-center budgets, and per-user limits with clear precedence rules. Together, these posts reinforce that budgeting is now a configuration discipline, not just a finance afterthought.

Routing BYOK through Azure: quotas, monitoring, and FinOps-style controls

A more advanced cost-governance pattern pairs GitHub's native Copilot budgets and usage metrics with BYOK routing through Azure API Management into an Azure AI Foundry (Azure OpenAI) deployment, following last week's governed AI gateway pattern by going deeper on quota enforcement and FinOps-style monitoring. The goal is real-time token quotas and per-developer monitoring, using gateway policies like llm-token-limit and llm-emit-token-metric, with metrics flowing into Application Insights for analysis.

This approach is most relevant if you need stronger spend enforcement than Copilot's built-in controls or if you want uniform quotas across multiple AI consumers. It does add operational surface area (gateway config, Foundry deployments, observability), so it tends to fit platform teams rather than individual project teams.

Security and enterprise controls: managed settings, app access policies, and remote control restrictions

Copilot governance expanded beyond “which model can I use” into “which clients can I use” and “from which devices”, continuing last week's direction of tightening guardrails as Copilot moves deeper into PR and agent workflows. For organizations standardizing Copilot at scale, these controls reduce the need for ad-hoc guidance and make enforcement more consistent across developer environments.

Managed settings expand to the Copilot app and Copilot cloud agent

Enterprise managed settings now apply to the GitHub Copilot app and the Copilot cloud agent, extending the reach of managed-settings.json after last week's broader governance push (budgets, session controls, and safer tool connections) by bringing more of the Copilot surface under one policy mechanism. This centralizes controls for plugins, marketplaces, approval prompts, and default model selection behavior across more of the Copilot surface area, which is important now that the Copilot app is a first-class workflow tool and not just an add-on.

If you already maintain managed settings for IDE clients, this reduces configuration fragmentation. It also makes it easier to roll out policy changes (like approved plugins or default model behavior) without relying on per-client documentation.

Dedicated access policy for the Copilot app

GitHub added a dedicated access policy for the Copilot app, separate from the Copilot CLI policy, which fits with last week's framing that the Copilot app is no longer a side surface once it includes security checks and review workflows. This enables independent enable/disable decisions at the enterprise and organization levels, which is useful if your risk posture differs between an interactive desktop app and a command-line tool.

Because the Copilot app is also supported by enterprise-managed settings, existing guardrails (like allowed plugins) can apply consistently once the app is enabled. For admins, the practical change is you can now roll out the Copilot app gradually without changing your CLI stance.

Restricting remote control to managed devices

A new enterprise managed setting, remoteControl, lets organizations restrict remote control to managed devices and choose modes like requireSSO, disabled, or enabled, extending last week's “safer agent workflows” thread by addressing the device and access path those workflows run through. This is aimed at reducing risk when developers use Copilot-assisted remote workflows (for example, agent-driven sessions that can interact with environments beyond the local IDE).

If you are rolling out more agent automation, this control becomes part of your baseline hardening. Treat it like any other device-trust gate: define what “managed device” means in your org, then align the Copilot setting so remote control cannot become a bypass around your endpoint policies.

Other GitHub Copilot News

A mix of practical how-to content this week focused on making agents more reliable (tests, harnesses) and improving day-to-day workflow efficiency (debugging, prompt hygiene), which complements last week's emphasis on turning agent use into repeatable team workflows rather than one-off prompting.

The dotnet/skills team introduced code-testing-generator, a polyglot unit-test agent that learns repo conventions, generates tests, and validates they build and run in the repo's normal test workflow, with benchmarks showing higher task completion and fewer failures than stock Copilot for vague prompts and diff-based test requests. Separately, guidance on an “agent harness” workflow (prototype, plan in-session, implement with Autopilot, then iterate and rubber-duck with another model family) gives teams a repeatable process to reduce agent thrash and improve review quality.

VS Code content this week leaned into “reduce friction before you ask Copilot” and “use Copilot to shorten debugging loops”. One short tip recommends grammar-checking prompts in VS Code before submitting to Copilot to reduce mistakes and potentially lower token usage, and a longer tutorial demonstrates debugging a real Python API using breakpoints, stepping, variable inspection, watch expressions, and the call stack, with Copilot used to help diagnose and fix issues.