Weekly GitHub Copilot Roundup: Models, Agents, and Governance

by TechHub

Welcome to this week's GitHub Copilot roundup, where the story is equal parts model churn and operational control. New model options landed (Claude Sonnet 5 and Kimi K2.7 Code GA, Claude Opus 4.8 fast mode preview) while GitHub signaled upcoming removals for Gemini 2.5 Pro and Gemini 3 Flash, making policy audits and fallback planning a practical admin task. In the IDE, Copilot keeps pushing into agent workflows with vision attachments, browser tools in VS Code, and JetBrains support via ACP, backed by better session UX and usage visibility. On the governance side, managed-settings.json, cost-center budgets, session streaming, and CLI/SDK credit limits make it easier to enforce guardrails while still letting teams use agents in editors, CI, and tool-driven workflows.

This Week's Overview

Model changes and admin control in Copilot

July brought a mix of new model options, faster variants, and a clear reminder that model availability in Copilot is not static - building on last week's focus on Auto mode rollout, token economics, and planned deprecations as something admins need to operationalize, not just “keep up with.” Claude Sonnet 5 is now generally available across Copilot surfaces (major IDEs, Copilot CLI, and GitHub experiences), and Kimi K2.7 Code also moved to generally available as a selectable model in the model picker. In parallel, Anthropic's Claude Opus 4.8 (fast mode) rolled out in preview, positioned for interactive and agentic workflows where output speed matters.

At the same time, GitHub announced a near-term deprecation: Gemini 2.5 Pro and Gemini 3 Flash will be removed from Copilot experiences on July 31, 2026, with Gemini 3.1 Pro and Gemini 3.5 Flash listed as replacements. If you run Copilot Enterprise, this is not just informational - admins may need to explicitly allow the replacement models via model policies so they show up in Copilot Chat model selectors (VS Code and github.com). This week is a good time to audit model policies and confirm developer clients will have a smooth fallback path before the cutoff date.

There were also policy-level changes that reduce friction for defaulting model behavior without taking choice away from developers. Enterprises can now set model to auto in enterprise managed-settings.json, which makes auto model selection the default for new conversations while still allowing per-conversation model changes. On the Copilot CLI side, auto model selection got a more explicit description of how routing works (task characteristics plus real-time availability/health) and how it bills (using model multipliers from 0x to 1x, plus a 10% discount for paid subscribers), which matters if you are trying to predict spend for scripted or CI usage.

Copilot in the IDE: agents, vision, and workflow UX

This week's IDE story was about Copilot moving beyond chat into more “do the work” surfaces: attaching real artifacts, running tools, and managing multi-step agent sessions - a continuation of last week's agent-first push (desktop app, parallel sessions, and worktree-backed flows) showing up directly inside editors. Copilot vision is now generally available, enabling image and PDF attachments in Copilot Chat (VS Code and github.com) as well as in the Copilot CLI, and it no longer requires the Editor Preview Features policy for Business and Enterprise plans. If your team does debugging from screenshots, UI diffs, logs exported to PDFs, or design review workflows, this takes “paste text into chat” out of the critical path.

Browser tools and agent workflows in VS Code

Browser tools for Copilot in VS Code are now generally available, giving agents the ability to drive a real browser to navigate and test web apps, capture page content, read console errors, and run scripted flows. For teams that have been cautious about agents touching production-like environments, the details matter: the rollout includes privacy defaults and enterprise admin controls, plus VS Code concepts like Workspace Trust that influence what tooling is allowed to run.

VS Code 1.127 also shipped a set of practical Copilot UX improvements aimed at the reality of long-running agent work, following last week's focus on token efficiency and session operability (caching, transport, and session controls) by making those sessions easier to manage and inspect in the UI. The update includes session list drag-and-drop, chat input banners, editor gutter feedback while reviewing agent changes, session layout tweaks, a “troubleshoot” skill for diagnosing agent behavior, and visibility into subagent credit consumption. Together, these changes make it easier to treat agent sessions like a first-class artifact you can inspect, re-order, and review rather than a transient chat thread.

Copilot Agent reaches JetBrains via ACP

Copilot Agent is now available in JetBrains AI Assistant, enabled through agent client protocol (ACP) support inside the AI Agents tab - a clear next step from last week's JetBrains story (Copilot CLI integration with ask/plan/agent modes) toward a more native, multi-step agent experience inside the IDE. The practical takeaway is that multi-step workflows (summarizing a project, reviewing a README, running tests, and checking code coverage) can now happen in JetBrains without bouncing back to GitHub or VS Code as the “agent home.” GitHub's changelog framing also calls out model selection and reasoning-depth controls in the JetBrains experience, which matters if your org standardizes on specific models or wants to enforce consistent review depth.

If your team spans multiple IDEs, this is another signal that Copilot's agent surface is becoming portable: the same “agentic” capabilities are increasingly defined by a protocol boundary (ACP) rather than a single editor integration. Expect more emphasis on shared concepts like skills, session management, and evaluation outputs as Copilot spreads across clients.

