Weekly GitHub Copilot Roundup: New Models, Orchestration, Governance

by TechHub

This week in the Weekly GitHub Copilot Roundup, the model lineup expanded (GPT-6 Astra GA, plus Gemini 3.8 Flash and Claude Fable 5.1) while deprecations and policy updates made it clear that model choice is now an admin and billing decision as much as a developer preference. At the same time, Project HydraFusion signaled a shift from picking one model to routing work across multiple models, with early experiments showing how orchestration can balance quality, latency, and spend. Governance also tightened across agent workflows, with content exclusions reaching the Copilot app and CLI, clearer identity constraints for cloud agents in Actions, and new budget expiration controls. On the workflow side, VS Code kept making agent sessions more reviewable, and Copilot code review entered a new phase with optional approvals that can satisfy branch protection rules if you choose to enable them.

This Week's Overview

Copilot model lineup: new GA options, GPT-6 Astra, and deprecations to handle

GPT-6 Astra reaches general availability

OpenAI's GPT-6 Astra is now generally available in GitHub Copilot, with GitHub positioning it for longer-horizon, agentic coding work where the model needs to plan and execute across multiple steps. For teams using the Copilot Coding Agent (and other agentic experiences), this matters because the model choice now directly affects how well multi-step tasks complete without constant re-prompting, extending last week's focus on pairing agent workflows with clearer controls around model choice and spend.

The GA announcement also reinforces that model selection is tied to usage-based billing, and that availability depends on where you run Copilot (IDEs, CLI, and other clients). Practically, developers should verify which surfaces in their workflow expose GPT-6 Astra, while admins should double-check model policy settings so the model actually appears in selectors for the right groups.

Gemini 3.8 Flash and Claude Fable 5.1 arrive as new selectable models

GitHub added two more generally available model options: Google Gemini 3.8 Flash and Anthropic Claude Fable 5.1. Both roll out across major Copilot surfaces (including IDEs and the CLI), and both are governed by Copilot model policies for Business and Enterprise, so admins can allow or block them explicitly, building on last week's theme that scaling Copilot use depends on admin-managed settings and predictable budgeting.

Gemini 3.8 Flash comes with introductory provider pricing under usage-based billing through December 31, 2026, which makes it a candidate for cost-sensitive workloads if it meets your quality bar. Claude Fable 5.1's notes include data-retention requirements and Zero Data Retention (ZDR) access for eligible enterprises under a time-bound exemption tied to Enterprise Frontier Safeguards (EFS), so regulated teams should treat this as a procurement/policy check as much as a developer feature.

Deprecations and admin controls: avoid surprise model removals

GitHub deprecated several Copilot models effective September 1, 2026, and also announced an additional set of selected models scheduled for deprecation on October 2, 2026, with recommended replacements. If your org relies on a specific model for chat, review, or agent tasks, you should verify what changed in the selector and update internal guidance before developers hit silent fallbacks, especially given last week's emphasis on model governance and usage-based cost controls.

For Copilot Business and Enterprise, the operational action is to review Copilot model policies so replacement models are enabled where needed (especially for VS Code and github.com chat selectors). This week also brought a governance tweak for Team plan users with seats in multiple orgs: model availability now follows the organization that is billed for the user's Copilot usage, aligning access with billing and policy ownership.

HydraFusion and multi-model orchestration shift Copilot from “pick a model” to “route the work”

This week pushed a clear theme: Copilot is moving beyond manual model selection toward orchestrating multiple models at runtime to balance quality, latency, and cost, building on last week's cost-and-governance thread where teams were already being pushed to treat model choice as an operational decision. GitHub framed this as a harness-driven approach where the system can plan, execute, critique, and iterate using different execution patterns rather than relying on a single model for the whole task.

Project HydraFusion: runtime routing with Single, Cascade, and Critique patterns

