Weekly GitHub Copilot Roundup: Agents, governance, and metered AI

by TechHub

This week, GitHub and Microsoft positioned Copilot as part of an enterprise agent platform, where identity, tool access, policy, observability, and eval loops matter as much as model output. Copilot also moved further into resource management, with model deprecations and replacements, optional Gemini models via admin policy, 1M-token context and reasoning controls, and fully live usage-based billing tied to GitHub AI Credits (plus new cost signals for code review and Actions). Inside GitHub, agentic workflows expanded with richer PR context for Copilot Chat, configurable code review tiers and MCP-backed skills, Azure Repos review previews, and Marketplace-installed agent apps. The rest of the updates fill in the execution and governance layer (CLI scheduling and rubber-duck review, sandboxes, a cloud agent tasks API, the Copilot SDK GA, and tighter enterprise controls across VS Code, JetBrains, Visual Studio, and Eclipse).

This Week's Overview

Copilot becomes an agent platform (not just an assistant)

This week, Microsoft and GitHub framed Copilot as one layer in a larger enterprise agent stack: build in GitHub (with Copilot), ground with Microsoft IQ, run in Azure AI Foundry, and govern with Agent 365 plus the Microsoft Security stack. Building on last week's shift toward “agent plumbing” (MCP for tool integration, OpenTelemetry for observability, and policy/audit hooks), the message is that “AI output” is only useful if the surrounding system handles identity, tool access, policy, observability, and continuous improvement (evals, traces, routing, tuning, and reinforcement learning).

For developers, the practical shift is toward standardized “agent plumbing”: MCP (Model Context Protocol) for tool/context integration, shared evaluation loops to keep agents reliable, and production controls that make agent execution auditable. If you're rolling Copilot into internal developer workflows, the articles this week are a reminder to design for lifecycle operations (metrics/traces, model routing, approvals) instead of treating prompts as the product.

Copilot models, context, and pricing move toward “resource management”

Several Copilot changes this week are really about operational control: which model runs, how much context it can consume, and how you pay for it. Together they push Copilot usage toward the same kind of governance you already apply to CI minutes or cloud budgets.

Model churn: deprecations and policy-driven replacements

GitHub deprecated GPT-4.1 (June 1) and then GPT-5.2 and GPT-5.2-Codex (June 5) across most Copilot experiences, pointing users to GPT-5.5 and GPT-5.3-Codex as replacements, which follows directly from last week's push to stabilize enterprise defaults via the GPT-5.3-Codex LTS baseline and tighter policy-managed routing. On Copilot Enterprise, admins may need to explicitly enable the replacement models using model policies so they show up in Copilot Chat selectors (VS Code and github.com), which makes model availability a managed enterprise setting rather than an end-user preference.

The other side of this is expansion: Gemini 3.1 Pro (Preview) and Gemini 3.5 Flash can now be selected in more surfaces (Copilot CLI, Copilot cloud agent, Copilot app technical preview, and the Copilot SDK). Business and Enterprise admins must opt in via model policy settings, so expect “which models are allowed” to become a standard part of Copilot rollout checklists.

1M-token context windows and configurable reasoning levels (with credit impact)

Copilot now supports one-million-token context windows and configurable reasoning levels across VS Code, Copilot CLI, and the Copilot app (with more surfaces planned), extending last week's theme that model choice and routing details are becoming day-to-day cost and governance levers rather than hidden implementation details. The catch is explicit: larger context and higher reasoning consume more AI credits per interaction, so teams will need to balance “load more repo” against predictable spend.

If you are standardizing agentic workflows, this makes it worth defining defaults (for example, low reasoning for quick Q&A, higher reasoning only for complex refactors) and educating developers on when a 1M-token context is actually needed. It also ties into tooling like token budgeting controls in Copilot CLI sessions, because “bigger context” is now a first-class cost lever.

Usage-based billing goes fully live (AI Credits, budgets, and code review costs)

GitHub Copilot moved to usage-based billing for all users, with plan consumption based on GitHub AI Credits and new user-level budget controls. Following last week's additions around premium multipliers, Auto discounts, and cheaper “small task” models, this makes the cost surface explicit enough that teams can start treating Copilot like any other metered platform service. Copilot Max upgrades are now part of the plan structure, and Copilot code review now consumes GitHub Actions minutes in addition to AI Credits, which makes code review automation a combined “AI + CI” cost center.

Individual plans also gained access to “evaluation models” that Copilot Auto may select, and GitHub provides a setting to disable evaluation models if you want predictability. For teams, that means you can now treat Copilot like any other shared resource: enforce budgets, define allowed models, and decide whether experimental/evaluation models can run in production workflows.

Agentic workflows land across GitHub: code review, PR context, and agent apps

