Copilot Fusion needs a routing acceptance contract.

The model name is no longer the deployment unit

GitHub made Copilot Fusion generally available on October 28, 2026. Fusion is not another fixed model in a picker. It is a runtime that selects from models allowed by plan and policy, then uses a Single, Cascade, or Critique pattern based on the task and the chosen effort level. That changes what an engineering team must approve.

With a fixed model, an evaluation can pin a model identifier, prompt, tool set, repository state, and task. Fusion introduces a decision layer between the request and the models. The chosen model pool can change. Service health and cache boundaries can affect routing. A higher effort setting may call more than one model. A reviewer model may receive only selected context. The user sees the final answer, not every intermediate draft. GitHub explicitly describes the model pool and patterns as subject to change.

That flexibility can improve quality and efficiency. GitHub reports a score of 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code with Opus 5.5 Max, while using about half the average API cost per task, half the tokens, and 40 percent less time. Those are first-party results on a public benchmark. They justify testing Fusion; they do not establish that it is better for your repositories, risk classes, or review constraints.

The acceptance unit should be the full task receipt: frozen repository state, task statement, risk class, effort level, eligible models, policy snapshot, tool permissions, observed route, final diff, residual workspace state, deterministic test evidence, resource consumption, reviewer decision, and rollback target. If any of those material inputs change, the result belongs to a new evaluation cohort.

Understand the three patterns before comparing effort levels

GitHub documents that Standard, High, and Max are effort controls, not promises of a specific model. Standard emphasizes a single model. High and Max can use multiple models and more computation. The runtime considers task characteristics, model capability, model availability, cache boundaries, and policy eligibility. If no model is eligible, Fusion is not offered. That makes administrator policy part of runtime behavior rather than a separate procurement detail.

Context is also constrained by the smallest context window among eligible models. This conservative boundary can prevent a route from silently exceeding one participant's limit, but it may reduce the material available for a large migration or repository-wide diagnosis. A team should therefore test long-context tasks separately instead of assuming that a higher effort label expands context.

The interface exposes which models were used when a user hovers over the Fusion label, but GitHub says the final response is shown while intermediate model drafts remain hidden. This is a reasonable product abstraction; it is not a forensic transcript. Your acceptance evidence must come from inputs you control, tool logs you retain, the final workspace diff, test receipts, the visible model set, cost records, and the human review outcome.

task_id: auth-refresh-017
risk_class: high
repo_base: 2dd3...a91
fusion_effort: high
eligible_models_policy: copilot-model-policy-2026-10-31
tools: [read_repo, edit_workspace, run_unit_tests]
forbidden: [network_write, secret_read, merge]
acceptance:
  deterministic_checks: [unit, integration, secret_scan, auth_regression]
  max_wall_minutes: 35
  max_cost_usd: 8.00
  independent_reviewer: security-owner
  exact_head_approval: required

Separate routing, evidence, and authorization

A router is allowed to decide how work is attempted. It should not decide whether the result is safe to merge. Keep three control planes separate. The routing plane selects eligible models and patterns. The evidence plane records what happened and runs protected checks. The authorization plane decides whether residual risk is acceptable.

The contract should be explicit enough to survive a model-pool change. Pin what the team controls: task taxonomy, risk class, Fusion effort, organization policy snapshot, tool permissions, repository base, fixture data, network boundary, acceptance tests, budgets, reviewer role, and rollback. Record what the runtime controls as observations: model set, pattern if exposed, timestamps, token or premium-request accounting, tool sequence, failures, retries, and final output.

fusion_acceptance_contract: v1
scope:
  task_classes: [bug_fix, test_repair, refactor]
  excluded: [production_access, secrets_rotation, destructive_migration]
inputs:
  base_commit: immutable
  issue_text: frozen
  policy_snapshot: required
  local_model_endpoint: none|pinned
evidence:
  route_observation: [models_used, effort, start, finish]
  workspace_diff: required
  residual_untracked_files: required
  deterministic_receipts: required
budgets:
  wall_minutes_p95: 30
  accepted_task_cost_p95_usd: 6
authorization:
  agent_cannot_merge: true
  exact_head_human_review: true
  approval_expires_on_change: true
rollback:
  fixed_model_path: documented
  clean_workspace_restore: tested

Do not require an impossible explanation of proprietary routing internals. Require enough evidence to reproduce the decision boundary you own. If a task fails after a model-pool change, you should be able to identify the policy cohort, the observed models, the repository state, and the test that caught the regression. That supports a safe rollback even when the internal router cannot be replayed exactly.

Protect the acceptance checks from the coding run. The agent may author tests, but a trusted pipeline should execute the approved suite from the exact candidate head. For high-risk changes, add a test-suite auditor or mutation fixture that proves the checks can fail. A Critique route does not create evaluator independence if both models rely on the same incomplete requirements and the same agent-authored tests.

Evaluate accepted work, not attractive answers

GitHub's Project HydraFusion describes evaluation across TerminalBench 2.1, DeepSWE, and an internal CheckpointBench. Public benchmark results are useful for comparing broad agent capability, but production adoption requires repository-specific tasks. Construct a frozen set from real, sanitized work: regression fixes, multi-file refactors, dependency updates, ambiguous bug reports, long-context migrations, flaky tests, and tasks the team previously rejected.

Run each task enough times to expose variance. Compare Standard, High, and Max with a fixed-model baseline where available. Do not force every task through every setting forever; the goal is to identify a safe default by class. Standard may dominate for bounded fixes. High may earn its extra work on cross-cutting changes. Max may be appropriate only when the marginal acceptance rate justifies higher cost and latency.

