Copilot Fusion hands GitHub the model choice. Copilot access makes the budget the control

GitHub used its Universe conference on 28 October 2026 to move two decisions from developers to Copilot. Copilot Fusion now picks which models answer a prompt and how they work together. Copilot projects let one goal fan out into agent sessions across several repositories, with a single place to approve, steer and review. Underneath both, GitHub changed how large customers pay: Copilot access through GitHub Enterprise has no seat charge for Enterprise Cloud users and no included AI credits, so every request is metered from the first one.

For an engineering team the practical change is about control. Model choice becomes a policy question that administrators answer once, through the models Fusion may use and the effort level it defaults to, rather than something each developer handles mid-task. Coordination across repositories becomes a queue of decisions rather than a set of browser tabs. Cost control moves from counting seats to setting budgets, because on the new Copilot access model the budget is the only thing that limits spend.

GitHub’s headline claim for Fusion is that, on the Artificial Analysis Coding Agent Index, Fusion Max scored within two points of Claude Code running Opus 5.5 Max at about half the cost and 40% less time per task. We checked that against Artificial Analysis’s published data and it holds for the composite score. The per-benchmark results are more mixed than the headline suggests, and the cost figure is an API-price estimate, not a Copilot bill. The rest of this piece explains the mechanisms, the evidence and the decisions each change forces. We have not run Fusion or projects ourselves; product behaviour below comes from GitHub’s documentation and changelog as read on 12 November 2026.

What shipped on 28 October, and in what state

Universe produced dozens of changelog entries. Three matter for this question, and they shipped in different states. The distinction matters because a generally available feature, a public preview and a sales-led offer carry different commitments.

Jay Parikh’s Universe post is the summary document, published the same day as the event. It says projects are “available natively in the GitHub Copilot app starting today” without using the word preview. The app changelog and the projects documentation both say public preview and subject to change. We use the documentation’s label.

How Copilot Fusion decides

GitHub’s Fusion documentation describes it as “an intelligent runtime model router and orchestrator”. You select Copilot Fusion in the model picker and choose an effort level, but you are not choosing a model. For each prompt, Fusion selects an execution pattern, a reasoning effort and the models that run it, then returns a single response.

The routing input is a set of capability signals for reasoning, code generation, debugging and tool use. Fusion uses them to choose “the most efficient execution pattern that meets the quality bar” for the effort level you picked. GitHub says choosing a pattern “adds minimal latency” but gives no figure.

Three execution patterns

The documentation lists three patterns:

• Single. One model completes the task. GitHub says it behaves like a request to one model.
• Cascade. An efficient model drafts a solution, and a judge inspects the draft and either accepts it or escalates to a stronger model.
• Critique. One model drafts while several models critique the draft independently and in parallel. Their feedback is combined and the original model revises.

The pattern is chosen per prompt, so a session can run its first prompt as single and a follow-up as critique. Cascade and critique take longer because they add review calls. GitHub’s stated rule is that Fusion “only adds model calls when a task warrants them”, so a simple task does not pay for a review it does not need.

The critique pattern has changed since the research preview. GitHub’s September post on Project HydraFusion, Fusion’s predecessor, described a single read-only critic “from a different model family” and one revision. The general-availability documentation describes multiple critics in parallel. The changelog’s shorter description still says “another model reviews it”. Teams estimating cost should work from the documentation, because more critics means more calls per prompt.

Four effort levels

The plan columns come from the availability table on the Fusion documentation page as read on 12 November. The changelog’s line that Fusion is “available on all Copilot plans” is true of Standard but not of High or Max.

Details that affect real work

Several documented behaviours matter more in daily use than the patterns themselves.

Discarded drafts can leave edits behind. The documentation is direct: if Fusion discards a draft, “changes that the draft already made in your workspace, such as file edits, aren’t undone automatically.” The HydraFusion post described a “fail-safe application” principle under which no patch is applied when a workflow is cancelled or fails validation. The shipped documentation’s warning is narrower, and it is the one to plan around. Review the working tree before committing, especially after a cascade escalation.

The context window is the smallest in the pool. Fusion has no context window of its own. Each step runs inside the limits of the model running it, and the window shown in the picker is “a conservative value based on the smallest limits among the models it uses.” A team that relies on very long contexts may find Fusion’s advertised window smaller than the largest model it routes to.