This week added more “agent-shaped” surfaces inside GitHub itself, especially around code review and pull requests. The pattern is consistent: richer repository and PR context, plus ways to invoke specialized agents in the same places developers already collaborate.

Copilot Chat in PRs and richer diff context (GA)

Copilot Chat is now generally available on github.com with richer and faster pull request and diff context, building on last week's web-side shift toward more persistent, page-level context in Copilot Chat as you navigate GitHub. That matters because PRs are where teams make correctness and safety decisions, so having Copilot summarize, explain changes, and answer questions directly on the PR page reduces the friction of “copy/paste diff into chat” workflows.

If you're piloting AI-assisted review, this GA release is a good moment to define a team convention for how Copilot output is used (for example, summaries for navigation, questions about intent, and targeted review checklists), rather than treating it as a blanket approval signal.

Shaping Copilot code review with MCP skills and effort tiers (public previews)

GitHub introduced public previews that let you shape Copilot code review around your team: MCP/agent skills can bring organization-specific context into reviews (docs, standards, checklists), and a new “Medium” review tier routes complex PRs to a higher-reasoning model with usage-based cost signals, which follows last week's UI work that made “Fix with Copilot” more explicit and controllable in PR review flows. This is a concrete step toward review policies that consider both quality and spend, instead of treating all PRs the same.

The MCP angle is especially important because it makes review customization a configuration and integration problem (what context is available, how it's retrieved, and how it stays current). GitHub also has a demo showing how to extend Copilot code review with MCP and custom skills so reviews can incorporate external documentation and repo-defined checklists for more tailored feedback.

Copilot code review reaches Azure Repos (technical preview)

Copilot code review is now in technical preview for Azure Repos, enabling on-demand PR reviews directly inside Azure DevOps. Coming right after last week's MCP-focused Azure DevOps integration examples, this preview is another sign that Copilot review workflows are being designed to travel across repo hosts, not just within github.com. Billing starts June 2, 2026 and uses GitHub AI credits, which is a notable cross-product linkage if your repos live in Azure DevOps but you want Copilot-powered review workflows.

This fits alongside Microsoft's broader “Azure DevOps meets GitHub” story: hybrid SDLC patterns (Boards/Pipelines with GitHub), remote MCP servers, and more AI-driven review and autofix capabilities. If you're in a staged migration from Azure Repos to GitHub, this preview gives you a way to standardize review automation earlier, before repo hosting is fully consolidated.

GitHub agent apps: Marketplace-installed agents inside issues and workflows

GitHub introduced “agent apps”: partner-built AI agents installed from the GitHub Marketplace and invoked inside GitHub via issue assignment, PR @mentions, or the Agents UI within workflows, extending last week's direction that agents are becoming first-class workflow participants (review-to-fix, CI remediation, and managed configuration) rather than one-off chat helpers. This turns “bring your own agent” into a first-class GitHub integration pattern, closer to how teams already adopt GitHub Apps for CI, code quality, and automation.

For developers, the key question becomes governance: which agent apps can access repos, what permissions they receive, and what audit trail exists for the changes they propose. Expect teams to treat agent apps like any other third-party automation that can open PRs or comment on issues.

Copilot CLI, sandboxes, and cloud agents: safer execution and more automation hooks

The Copilot story in terminals and agent execution got more concrete this week: improved Copilot CLI ergonomics, more sandboxing options, and APIs to kick off cloud agent tasks programmatically. The common theme is moving from “chat about code” to “run tools and produce PRs,” with guardrails.

Copilot CLI refresh: UI, rubber duck review, scheduled prompts, and voice input

Copilot CLI shipped a refresh with an experimental tabbed terminal UI and new generally available capabilities: the Rubber Duck review agent, scheduled prompts via /every and /after, and local voice input for dictation, building on last week's momentum around richer CLI sessions (including remote control) by adding more ways to structure and critique work inside the terminal. The Rubber Duck pattern (a second model family challenges the first model's plan and code) showed up repeatedly across Build content as a practical way to catch errors earlier.

If your team already lives in terminals, the scheduling commands are an underrated workflow primitive: recurring prompts can enforce habits (run tests, update changelogs, re-check open TODOs) without building custom scripts. Voice input being local also matters for privacy-sensitive environments where you still want faster interaction.

Copilot sandboxes (public preview): isolate tool execution locally or in GitHub-hosted environments

GitHub announced public preview “cloud and local sandboxes” for Copilot, giving you isolated environments for tool execution with policy and governance controls, which pairs naturally with last week's push to make cloud agent configuration auditable because sandbox permissions become another part of the agent surface area you may need to review and standardize. The point is to make agentic coding safer by restricting filesystem, network, and system access during execution, which directly addresses the risk of an agent running a destructive command or pulling untrusted dependencies.