Score failure as carefully as success. Record whether the run stopped, asked for clarification, produced a plausible but wrong patch, altered unrelated files, hid uncertainty, exceeded budget, or left the workspace dirty. A safe refusal can be better than a confident patch. A router that escalates difficult tasks but contains failure may be more valuable than one that generates more code.

accepted_task_cost =
  sum(model_charges)
  + ci_compute
  + reviewer_minutes * loaded_rate
  + remediation_minutes * loaded_rate

route_value =
  accepted_tasks
  - escaped_regressions * severity_weight
  - policy_violations * stop_weight

Model eligibility is part of the product

Enterprise and organization administrators can control model availability. GitHub's policy documentation describes baseline policy plus organization or team restrictions, and notes that migration between policy systems can cause regressions. Fusion also excludes models based on plan, administrative policy, data-residency or FedRAMP constraints, and evaluation status. The same user prompt can therefore produce a different eligible pool after an admin change.

Capture the effective policy, not only the intended policy. Your preflight should verify that Fusion appears for the test identity, list the models the interface reports after a run, confirm data-residency and contractual requirements, and fail closed if the pool becomes empty. A central admin rollout should include canary organizations and a regression task set before a broad policy change.

GitHub also announced experimental local-model selection for Fusion. Standard effort can use a Windows managed model; Qwen can be connected through an OpenAI-compatible server and Copilot CLI across operating systems. Routing decisions still occur in the cloud, and GitHub warns that local models do not receive the same safety protections as hosted models. “Local model” therefore does not mean a fully local control plane or equivalent assurance.

Keep local endpoints in a separate trust zone. Authenticate the client, bind model and weight digests, restrict network reach, log requests without secrets, and define what happens when the server is unavailable. Never silently fall back from an approved local route to an unapproved hosted model—or from a protected hosted model to an ungoverned local server.

One request can contain several billable decisions

GitHub says each model used by Fusion is billed at the model's standard rate. A limited-time 30 percent discount runs through November 30, 2026. That temporary price should not become the business case for a permanent default. Model the undiscounted steady state and verify actual account records because plan entitlements and premium-request multipliers can change.

Measure cost by accepted task. A cheap attempt that fails review and triggers another run is not cheap. A Critique pass that prevents a production regression may be excellent value. Include model charges, CI, sandbox time, reviewer effort, rework, and incident cost. Report medians and tails by task class; averages can hide a small set of runaway tasks.

Latency also needs an end-to-end definition. Record time to first useful action, time to final patch, CI time, human review time, and total time to accepted merge. GitHub's reported 40 percent time reduction is a useful hypothesis. Reproduce it against your own queue, repository size, network, tools, and review standard.

Set budgets as stop conditions, not aspirations. When a task exceeds its wall-clock or cost ceiling, preserve evidence and hand it to a human or a fixed-model fallback. Do not let escalation continue merely because the runtime believes another attempt may help. For high-risk tasks, require an explicit human decision before budget expansion.

Rehearse the failures orchestration can hide

Fusion works separately from Copilot subagents, according to GitHub's documentation. Test those boundaries explicitly. A task that invokes subagents may create another layer of delegation, permissions, and cost not represented by the Fusion model label. Your receipt should record both orchestration systems rather than treating them as one invisible agent.

Run a 30-day acceptance pilot

1. Week 1 — freeze the baseline. Select 30 to 60 sanitized tasks across risk and repository types. Record fixed-model outcomes, tests, reviewer minutes, costs, and rework.
2. Week 2 — shadow Fusion. Run Standard and High in disposable workspaces. Do not merge. Capture visible models, diffs, residual files, protected tests, costs, latency, and failure categories.
3. Week 3 — limited live use. Enable the best route only for task classes that cleared thresholds. Keep merge authority human and exclude secrets, production access, destructive migrations, and incident response.
4. Week 4 — challenge and decide. Change model policy in a canary, simulate an unavailable local endpoint, inject a failing test, exceed a budget, and verify clean rollback. Approve a routing matrix, not a universal default.

Precommit the stop rules: deterministic-check bypass, protected-file edits outside scope, merge without exact-head approval, untraceable billing, material acceptance regression, dirty workspace after rollback, local endpoint identity failure, or inability to reconstruct the policy cohort. A stopped pilot is evidence that the control works.

The final artifact should be a routing matrix. For example: Standard for bounded documentation and low-risk fixes; High for tested multi-file features; Max only for a narrow set with demonstrated marginal value; fixed model for regulated or reproducibility-sensitive tasks; human-only for production credentials and destructive operations. Review the matrix whenever model policy, tool permissions, pricing, or the Fusion runtime changes materially.

FAQ

Is Copilot Fusion simply automatic model selection?

It includes selection, but GitHub also describes orchestration patterns that can cascade work or use one model to critique another. Higher effort may therefore change both the model set and the work pattern.

Should we always choose Max effort for important code?

No. Importance determines the rigor of evidence and review, not automatically the largest model budget. Use repository-specific results to decide whether Max materially improves accepted outcomes for that task class.

Can the displayed model list reproduce a run?

Not by itself. Reproduction also needs repository state, task, policy, effort, tools, environment, tests, and runtime cohort. Intermediate drafts are not exposed, and the model pool may change.

Does a local model keep the whole workflow local?

No. GitHub says routing decisions still occur in the cloud, and experimental local models have different safety protections. Verify the actual data path and control boundary.

What metric should executives see?

Cost and elapsed time per accepted task, segmented by risk and task class, alongside regression escapes and reviewer effort. Request counts and benchmark scores are supporting measures.