Visual Studio updates: usage tracking, trusted MCP servers, and C++ modernization

Microsoft's Visual Studio June update leaned into governance and day-to-day operational clarity, extending last week's theme that MCP and agent integrations need explicit safety boundaries (policy controls, safer tool design, and attribution) by adding trust validation at the IDE level. The Copilot Usage window now includes token-based tracking and alerts, which should make it easier to spot runaway prompts or unexpectedly expensive sessions before they hit monthly thresholds. The update also adds trust validation for MCP servers, reflecting the fact that connecting tools to agents is now a security decision, not just a convenience feature.

On the C++ side, the GitHub Copilot modernization agent for C++ MSVC upgrades is now generally available, targeting the real work of keeping native codebases aligned with evolving MSVC Build Tools. Teams modernizing large C++ solutions should read this as “agent assistance is moving into refactoring and migration workflows” rather than only greenfield code generation.

Enterprise governance, budgets, and auditability for Copilot usage

GitHub shipped several changes that collectively make Copilot easier to govern at enterprise scale: centralized settings enforcement, better budgeting controls, and improved visibility into what agents did - picking up from last week's additions to usage reporting and attribution by turning more of those policies and metrics into enforceable, streamable enterprise primitives. Enterprise managed-settings.json is now generally available for GitHub Enterprise Cloud, letting you centrally manage and enforce Copilot client settings by storing a file in a .github-private repository that VS Code and Copilot CLI will honor. This closes a common gap where orgs could define policy but struggled to make it stick consistently across developer machines and automation environments.

Budgeting and spend controls: cost centers, pools, and per-user caps

Cost centers now support AI credit pools, which let enterprises cap how much of their monthly included Copilot AI credits each cost center can consume (currently via the REST API). Per-user AI credit budgets at the cost center level also arrived, automatically adjusting as users join or leave cost centers or enterprise teams, with REST API creation available now and billing UI support planned. These two features work well together: pools set the maximum slice for a cost center, and per-user budgets help prevent a small number of heavy users from consuming that slice early in the month.

For developers, the practical impact is that agent-heavy workflows may start failing “by design” once caps are hit, so teams should decide where to enforce constraints (cost center caps, per-user budgets, or per-session limits in the CLI/SDK). For admins, the REST-first nature of these features means you may want to build internal automation (or Terraform-like wrappers) to keep budgets aligned with org changes.

Auditing agent activity: session streaming and improved metrics attribution

Copilot agent session streaming is now in public preview for GitHub Enterprise Cloud, letting customers stream or query agent session usage records (prompts, responses, and tool calls) across Copilot clients - a direct continuation of last week's push for better agent attribution and enterprise reporting, but with the raw event trail many orgs need for incident response. You can route this via audit log streaming to a SIEM/event collector, including Microsoft Purview as a supported endpoint, or pull records through a REST API covering the last 48 hours. This is a concrete step toward treating agent activity like other auditable enterprise events, which is often required for regulated environments and incident response workflows.

GitHub also improved the Copilot usage metrics API in ways that make chargeback and adoption analysis less fragile. Copilot CLI now reports suggested lines of code, more users will have IDE/plugin details available through server-side telemetry, and AI credit usage attribution is more accurate at the organization and enterprise level. If you rely on fields like ai_credits_used and breakdowns like totals_by_ide, these changes should reduce the “unknown client” bucket and make it easier to reconcile usage with billing controls.

Copilot in automation: safer CI usage and credit guardrails

Copilot CLI now runs in GitHub Actions using the built-in GITHUB_TOKEN instead of requiring a personal access token (PAT), building on last week's emphasis on CLI session control and enterprise permission-prompt policies by making CI usage both easier to adopt and easier to secure. That removes a common secret-management footgun (long-lived PATs in CI) and makes it easier to adopt Copilot CLI for scripted tasks like issue triage, code generation experiments, or build troubleshooting in PR workflows. The update also spells out the required Copilot policy/permissions and how billing and spend controls work for AI credits at the organization level, which is important if you want CI usage without surprise spend.

Public preview support for AI credit session limits also landed for Copilot CLI and the GitHub Copilot SDK. Teams can cap per-session spend for interactive and scripted runs, and the cap applies across model calls, subagents, and background work, stopping the agent when it reaches the limit. Practically, this gives you a “circuit breaker” you can attach to CI jobs (or developer scripts) so an agent does not burn through credits while stuck in a loop or exploring an oversized search space.

Tooling integrations with MCP and Copilot Skills

This week continued the shift from “chat assistant” to “tool-using agent” by expanding the number of MCP (Model Context Protocol) and skill-based integrations that can be run locally and in CI, extending last week's pattern of MCP spreading into build diagnostics and database workflows by showing what “production-shaped” integrations look like (reports, evals, and CI loops). In practice, MCP provides a standardized way for an assistant to call external tools, where the MCP server defines what tools exist and what inputs/outputs look like. That standardization is increasingly paired with enterprise controls (like trust validation and audit streaming) so teams can treat tool access as a governed capability.