GitHub also published a demo showing the /sandbox enable flow and how to configure permissions like network and file system access. This is the sort of feature that becomes mandatory once you let agents run linters, build steps, or migration scripts instead of just suggesting code.

Copilot cloud agent automation: Agent tasks REST API and “Fix with Copilot” for Actions

A public preview Agent tasks REST API is now available for Copilot Pro, Pro+, and Max, letting developers start and track Copilot cloud agent tasks programmatically. This builds on last week's early governance/auditing building blocks for cloud agents by making agent execution easier to trigger from scripts and systems (which increases the need for consistent policies, logging, and guardrails). These tasks run in an isolated environment and open pull requests with validated changes, and the API supports authentication using personal access tokens and OAuth.

On the GitHub Actions side, “Fix with Copilot” is now available for Pro, Pro+, and Max: the Copilot cloud agent can investigate a failing Actions job, push a fix to a branch, and tag the developer for review. Together, these changes make it easier to wire Copilot into automation loops (CI failures, scheduled maintenance, dependency bumps) while keeping humans in the approval path via PRs.

Copilot SDK goes GA, and enterprise-managed extensions start to solidify

This week was a milestone for building on Copilot: the Copilot SDK reached general availability, and VS Code added early enterprise controls for managed Copilot CLI plugins. The direction is clear: organizations want extensibility, but they also want a way to standardize and lock it down.

Copilot SDK (GA): embed the agent runtime with MCP, streaming, and tracing

The GitHub Copilot SDK is now generally available, offering a stable, production-ready API to embed Copilot's agent runtime into apps and developer tools across multiple languages, and it lands right after last week's set of MCP and “agent memory” examples that showed what teams were already building around Copilot in practice. The GA scope includes tools, MCP integration, streaming, and multi-turn sessions, and it calls out OpenTelemetry support plus authentication options (OAuth, GitHub Apps, and BYOK).

In practice, this means you can build “Copilot-like” experiences inside internal tooling: repo-aware assistants, task runners that open PRs, or domain-specific agents that use your own MCP servers to pull context. The Build sessions around the SDK leaned into multi-agent orchestration concepts and demonstrated how you'd compose agent behavior rather than relying on one monolithic chat.

Enterprise-managed Copilot CLI plugins in VS Code 1.122 (public preview)

VS Code 1.122 adds a public preview feature for enterprise-managed GitHub Copilot CLI plugins, allowing admins to centrally define plugin marketplaces and enforce hooks and MCP configurations via a shared settings.json, which builds on last week's pattern that MCP-backed tooling is spreading across clients and now needs consistent admin control rather than per-developer setup. This is the missing “policy layer” for plugin-driven agent workflows, because plugins often become the pathway to tool access, credentials, and outbound network calls.

If you're adopting MCP and skills broadly, this gives you a straightforward control point: decide which plugins are allowed, how MCP servers are configured, and what hooks run in enterprise environments. It also sets the stage for consistent developer experiences across machines, since settings and marketplaces can be standardized.

The Copilot app expands: agent-native desktop workflows from issue to merge

GitHub pushed the Copilot app deeper into the Copilot portfolio this week, positioning it as a desktop hub for agent-driven development, continuing last week's thread that Copilot experiences are converging across web, IDEs, and CLI with shared sessions and longer-lived context. The emphasis is on keeping context and execution in one place as you move from an issue to a PR to a merge.

The Copilot app technical preview expanded to existing Copilot Pro/Pro+/Business/Enterprise customers, and GitHub highlighted capabilities like canvases, voice conversations, cloud sessions/automations, and tighter integration with Copilot CLI and PR workflows. Demos showed practical mechanics like using Git worktrees for parallel branch work and “agent merge” to handle slow CI by merging automatically once checks pass.

Copilot across IDEs: VS Code, JetBrains, Visual Studio, and Eclipse push agent experiences

IDE integrations continued to converge on the same themes: sessions views for agents, reasoning controls, better context management, and BYOK (Bring Your Own Key) options. The details vary by editor, but the direction is consistent.

VS Code: Agents window, remote agent sessions, and BYOK options (v1.120-v1.123)

The “GitHub Copilot in Visual Studio Code, May releases” changelog (v1.120-v1.123) highlighted an Agents window preview, remote agent sessions, and expanded BYOK options including air-gapped usage, continuing last week's VS Code focus on agent workflows plus the early observability story (OpenTelemetry + Grafana) by adding more dedicated UI for managing sessions. It also mentioned terminal safety and efficiency updates, plus editor improvements like an integrated browser and better Markdown preview.

