GitHub Universe 2026: what actually changes for teams using Copilot

Published October 29, 20266 min read

Universe keynotes are written for executives, and this year's was no exception. Jay Parikh's announcement post frames GitHub as “a complete software delivery system built around agents” and says “Completed work, not more code, is the output that matters.” Under the framing are a handful of concrete product changes, and most of them come with a bill attached.

This piece sorts them by what a team lead or platform engineer has to decide. Everything here comes from GitHub's announcement and its documentation as of October 29. We haven't used Fusion, Max review, or automations on a real repository yet, so the benchmark and cost figures are GitHub's.

The announcements at a glance

Fusion: letting Copilot pick the model

Copilot Fusion is a router. You pick “Copilot Fusion” in the model picker instead of a specific model, and it chooses one or more models and a pattern for each request. The docs list three patterns:

• Single: one model answers.
• Cascade: an efficient model drafts, and a judge accepts the draft or escalates to a stronger model.
• Critique: one model drafts, several critique it in parallel, and the draft is revised.

You choose an effort level of Standard, High, or Max. Fusion is generally available in VS Code, Copilot CLI, the Copilot app, and JetBrains IDEs on all Copilot plans. It only routes to models your plan and your admins' model policies allow.

GitHub's headline claim is that “Fusion Max scored within two points of Opus 5.5 Max at half the cost and 40% less time per task” on the Artificial Analysis Coding Agent Index. That's a vendor number on one index. The pricing logic is plausible, since routing easy turns to a cheaper model is how you'd build this by hand, but nobody has reproduced it yet.

Two limits from the docs matter in practice. Fusion doesn't start subagents. And when a cascade escalates, “changes that the draft already made in your workspace, such as file edits, aren't undone automatically,” so a rejected draft can leave edits behind. Review the diff before you commit. The docs also say the model pool and patterns may change, which makes Fusion a poor fit if you need reproducible runs. Pin a specific model for those. If cost is the reason you want routing, compare against doing it by hand with a cheaper model such as GPT-6.1 Terra for the high-volume steps.

Code review now has three price points

Copilot code review now runs at one of three effort levels, billed in AI credits. GitHub's own estimates per review:

Those estimates exclude Actions minutes, and the docs say cost rises with PR size and with repository custom instructions. GitHub says Max “posted the highest F1 score on ReviewBench for high-severity issues” but doesn't publish the score.

The budget math is simple and worth doing before anyone flips a default. The estimates are per review run, so re-reviews after new pushes and reviews of PRs that never merge count too. A team that runs 400 reviews a month uses roughly $100 of credits at Lite, $600 at Balanced, and $4,000 at Max, using GitHub's averages, before any credits your plan includes. Balanced is already the built-in default, so many teams are using it without having chosen it.

The level resolves in order: the effort picked on the request, then the level already used on that PR, then the requester's setting, the repository setting, the organization setting, and finally the built-in default. Our suggestion is Lite as the organization default, Balanced on repositories with security-sensitive code, and Max requested by hand on release-critical PRs, which is close to GitHub's own guidance.

Automations: cloud agent on a trigger

Copilot automations run the cloud agent on a schedule (hourly, daily, or weekly), when an issue is created, when a PR is opened or gets new commits, or from an API call. Issue triage and review are GitHub's example uses. They're available on Pro, Pro+, Max, Business, and Enterprise, but only in private or internal repositories.

The details that should shape how you roll them out:

• They aren't in Git. Automations are created in the UI or API and “are not committed to Git,” so changes to them don't go through pull requests, CODEOWNERS, or your repository's Git history. Keep a written list of what runs where.
• MCP tools reach beyond the repo. GitHub tools are limited to the one repository, but MCP server tools “aren't limited to that repository.” Treat each MCP tool you grant as access to that whole system, the lesson of the LiteLLM token incident.
• Untrusted events are off by default. Events from users without write access are ignored “to reduce the risk of prompt injection from untrusted users.” Leave that default alone.
• They can rewrite each other. Automations can propose changes to their own prompts, tools, and triggers, and to those of other automations. Nothing applies until a person approves it, so read each proposal like a diff.
• Every run costs. Runs use AI credits plus Actions minutes. Personal automations bill the creator, and shared ones bill the organization. You can set a per-run cap (minimum 30 credits) and daily, weekly, or monthly limits. The period limits block new runs but don't stop one already in progress.

Set the limits on day one. An automation triggered on every PR synchronize event runs on every push, and on an active repository that adds up quickly.

The Enterprise billing change

From October 28, GitHub Enterprise customers can use all Copilot features, including the app, code review, and automations, without a separate Copilot subscription: “You pay for the AI credits you use.” It's available through GitHub Sales now, with self-serve promised later. Existing Copilot Business and Enterprise customers can keep their plans or switch when ready.

This is the change with the longest tail. Heavy users could already cost more than their seat through overages, as our usage-based billing piece covered. With no separate subscription, usage becomes the whole bill, which makes the review defaults and automation limits above matter more. Before switching, compare against your billing usage records. The usage metrics API in our Copilot metrics piece is built for adoption trends, and GitHub says it isn't for exact accounting.

The number behind the push

GitHub's Octoverse report, published the same day, explains why every announcement is about agents. It says that “By September 2026, more than 40% of pull requests on GitHub started with an agent's first draft, up from 17% in March,” or about 110 million that month. It also says 55% of Copilot's monthly active users now use agentic features, up from 35% a year ago. Agent-started PRs touched several files more often (about 87% versus 79%) and merged within two weeks at 90% in September, against about 86% for the rest.

A merge rate isn't a quality measure, and the report doesn't say how many of those merges were later reverted. Still, it's GitHub's own data, and it explains why review capacity is where GitHub is now selling.

What to do this week

• Check the organization default for code review effort, and decide on purpose between Lite and Balanced.
• Decide who may request Max, and on which repositories.
• Before anyone creates automations, agree on per-run and monthly credit limits and on which MCP tools they may use.
• If you rely on reproducible agent runs, pin models instead of using Fusion.
• If you're on GitHub Enterprise, model your current usage at credit rates before talking to Sales.

What we didn't verify

The Fusion benchmark, the ReviewBench claim, and the Octoverse numbers are GitHub's, and none has an independent check yet. The docs don't give a release status for automations or session continuity, or a price for Copilot projects. The cost estimates per review are GitHub's ranges, and your PR sizes will move them.

Sources

• GitHub Blog: GitHub Universe 2026: Evolving every layer of the stack (October 28, 2026).
• GitHub Docs: Copilot Fusion.
• GitHub Docs: Copilot code review: effort levels and cost estimates.
• GitHub Docs: About automations.
• GitHub Docs: Working with projects.
• GitHub Blog: Octoverse 2026 (October 28, 2026).