Routing respects caches. GitHub says Fusion routes “along natural cache boundaries and large changes in conversation complexity” and keeps the main conversation on one model where possible, so the conversation keeps benefiting from cached tokens. Reviewer models receive only the context they need. This matters for cost because, in Copilot’s pricing table, cached input is a tenth of the uncached rate or less for most models. Our prompt caching explainer covers why that discount dominates agent bills.

Fusion is not a subagent system. It “works separately from subagents and doesn’t start them.” Orchestration here means several models collaborating on one response, not a planner spawning workers. Parallel workers are what projects provide.

You see the steps, not the drafts. You can follow each step and the model in use, but intermediate drafts are hidden and only the final response is shown. After a response, hovering over the effort level lists the models used. That hover is, for now, the only per-response record of which models a developer’s prompt touched.

What administrators control

Fusion only uses models that enterprise and organisation policies allow. According to the model availability documentation, enterprise owners can open AI controls, then Copilot, then “Configure Copilot Fusion models”, and set each model’s status for Fusion separately from its general availability. Two consequences follow. A model can be blocked inside Fusion while developers can still pick it directly. And because “frontier models are often used by Fusion Max”, disabling any model Max requires removes Fusion Max from the picker altogether.

Fusion also excludes models that are outside a plan, blocked by policy, excluded by data-residency or FedRAMP restrictions, or blocked as evaluation models. If none of its models are available, Fusion does not appear.

Administrators can make Fusion the default. The enterprise managed settings reference adds a fusionTier key alongside model. Setting model to "fusion" makes Fusion the default for new sessions, and fusionTier accepts "standard", "high", "max" or "unmanaged". Any value other than "unmanaged" locks the effort level against user and repository overrides. A team-overridable default is written as { "overridable": "standard" }. The reference’s client-support table sets minimum versions for this key: Copilot CLI 1.0.104-3, VS Code 1.144.0 and the Copilot app 1.1.33-4. Check the versions in use before relying on it.

This is where model choice becomes policy. An enterprise can make Fusion the default for new sessions, lock its effort level at Standard, allow one platform team to override to High, and remove an expensive model from Fusion’s pool without removing it from the picker. The lock applies to the effort level, not the model: the reference says users can still pick a different model for an individual conversation. GitHub’s changelog quotes Hari Pokhrel, a principal software engineer at AT&T, saying developers “would often choose a more powerful model for a complex task and forget to switch back”; Fusion Standard as the default addresses that, and we have no independent data on how much it saves. Teams that already run coding agents under managed settings will recognise the pattern from our Claude Code enterprise rollout plan.

Local models, with caveats

A separate experimental preview lets Fusion Standard route some requests to on-device models: MAI Code 1.1 Flash through a managed Windows ML download, or MAI Code 1.1 Flash or Qwen3.8 Flash Next through a local OpenAI-compatible server in the CLI on Windows, macOS and Linux. It must be switched on as an experimental feature, and only Standard uses local models. In the Copilot app, routing currently covers managed Windows ML models only. The Fusion documentation labels the same feature public preview; the changelog calls it an experimental preview. GitHub adds two caveats. Local inference “doesn’t make your session offline”, because Fusion “still makes routing decisions in the cloud”. And local models “may have different safety protections” from Copilot’s cloud models.

Checking the benchmark claim

The Universe post says: “In the Artificial Analysis Coding Agent Index, Fusion Max scored within two points of Opus 5.5 Max at half the cost and 40% less time per task.” The Fusion changelog is more precise. It names the baseline as Claude Code with Opus 5.5 Max, gives Fusion Max’s score as 60, and adds that it used about half as many tokens.

Artificial Analysis is an independent benchmarking company, so this is a third-party measurement, not a GitHub-run test. Its Coding Agent Index v2.0, current since October 2026, is the equal-weight average of three benchmarks: FrontierCode v1.1 (100 unreleased tasks on real open-source repositories, graded on whether a maintainer would merge the change), Terminal-Bench 4.0 (66 terminal tasks) and SWE-Atlas-QnA-AA (124 repository questions graded by rubric). Each task is attempted three times and scores are averaged per task, then across tasks.

We read the benchmark page on 12 November 2026. The page data we read carries an 11 November 2026 processing timestamp, two weeks after GitHub’s claim, so we can confirm that the numbers match the claim now, not what the page showed on 28 October.

On the composite, GitHub’s wording is accurate. A 1.8-point gap is “within two points”, 49% of the cost is “about half”, 59% of the time is roughly “40% less” and 51% of the tokens is “about half as many”.