If you're evaluating Copilot in regulated environments, the air-gapped BYOK mention is the standout because it signals continued investment in “control your keys/models” deployment patterns. The Agents window and remote sessions also align with the new sandboxing and cloud agent capabilities: more work happens in managed sessions, not just in-line completions.

JetBrains: Copilot CLI sessions, new slash commands, and an agent debug panel (preview)

GitHub Copilot for JetBrains IDEs gained Copilot CLI sessions with an agent picker, new slash commands, and an agent debug panel in public preview, which follows last week's GA expansion of remote control for CLI sessions by pushing those terminal-first agent patterns directly into JetBrains workflows. Cloud agent sessions now appear in the unified sessions view, and “thinking effort” (configurable reasoning) is available for supported reasoning models, matching the broader Copilot push toward explicit reasoning controls.

For teams using JetBrains, the agent debug panel is a practical troubleshooting tool: once agents can run tools and open PRs, developers need a way to understand what the agent did, what context it used, and where it failed. The new slash commands like /remote, /compact, and /chronicle also hint at session management becoming part of everyday IDE usage.

Visual Studio 2026: Plan agent, Skills panel, and roadmap toward debugging/profiling/testing agents

The May update for GitHub Copilot in Visual Studio 2026 added a new Plan agent, a Skills panel, multi-file change summaries, context window usage tracking, and improved Git-based context attachment for Copilot Chat, reinforcing last week's introduction of the Plan agent as a practical guardrail for “plan first, then let Agent mode change code.” Those are all aimed at making multi-step work more predictable: plan first, apply skills intentionally, and understand how much context you are consuming.

On the roadmap side, Visual Studio's Build 2026 announcements point toward deeper agent assistance for debugging, profiling, and testing, plus AI-assisted merge conflict resolution and pre-build error checking. Microsoft also reiterated BYOK as part of the approach for using different AI models inside Visual Studio, which is increasingly important as model policy and governance become enterprise concerns.

Eclipse: refreshed chat UI, BYOK custom models, and token visibility

GitHub Copilot for Eclipse shipped a release with a refreshed chat UI and better visibility into context window and token usage, building neatly on last week's Eclipse milestone (the plugin going open source) by turning that momentum into concrete “governable Copilot” capabilities teams can standardize. It also added BYOK custom models for Business and Enterprise, improved ABAP support, new skills/prompt files, and reasoning controls, bringing Eclipse closer to feature parity with other environments on the “governable Copilot” theme.

If you're supporting Eclipse in a mixed-tooling organization, token/context visibility is a practical win for predictable usage, especially now that credit consumption is explicitly tied to context size and reasoning. Skills and prompt files also help align Eclipse workflows with the same repo-based customization patterns used elsewhere.

Copilot for modernization: PR-based refactors, reusable skills, and portfolio workflows

Microsoft continued to push Copilot as a modernization engine, not just a coding assistant. The core narrative is portfolio-scale execution: plan the estate, then apply repeatable refactor patterns via agents that produce PRs with auditable changes.

A key announcement described a two-agent approach: an Azure Copilot migration agent (preview) for estate planning and wave planning, paired with a GitHub Copilot modernization agent (GA) for CLI-driven, PR-based modernization execution across portfolios. Building on last week's emphasis on turning agent behavior into versioned assets (skills, instructions, and managed configuration), the same post also announced GA of custom skills via skill.md, which is effectively a way to encode and reuse organization-specific modernization patterns across repositories.

Build sessions reinforced the same practical patterns: govern modernization with rule books, keep changes PR-based for reviewability, and use agentic workflows to tackle large legacy codebases (including examples like COBOL-to-Java and .NET-to-Azure modernization). If you're modernizing at scale, the most actionable idea is to invest in the skill artifacts (rule books, skill.md, checklists) so that “modernize this app” becomes repeatable work, not a one-off prompt.

Other GitHub Copilot News

Build-week content filled in a lot of the “how” behind agentic development, especially around guardrails, observability, and hybrid GitHub/Azure DevOps workflows, and it follows last week's thread that agent work needs repeatable operational practices (instrumentation, review hygiene, and governance) rather than relying on ad hoc prompting. Several sessions focused on moving from local experiments to production execution with evaluations, tracing, and governance, while case studies showed how large orgs migrate repos and evolve SDLC practices to make room for agents.

OpenTelemetry and evaluation loops kept showing up as the “production readiness” layer for coding agents, including guidance on exporting OTLP telemetry, building dashboards, and using Azure Monitor/Application Insights agent views.

A set of announcements and previews focused on “skills” and MCP configurations as portable building blocks for agents, from Fabric Skills (MIT-licensed skill bundles) to Azure Functions workspaces that install MCP config, hooks, and playbooks, plus broader agent framework updates in Foundry.