GitHub's Project HydraFusion is a research preview that orchestrates multiple models during a task, using execution patterns like Single, Cascade, and Critique. The key practical point is that routing can change per task, so developers get a “best fit” path without explicitly choosing a model upfront, and GitHub reports offline benchmark results that target near-frontier quality with large estimated cost reductions on agentic coding benchmarks.

The deeper technical angle is that HydraFusion is not only model mixing, its about policy and routing strategy (including approaches like beam-search-style policy tuning) applied to agent workflows at the repo level. If you are evaluating Copilot for agentic coding at scale, this preview is a signal that “model governance” will increasingly include orchestration policy, not just a list of allowed models.

HydraFusion reaches Copilot CLI (/experimental)

GitHub also highlighted HydraFusion in the Copilot CLI as an experimental capability, with directions to enable it via /experimental, which lands neatly after last week's terminal-first Copilot CLI workflows and SDK patterns for repeatable agent runs. The CLI angle matters because terminal workflows often involve tool execution, output parsing, and iterative fixes, which are exactly the kinds of loops orchestration tries to optimize (and GitHub cites offline results on Terminal-Bench 2.1 versus Claude Opus 5).

For teams trying it, the immediate work is enabling the experiment in developer environments and deciding how you will measure outcomes (completion rate, time-to-fix, token usage, and cost). Since this is experimental, treat it like a feature flag: test on representative tasks before rolling it into default workflows.

Community perspective: “model selection” to “model orchestration” and cost goals

A separate update on HydraFusion framed the transition as moving from offering model choices to orchestrating a heterogeneous model ecosystem, with a stated benefit of up to 67% lower cost, echoing last week's emphasis that budgeting and token discipline are becoming first-class parts of Copilot rollouts. Even if that number is context-dependent, it matches GitHub's broader message that cost control will come from fewer wasted turns and smarter routing, not only cheaper base models.

As this evolves, expect new questions for admins: do you control orchestration policies, do you audit which models were used per task, and how do you attribute cost when multiple models contribute to one outcome. Those are governance problems as much as developer-experience features.

Security and governance in agentic workflows: content exclusions, identity, and cost controls

Content exclusions reach Copilot app and CLI (including agentic workflows)

Copilot app and Copilot CLI now honor enterprise, organization, and repository content exclusion policies, which prevents excluded files from being pulled into context, extending last week's push to make agent work more governable across non-IDE surfaces like the Copilot app and CLI. That closes a practical gap for teams adopting agentic workflows outside the IDE, where “what the agent can read” becomes the core control point for sensitive code and credentials.

The weekly changelog also called out expanded content-exclusion protections specifically for Copilot app/CLI agentic workflows, reinforcing that the policy is intended to be consistent across surfaces. If you already configured exclusions for IDE chat, you should verify that the same exclusions apply to app- and CLI-driven flows that run agents against repos.

Why Actions cannot spawn cloud agent sessions with GITHUB_TOKEN (and what to do instead)

Jesse Houwing dug into why GitHub Copilot cloud agent sessions cannot be created from GitHub Actions using the built-in GITHUB_TOKEN, tying it to GitHub's accountability model (identity, billing, and auditability), which maps to last week's theme that agent work needs stronger controls and clearer provenance when it can open pull requests or touch real systems via tools. The takeaway is that “agent work” is treated like an accountable action that needs a user-or-server identity suitable for billing and logging, not an implicit workflow token.

He also outlines workable orchestration patterns using gh-aw, including in-run sub-agents, gated multi-workflow flows, and PAT-backed cloud agent sessions, plus guidance around safe outputs and AI Credits (AIC). If you are building agentic CI/CD, this is the kind of constraint you need to design around early so your pipeline does not stall when it tries to spin up a new agent.

Billing and budgets: signups reopen, seat billing changes, and budget expirations

GitHub is gradually reopening Copilot Business and Copilot Enterprise sign-ups for customers paying by credit card or PayPal, and it outlined billing and vetting changes, continuing last week's thread on AI Credits, budgets, and cost-center style controls as prerequisites for wider adoption. The biggest operational shifts are pay-before-access seat assignment and upfront seat charges starting October 1, 2026, plus potential payment requirements when exceeding included usage.