Three conditions the headline leaves out

The composite hides offsetting results. Fusion Max wins Terminal-Bench by 8.1 points and loses repository Q&A by 8.9 points and maintainer-mergeable patches by 4.6. Artificial Analysis itself warns that the index “should be read alongside the per-eval breakdowns” because agents with similar index values “can still have different strengths”. A team whose agent work is mostly understanding and explaining a large codebase should weigh the SWE-Atlas result more heavily than the composite. A team doing terminal-heavy operations work might reasonably weigh it the other way.

The cost is a pay-per-token API estimate, not a Copilot invoice. The methodology defines cost to run as “average pay per token API cost per task, based on provider token pricing rather than consumer plans”, including cached-input discounts and cache-write charges. It does not include the 30% Fusion promotion, and nothing we read says which price list was applied to the models inside Fusion’s run. Copilot bills Fusion at Copilot’s own per-model rates. The ratio is a reasonable guide to relative token spend; the dollar amounts should not be used for a Copilot budget.

The comparison is harness against harness. Each row on the page is “an agent variant, not a model”. The comparison pits GitHub’s harness and router against Anthropic’s Claude Code harness with one model, so the result mixes routing gains with harness differences. The Opus row is also labelled “Default Fallback”: in 76 of its 870 attempts the model refused on safety grounds and another model completed the attempt (the refusal records we read name Claude Opus 4.8). Under the methodology, fallback attempts are scored like any other, so part of the baseline’s score came from a different model. Fusion recorded no refusals.

Fusion is not the only agent near 60

The same page lets the claim be placed in context. These rows were also read on 12 November:

Two things stand out. Among the agents in this table, Fusion Max is the cheapest to score close to 60. And a second multi-model router, Cognition’s Devin Fusion CLI, sits within a fifth of a point of the Opus baseline at 70% of its cost. That makes the broader finding, that routing between models can approach a single frontier model’s quality for less, rest on more than one vendor’s result. It also shows that the trade-off depends on the harness and the pool: Devin’s router scores higher than Fusion Max and costs more per task. The Sonnet 5.5 row carries the same “Default Fallback” label as the Opus row, with 45 of its 870 attempts completed by a fallback model. Our piece on why benchmarks became a marketing channel explains why a benchmark result quoted in a vendor’s launch post deserves this kind of check.

The page has no rows for Fusion Standard or Fusion High, which are the levels most developers will run every day. The external evidence covers Max only.

How this compares with GitHub’s own September numbers

The HydraFusion research preview, announced on 4 September 2026 in Copilot CLI’s experimental mode, came with GitHub-run offline evaluations against Claude Opus 5, all models at medium reasoning. GitHub reported 67% lower estimated cost and 4.9 points higher quality on TerminalBench 2.1, 36% lower cost and 1.5 points lower on DeepSWE, and 65% lower cost and 0.1 points lower on CheckpointBench, an internal benchmark built from real Copilot sessions. The post described these as “the best tuned HydraFusion configuration” and said they were “specific to the evaluated benchmark revisions, workflow configurations, model pool, and pricing assumptions.”

The direction is consistent across both sets of results: the router does best on terminal tasks and gives up ground on repository-level work, slightly in GitHub’s own tests and by up to 8.9 points in Artificial Analysis’s. The Artificial Analysis result is the stronger evidence because it was measured by a third party on a newer baseline at maximum effort. Neither set measures how Fusion behaves on long multi-turn sessions, which the HydraFusion post named as the next area of work.

What Copilot projects change

A Copilot project is a container for a goal. You create one from the Copilot app’s sidebar, optionally attach repositories (or none: projects can “focus on tasks that don’t require a repository”), describe what you want with results and constraints, and optionally add files to a Library. Copilot then coordinates the work, which “can involve starting sessions, setting up recurring automations, or creating artifacts.” The app changelog says Copilot “runs as many agents as the work needs and brings back results (e.g., pull requests) for your review”, and that you can choose the models and tools for the job.

GitHub’s documentation draws the boundary itself: for a task in one repository, start a session from that repository; “use a project when you want Copilot to coordinate work toward a broader goal.”

The human’s surface is a decision queue

The project’s Overview groups work by status:

• Needs input: “Decisions, reviews, and permission requests that need your attention.”
• Open: work with an open pull request, showing the session status, the pull request and lines added and deleted.
• Working: sessions still running.
• Done: completed work.