Driving Chaos Studio from assistants and agents

Azure Chaos Studio introduced Chaos Studio Workspaces in public preview, described as a scenario-based approach to chaos engineering with curated outage drills, recommended scenarios, and structured scenario reports. The reporting angle is key: reports are correlated with Azure Monitor signals, so the outcome of a drill is tied to the telemetry teams already use to detect incidents. Mark Russinovich's post also highlights integration paths through a GitHub Copilot Skill and an MCP server, enabling AI assistants and agents to drive Chaos Studio workflows instead of requiring manual portal setup.

The example Microsoft Entra ID outage scenario underscores where this can fit: teams can run standardized incident simulations, capture consistent evidence, and iteratively harden reliability controls with less bespoke scripting. For platform teams, pairing scenario catalogs with AI-driven execution also suggests a path toward “resilience runbooks as code,” where drills become repeatable workflows that can be triggered during readiness reviews or pre-release gates.

MCP in CI: diagnosing builds with MSBuild binlogs

A .NET team post showed how to run the Microsoft Binlog MCP Server inside GitHub Actions so that when a PR build fails, an agent can analyze MSBuild binlogs and post a root-cause comment with suggested fixes - essentially the CI follow-through to last week's Binlog MCP Server preview by showing how teams can operationalize it where failures actually happen. This is a good example of why MCP matters: rather than pasting logs into chat, the workflow gives the agent a tool that can query structured build artifacts and return targeted diagnostics. The article also lists other Binlog MCP tools and shares evaluation results comparing tool-based setups against a baseline with no tools, which helps teams justify the extra integration work.

For teams with noisy CI, this is a practical pattern: “on failure, generate a machine-readable artifact, run an MCP tool against it, and post a summary back to the PR.” It keeps the analysis close to the failure context and creates a durable record in the code review thread.

Copilot CLI plugins: C++ language server setup as a skill

GitHub added a Microsoft C++ Language Server plugin to the Copilot CLI plugins marketplace, with a setup skill that generates and refreshes compile_commands.json for CMake, MSBuild, and custom build systems - another example of the MCP/skills expansion we covered last week, but aimed at the “environment setup” work that often blocks agentic refactoring and review. This targets a common pain point in C++ tooling: language servers and static analysis tools often need accurate compilation databases to provide correct navigation, diagnostics, and refactorings. Turning that setup into a reusable skill is a small but useful step toward “agent assists with environment setup,” not just code output.

If you support mixed build systems or complex native repos, the immediate benefit is reducing the time it takes new contributors (or CI environments) to get correct IntelliSense and analysis results. It also makes it easier to standardize how compile_commands.json is produced across different developer machines.

Copilot code review: deeper reasoning for complex PRs

GitHub demonstrated a “medium depth” option for Copilot code review in public preview, which fits alongside last week's AGENTS.md controls by pairing “what to check” (repo guidance) with “how hard to think” (reasoning depth) for more consistent review outcomes. The pitch is straightforward: a higher reasoning model produces more thorough pull request feedback, particularly for complex changes and security-sensitive code paths. GitHub also showed that admins can enable the feature at the repo or org level, which is important if you want consistent review expectations across teams rather than opt-in behavior.

For developers, “medium depth” reviews are most useful when you already have basic linting and static analysis in place, and you need the review to focus on logic, security boundaries, and edge cases. If you try it, a good starting pattern is to limit scope to high-risk directories (auth, payments, infra), then compare defect catch rates and review time before rolling it out broadly.

Other GitHub Copilot News

Several updates this week were more about how developers interact with Copilot day to day than about governance or models, continuing last week's shift of the Copilot app into a stable “issue to merge” loop by digging deeper into canvases and app-first skills. GitHub's Copilot app content explored “canvases” and new skills like /impeccable, showing a workflow where you iterate on UI improvements (fonts, drag-and-drop behavior, event grouping) and then open a pull request directly from the app. In parallel, two longer-form guides clarified that Copilot App Canvas is meant as a development-time runtime for agent-driven systems (not a UI builder), with concrete examples like observability hooks, control actions, validation via JSON Schema, and fault injection over protocols like SSE and JSON-RPC over stdio.

On the broader ecosystem side, VS Code Insiders 1.128 continued to expand AI configuration knobs, including custom model parameters for BYOK (bring your own key) endpoints and the option to run the Claude agent using Anthropic API credentials instead of GitHub Copilot quota. If you are mixing Copilot with vendor-direct billing or experimenting with custom endpoints, this is another step toward making the editor the integration hub for multiple AI backends. John Savill's Azure Update (July 3, 2026) also called out Copilot model availability alongside Azure AI Foundry updates, which is useful context if you're tracking how Azure and Copilot model catalogs evolve together.