On the control side, budgets now support expiration dates for individual user overrides via billing settings or the Budgets REST API using the expires_at field. That gives admins a cleaner way to grant temporary higher spend for a migration or incident without leaving permanent exceptions behind.

Copilot in VS Code: agent workflow UX keeps getting more “tooling-like”

VS Code releases and notes this week continued to make Copilot's agent experience feel less like a chat box and more like an IDE subsystem: better session organization, clearer context, and more visible usage and limits, which follows directly from last week's emphasis on sessions, canvases, and other “visible agent work” patterns that make multi-step efforts easier to review and repeat. If you are standardizing on VS Code for agentic work, these changes are the difference between “cool demo” and “repeatable workflow”.

Agent Merge and agent session handling (VS Code 1.136 and recap 1.133-1.136)

VS Code 1.136 highlights included Agent Merge and improved agent session handling, and the summer recap (1.133-1.136) showed related workflow improvements like prompt UX changes, chat search, detailed per-turn usage, and Agent Plugins support. Together, these target the real friction points in agent usage: keeping parallel threads understandable, merging work back into your branch cleanly, and seeing what a conversation or tool run cost.

If your team is experimenting with Agent Plugins (and MCP-based extension patterns), the recap is useful as a checklist of what is now built-in versus what still needs extension glue. The per-turn usage and better navigation also make it easier to do internal evals (for example comparing success rates across models) without building your own logging layer.

VS Code 1.137 (Insiders) adds a unified model token limit display, which helps developers understand context-window constraints when switching models, building on last week's practical guidance around tokens and keeping context tight with commands like /compact. It also improves context pills when pasting GitHub issue/PR links, reducing the “did Copilot actually ingest the right context?” guesswork.

The Insiders notes also mention MCP server installation defaults for Copilot CLI/agent-host sessions, which lowers setup overhead for teams adopting Model Context Protocol (MCP) tooling after last week's run of MCP tutorials and connector setup aimed at reducing integration friction. If you are rolling MCP out internally, this kind of default matters because it reduces drift between developer machines.

Copilot code review: bots can now submit approvals (public preview)

Copilot code review now adds an approval assessment to every review overview comment, and admins can optionally allow Copilot to submit approvals that count toward required-approvals rules, extending last week's governance discussion about approval gates for Copilot-attributed pull requests and how agent output fits into existing review workflows. This is in public preview across Copilot Pro, Pro+, Max, Business, and Enterprise, and it changes how teams might structure review policies because an automated approval can now satisfy branch protection requirements if you enable it.

Teams should treat this as a governance decision, not just a convenience toggle: decide when an automated approval is acceptable, what codepaths it can approve, and how to monitor false positives. In practice, you will likely want to start with low-risk repos or non-production branches while you measure whether Copilot's assessment matches your human reviewers' bar.

Other GitHub Copilot News

GitHub continued to invest in “how” Copilot runs agentic work, not just what models it supports, which picks up on last week's platform-and-workflow thread (harness patterns, repeatable skills/plugins, and more reviewable agent execution) by drilling into cost controls and runtime coordination. One post details shipped cost controls (selective compression of noisy tool output, removing wasted formatting in file viewing, prompt compression backed by regression tests, and batching background task results to avoid extra model turns), and another explains harness engineering concepts that show up in Copilot's runtime coordination and guardrails.

On the practical workflow side, there were several hands-on guides and trainings: running parallel agent sessions in the Copilot app (with separate Git worktrees per session), grounding agents in a local clone and requiring file-and-line evidence, and multiple Copilot SDK sessions showing how to build custom tools with MCP-based extensibility. Radius Canvas also entered public preview inside the Copilot app, building a versioned application model from a repo and generating GitHub Actions deployments using OIDC trust for short-lived credentials, which is a concrete bridge from “agent suggests” to “agent ships” in a controlled way.