You can open any session to see its conversation, changes, pull request and plan, and send a message in “Steer this session”. The Library splits material into User (what you added) and Agent (artifacts sessions created). Recurring work is set up in plain language in the project conversation, such as a summary every Monday at 9 AM, and appears in an Automations tab where it can be paused, rescheduled or deleted.

This changes three things for a team.

The unit of delegation becomes a goal. Before projects, the natural unit for a Copilot agent was a session or an issue in one repository. A change that touched a service, its client library and its infrastructure configuration meant three sessions, three contexts and a human keeping them consistent. A project holds the goal and the shared context once and starts the sessions itself.

The bottleneck moves to review. The Needs input queue makes explicit what multi-agent work does to an engineer’s day. Producing changes in parallel is cheap; deciding whether each is right is not. GitHub’s code review additions at Universe, including a Max review level that GitHub says “posted the highest F1 score on ReviewBench for high-severity issues”, address the same bottleneck. We have not verified the ReviewBench result.

Context moves out of chat. The Library is a project-level store of specifications, feedback and agent output. That reduces how often a developer must re-explain a task, and it raises a governance question: whatever goes into a Library is context for every session in the project.

What projects do not do, as far as the documentation says

The documentation does not describe dependency ordering between repositories, coordinated merges or rollback across them. Each session’s work surfaces as its own pull request. A project that changes an API and its consumers will still need the team’s usual sequencing, and cross-repository consistency is still checked by people and CI. GitHub may handle more than the documentation states, but nothing we read says so.

Projects also sit on top of the cloud session model. Cloud sessions started from the Copilot app run by default in a cloud sandbox, an isolated Linux environment GitHub hosts. Because sessions do not run on your machine, “you can run several sessions in parallel without using local resources.” Sessions survive client switches. GitHub’s session management guide describes starting one in the app, steering it from GitHub Mobile, reading its log on github.com and resuming it in Copilot CLI with its history intact. GitHub’s cloud changelog adds that sandboxes have “no one-hour limit on total running session time” and save a snapshot when they stop. For the general shape of the loop around these sessions, see our explainer on what an agent harness is.

The billing change, from seats to budgets

GitHub moved every Copilot plan to usage-based billing on 1 June 2026, announced by chief product officer Mario Rodriguez on 27 April. Under that model, as GitHub’s billing documentation describes it, token use is converted to GitHub AI Credits at 1 credit = $0.01. Copilot Business stayed at $19 per user per month with 1,900 credits, and Copilot Enterprise at $39 with 3,900, pooled across the billing entity. Rodriguez’s stated reason was that “a quick chat question and a multi-hour autonomous coding session can cost the user the same amount”, which made the old premium-request model “no longer sustainable.”

Universe added a third enterprise option. GitHub’s changelog says enterprises working with an account team “can now get Copilot included with GitHub Enterprise for every licensed user.” The billing comparison calls this Copilot access:

GitHub says Copilot access has “the same feature and model eligibility as Copilot Enterprise, subject to administrator policies and spending controls.” GitHub’s pricing page, read on 12 November, lists GitHub Enterprise at $21 per user per month and now names “GitHub Copilot access” among its features.

The rules that come with it

The documentation adds conditions that matter more than the headline:

• Seats still have to be assigned. Developers do not get Copilot automatically. Enterprise owners assign seats to members, teams or organisations.
• The whole enterprise uses one model. Copilot access and Copilot Standalone can be combined, but Copilot access cannot be combined with Business or Enterprise seats in the same enterprise, “including in individual organizations.”
• The paid-usage policy must stay on. The AI credits paid usage policy is on by default and, under Copilot access, “must remain enabled” or credit-consuming features are blocked, since there is no allowance to fall back on.
• Budgets bite from the first request. Spending limits apply “from the first metered use”, against “after the included pool is exhausted” on Business and Enterprise. User-level budgets always enforce a hard stop.
• An empty budget does not remove the seat. Code completions and next edit suggestions keep working with no budget. Copilot Chat, code review and Copilot in the cloud need budget.
• The network endpoint changes. Copilot access uses the Copilot Enterprise endpoint, so an allowlist that permits only *.business.githubcopilot.com needs *.enterprise.githubcopilot.com added.
• Transitions are voluntary and monthly. They take effect on the first day of a month, are arranged through an account team, and are not available to GitHub Free or Team organisations or self-service Enterprise Cloud trials. Self-serve availability will come “in stages” with dates “in the coming weeks.”

A worked example with hypothetical inputs

Take an enterprise with 200 developers, all already licensed for GitHub Enterprise Cloud, and compare one month at list prices. The Enterprise Cloud licence is paid under every option, so it drops out of the comparison. Account-specific discounts are ignored.

On Copilot Enterprise, seats cost 200 × $39 = $7,800 and fund a pool of 780,000 credits, worth $7,800. On Copilot Business, seats cost $3,800 and fund 380,000 credits. On Copilot access, seats cost nothing.

The pattern follows from how GitHub priced the seats. Because each Business or Enterprise seat comes with credits equal to its price, a seat is a prepaid usage commitment. Copilot access removes the prepayment. For users who already hold an Enterprise Cloud licence, it costs the same as either seat plan once usage exceeds the pool, and less whenever usage falls short, because unused pooled credits are forfeited at the monthly reset. It also carries Copilot Enterprise’s feature and model eligibility with no seat charge.

The arithmetic changes for users without an Enterprise Cloud licence. Copilot Standalone costs $10 plus usage. Against a Copilot Enterprise seat, Standalone is cheaper while average usage stays under $29 per user per month and $10 dearer once it passes $39. Against a Business seat, Standalone is cheaper only below $9 of usage and $10 dearer above $19. Because the model applies enterprise-wide, the mix of licensed and unlicensed users decides the outcome.

So the cost question is mostly settled by arithmetic. The real change is that the seat pool is gone. It used to set a monthly floor, and a ceiling for enterprises that switched off paid usage. Spend is now limited by the budgets an administrator sets: per user, per cost centre, per organisation and enterprise-wide. GitHub’s own advice is to “configure budgets before users begin consuming AI credits”. Under Copilot access the paid-usage policy must stay on, so an enterprise that skips that step has set no ceiling of its own. When the move to credits was announced in April, Greyhound Research’s Sanchit Vir Gogia told InfoWorld that “the dashboards do not lower the bill. The architecture lowers the bill.” Fusion’s default tier and the models it may use are now part of that architecture.

Fusion’s bill, step by step

Fusion makes per-prompt cost less visible because one prompt can trigger several model calls. The documentation states that Fusion High and Max “may consume more AI credits than it would with Fusion Standard.”

To show the mechanics, here is a hypothetical critique-pattern prompt priced at Copilot’s published rates. The model choices are ours, for illustration. GitHub does not publish Fusion’s model pool; the Artificial Analysis record for Fusion Max lists Anthropic and OpenAI as the model creators. Cache-write charges, which apply to these models, are left out and would raise every line. Each GPT-6.1 Terra step is kept under that model’s 272K-token input threshold, above which Copilot’s higher long-context rates apply.

With the 30% promotional discount that runs to 30 November, the total falls to about $0.31. For comparison, the draft step alone, the single pattern, costs $0.150. The same draft-sized request sent once to Claude Opus 5.5 at Copilot’s rates ($4 input, $0.20 cached, $20 output per million tokens) costs $0.600.

That is the economic logic of Fusion. In this example a multi-model review is nearly three times as expensive as a single call to a mid-priced model, and still cheaper than one call to a frontier model. Whether Fusion saves money therefore depends on what developers would otherwise have selected. A team that defaulted to frontier models will probably see savings, which is what the Artificial Analysis comparison measures. A team that defaulted to mid-priced models and switches to Fusion Max may see its bill rise.

Two further details matter. Fusion bills “each model it uses, at that model’s standard rate”, so its cost moves whenever an underlying rate moves. Copilot’s pricing page lists Gemini 4 Carbon at promotional rates until 1 December 2026, after which they double. And the 30% Fusion discount itself ends on 30 November.

A second meter for projects

Parallel sessions add a meter that is not AI credits. Cloud sandboxes are billed by compute, memory and storage: $0.000024 per vCPU second, $0.000003 per GiB second and $0.005 per GiB month for snapshots of stopped sessions. GitHub’s cloud changelog says sandbox billing “begins in November 2026” and draws from the included Actions entitlement, which is now a single dollar-based pool shared with standard runners and, on Team and Enterprise Cloud, larger hosted runners.

For scale, take a hypothetical project that runs five sessions in parallel, each in a sandbox with 2 vCPUs and 8 GiB of memory for 45 minutes. GitHub does not publish sandbox sizes, so these are assumptions. Each session costs about $0.13 in compute and $0.06 in memory, roughly $0.19, or under $1 for all five. Model usage is likely to be far larger. As a rough reference, Artificial Analysis measured Fusion Max at $5.59 of API cost per benchmark task, so five such sessions would be about $28 at API prices. For budgeting, credits are the line to watch; sandbox minutes matter mainly because they come out of the same Actions entitlement as CI.

Copilot code review is a third line. GitHub estimates $1.50 to $25 in credits per review at the Max level, averaging about $10, and every review also consumes Actions minutes. At GitHub’s average estimate, a project that opens ten pull requests and sends each to Max review would spend about $100 in review credits before Actions minutes.

Automations, including recurring tasks in a project, can now be capped. A Universe changelog adds optional AI credit limits per run, day, week or month. A run stops at its per-run limit, and new runs wait for the period to reset once a periodic limit is reached. Automations without limits “continue to run as they do today.”

Timeline: how Copilot got here

What is still unknown

Several gaps would change how confidently a team can act.

Fusion’s model pool and routing policy are not published. GitHub says the pool “changes as new models become available”. The only per-response record is the hover list. Without a published pool, or per-model usage in billing exports for Fusion requests, an administrator cannot predict which providers process which prompts beyond what model policies allow. That matters for teams with provider restrictions. The policy controls are documented, but whether routing within allowed models changes week to week is not.

There is no external evidence for Standard or High. The Artificial Analysis comparison covers Fusion Max only. Most usage will be at Standard, and AT&T’s comment in GitHub’s changelog is the only account of Standard in production we found.

The benchmark compares agents, not just models. Comparisons in the same harness, Copilot’s harness with a fixed Opus 5.5 against Fusion Max, would isolate how much of the result is routing. The Artificial Analysis page lists a harness comparison as “coming soon”.

Projects have no independent evaluation. We found no third-party measurement of how projects perform on cross-repository work, how often Needs input items arise, or how well sessions in one project stay consistent with each other.

Some cost controls are not documented for projects. The automation credit limits are documented for automations on github.com and in the app. The projects documentation does not say whether recurring tasks created inside a project expose the same limits, or whether a project as a whole can be capped beyond user and cost-centre budgets.

Self-serve timing and negotiated prices are open. GitHub has promised self-serve Copilot access “in stages” without dates, and tells customers to “confirm any account-specific pricing and migration terms with your account team.”

What would change the conclusion: Artificial Analysis rows for Fusion Standard and High; billing exports showing per-model credits for Fusion requests; a same-harness comparison; or published evidence of discarded Fusion drafts leaving edits in real repositories. If Standard’s quality turned out close to Max’s on a team’s own work, the case for locking the default would get stronger. If the per-benchmark gap on repository Q&A held at Standard, teams doing code-comprehension work would want a fixed model for that task type.

What to do now

For an engineering organisation deciding what to adopt, the evidence supports these steps.

1. Treat Fusion as a policy, not a model. Decide which models Fusion may use under “Configure Copilot Fusion models”, and set model: "fusion" with an overridable fusionTier of "standard" in managed settings for most teams. Allow High or Max for specific teams through an override, not everywhere.
2. Run a measured pilot before locking anything. As a proposed test: give two comparable teams the same two-week workload, one on a fixed model and one on Fusion Standard, each in its own cost centre with budgets. Compare credits per merged pull request and review findings per pull request, and count how often a Fusion response leaves unexpected edits in the working tree.
3. Read the benchmark by task type. If your agents mostly answer questions about large codebases, the 8.9-point SWE-Atlas gap matters more than the composite. If they mostly run terminal work, the 8.1-point Terminal-Bench lead matters more.
4. Use projects for goals that already cross repositories, and keep single-repository tasks as sessions, as GitHub advises. Budget reviewer time for the Needs input queue before adding parallel sessions, and keep CI as the cross-repository consistency check.
5. Price Copilot access with your own usage export. GitHub’s documentation says to include usage your pool currently covers, not just overage. For Enterprise Cloud-licensed users, list-price arithmetic favours Copilot access; for unlicensed users it depends on usage. Either way, set user, cost-centre and enterprise budgets with hard stops before the first day of the transition month.
6. Watch the dates. Fusion’s 30% discount ends on 30 November, sandbox compute billing has started, and underlying model rates change without Fusion changing.

GitHub’s Universe announcements reduce the number of decisions a developer makes in a session. They increase the number an administrator has to make in advance. Teams that make those decisions deliberately, about which models Fusion may use, which effort level is the default, and what each budget covers, are the ones the new billing model rewards.